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: dh-cmake writing to /usr instead of fakeroot?

[Niels Thykier]

Elliana May:

Sorry, I have a few tabs open, this is the correct one:

https://launchpadlibrarian.net/715071071/buildlog_ubuntu-jammy-amd64.duckdb_0.10.0-10_BUILDING.txt.gz

I've tried now overriding the override_dh_auto_configure rule in the
debian/rules file, but even that seems to not be making a difference:

[2/3] Install the project...
-- Install configuration: "Release"
CMake Error at cmake_install.cmake:66 (file):
   file cannot create directory: /usr/local/lib/cmake/DuckDB.  Maybe need
   administrative privileges.

Many thanks,
Elliana



The upstream code seems to be installing during the "build" 
(dh_auto_build), whereas the Debian tooling expects this to happen in a 
separate "install" step (dh_auto_install). This may be related since 
dh_auto_build does not set any form of dest-dir but dh_auto_install does.


Consider it a possible hint for what to look for. That is what I can 
give you from the 5 minutes I had to look at this.


Best regards,
Niels

Re: Package remains in status "Uploaded"

[Niels Thykier]

Preuße, Hilmar:

On 27.09.2023 19:07, Niels Thykier wrote:

Hi,

In your  case, I would start with a give back and then if this attempt 
fails, contact the buildd admins.


AFAICT that option is limited to Debian Developers. So if anybody would 
be so kind


Hilmar


Turns out a give-back is not sufficient (wrong state).  Seems like you 
will need to find a buildd admin. Try debian-wb-t...@lists.debian.org or 
loon...@buildd.debian.org


Best regards,
Niels

Re: Package remains in status "Uploaded"

[Niels Thykier]

Preuße, Hilmar:

Hi all,

the package texinfo has been built successfully for architecture loong64 
and is in status "Uploaded" for about a month now. I'm pretty sure there 
are a lot of packages in status "BD-Uninstallable" b/c it does not get 
installed.


What can be done here?

Hilmar


This usually happens when the upload "fails" for some reason (such as 
expired buildd key, package gets rejected, etc.).


Usually, it can get "unstuck" via a give-back, which is a full rebuild 
if the problem is a "one-off" issue (I believe DDs can request those 
directly in the buildd web-interface these days).  Otherwise, a buildd 
admin has to check what fails.


In your  case, I would start with a give back and then if this attempt 
fails, contact the buildd admins.


Best regards,
Niels

Bug#1051213: RFS: debianutils/5.12 [ITA] -- Miscellaneous utilities specific to Debian

[Niels Thykier]

Control: owner -1 !

Ileana Dumitrescu:

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "debianutils":

[..]

Niels Thykier and I will be co-maintaining this package.



I got this. :)

Best regards,
Niels

Re: Flex help needed for eegdev (Was: Re: eegdev: FTBFS: ../../lib/stdio.h:64:3: error: #error "Please include config.h first.")

[Niels Thykier]

Nilesh Patra:

On Fri, Aug 25, 2023 at 05:17:47PM +0200, Niels Thykier wrote:

[...]


I had figured out this already, but conffile.lex.c does not exist in the
project, it is generated as a part of the lexer output. In particular:



Ok, apologies it was not clear to me from your opening email, where you 
were stuck. I incorrectly assumed it was an an earlier stage than you 
are, so my input was not useful to you.


I checked the source of `conffile.l` and it need already has to runes to 
include config.h where I would have assumed you needed to 
(https://salsa.debian.org/med-team/eegdev/-/blob/master/src/core/conffile.l#L24).


A bit of searching found the following flex upstream bug:

  * https://github.com/westes/flex/issues/564

Which seems related. Hopefully, it can help you.


Best regards,
Niels

Re: Flex help needed for eegdev (Was: Re: eegdev: FTBFS: ../../lib/stdio.h:64:3: error: #error "Please include config.h first.")

[Niels Thykier]

Niels Thykier:

[...]

Hi,

[...]
I believe that this is stdio.h is generated by the embedded gnulib copy 
and that is as far as I am willing to debug that rabbit hole. Based on 
the error, I assume gnulib's generated stdio.h requires the project 
specific "config.h" to be loaded first.

[...]

Best regards,
Niels



Correction; the gnulib was probably not an "embedded copy". The file 
still seems to be generated via gnulib, so the rest of my argument would 
remain the same.

Re: Flex help needed for eegdev (Was: Re: eegdev: FTBFS: ../../lib/stdio.h:64:3: error: #error "Please include config.h first.")

[Niels Thykier]

Nilesh Patra:



On 25 August 2023 1:47:26 pm IST, Nilesh Patra  wrote:

On Wed, 26 Jul 2023 21:52:17 +0200 Lucas Nussbaum  wrote:

Source: eegdev
Version: 0.2-6
Severity: serious

In file included from conffile.lex.c:242:
../../lib/stdio.h:64:3: error: #error "Please include config.h first."
64 |  #error "Please include config.h first."
   |   ^


The lexed file conffile.lex.c seems to include some stuff before
config.h is included which is causing it to choke.

I'm not acquainted with lexers and not sure what causes this. I'd
appreciate any help.


Adding mentors list as well. If someone can help with this, that'd be great.

Best,
Nilesh



Hi,

I do not think the lexer has anything to do with this.

A quick look at the log suggests that the package is "rolling" its own 
"stdio.h" (note the "../../lib/stdio.h" in the error message).  Indeed, 
the full log has "mv stdio.h-t3 stdio.h" as well.


I believe that this is stdio.h is generated by the embedded gnulib copy 
and that is as far as I am willing to debug that rabbit hole. Based on 
the error, I assume gnulib's generated stdio.h requires the project 
specific "config.h" to be loaded first.


As for solving it, I would have a look at the "conffile.lex.c" file, see 
where it has its "#include" for stdio.h and then add an `include 
"config.h"` before that to see if it works (via a patch).


Hope that helps.

Best regards,
Niels

Re: dh_install by file suffix

[Niels Thykier]

Ole Streicher:

Hi again,

I think youe way could be to put the file list into a variable in 
d/rules, and expand the list the .install, like:


-- debian/iraf.install -
etc/iraf/
usr/lib/iraf/bin/ecl.e
[... other fixed content]
${env:IRAF_FILES}
8<--

--- debian/rules ---

override_dh_install:
 IRAF_FILES=$$(cd debian/tmp; \
     find usr/lib/iraf/pkg usr/lib/iraf/unix/hlib \
  -name \*.hlp \
   -o -name \*.hd \
   [...] \
   -o -name \*.fits) \
     dh_install

8<--

where the same procedure however would required for all four binary 
packages. This does not look very nice, and also according to the 
debhelper manpage, one can only expand to 4096 chars (I'd need ~40,000).


Any better idea?

Best

Ole


On 15.07.23 21:01, Ole Streicher wrote:

Hi,

I am upgrading one of my packages (iraf) to a new version. The new 
version comes with a "make install", which installs everything under 
/usr/lib/iraf/ (and some other places).


The "iraf" source package needs to divide these files into user 
related files (for the "iraf" and "iraf-noao" packages) and 
development related files (for "iraf-dev" and "iraf-noao-dev"). The 
problem is now, that the division is (mainly) by extension:


- *.cl, *.hd, *.men, *.par (... and some other extensions) should go to
   the user packages

- *.a, *.h should go to the development packages

(the "iraf" and "iraf-noao" package differ mainly by that "iraf" 
collects them in the pkg/ subdir, and "iraf-noao" in the noao subdir).


The main question here is: how can I do a dh_install selective by file 
suffix? Otherwise, I would need to list the (~1000) files in the 
"install" files, which is not very robust.


Cheers

Ole




Hi,

This would also not work as substitution is applied /after/ "word 
splitting". That is ${env:IRAF_FILES} would be treated as a single file 
(with a lot of spaces) even if you could do the expansion.


The order is deliberate as it is the way debhelper supports files with 
spaces (by using substitution variables to introduce them post split).


However, using dh-exec (as proposed elsewhere) might be an option as 
then the substitution happens before the split and dh-exec does not have 
the substitution limit either. I believe you can make dh-exec env 
variables as well. However, it has a different syntax then debhelper.


Alternatively, you can just make the .install executable in general and 
have it output what you want. That option also works.


Best regards,
Niels

Re: Free component in a non-free tarball

[Niels Thykier]

Andrius Merkys:

Hello,

[...]

My question: Is it OK to extract AmberTools from Amber tarball and
package for Debian main?

[1] https://ambermd.org/AmberTools.php
[2] https://ambermd.org/GetAmber.php#ambertools

Best,
Andrius



From the description you have provided, I would assume yes with the 
following assumptions:


 1) By "Extract AmberTools" you mean repackage the orig tarball.
 2) AmberTools consists entirely of open sourced files that have a
compatible license. Probably it does, but I would double check that
no non-free files made their way into AmberTools.

(Plus of course that AmberTools does not Depend or Build-Depend on any 
non-free components whether third-party or from ambermd.org)


For reference, I did not check the upstream site.

Thanks,
~Niels

Re: cmake: compat 11 vs 13 (-indep)

[Niels Thykier]

Niels Thykier:
> Mathieu Malaterre:
>> [cc me please]
>>
>> Symptoms:
>>
>> I've recently discovered the following change in behavior for
>> dh_missing + cmake + -indep. Basically using compat 13 it is now an
>> error when build-indep rule install stuff other than just the -indep
>> files (1).
>>
> 
> The error is not specifically caused by compat 13 but dh_missing
> --fail-missing. This happens to be default in compat 13. However, you
> can use "dh_missing --list-missing" in compat 13 to avoid the error (or
> use --fail-missing in compat 12 or earlier to reproduce the error there).
> 
> Depending on what you are going for, this may be sufficient.  You are
> not required to use debhelper at its default if they do not suit you.
> 
> Obviously, that does not solve the underlying issue with cmake/install.
>  I do not have an answer for that.
> 
> Thanks,
> ~Niels
> 

Having looked a bit more at the packaging involved, perhaps you can
solve this by replacing all the

 dh_install -p$(X) [...]

calls by moving the content into debian/X.install.  In compat 13, you
can do substitutions in debian/X.install now without relying on dh-exec.

This should enable dh_install to record what would have been installed
more reliably and maybe resolve the dh_missing issue you are seeing.

Thanks,
~Niels

Re: cmake: compat 11 vs 13 (-indep)

[Niels Thykier]

Mathieu Malaterre:
> [cc me please]
> 
> Symptoms:
> 
> I've recently discovered the following change in behavior for
> dh_missing + cmake + -indep. Basically using compat 13 it is now an
> error when build-indep rule install stuff other than just the -indep
> files (1).
> 

The error is not specifically caused by compat 13 but dh_missing
--fail-missing. This happens to be default in compat 13. However, you
can use "dh_missing --list-missing" in compat 13 to avoid the error (or
use --fail-missing in compat 12 or earlier to reproduce the error there).

Depending on what you are going for, this may be sufficient.  You are
not required to use debhelper at its default if they do not suit you.

Obviously, that does not solve the underlying issue with cmake/install.
 I do not have an answer for that.

Thanks,
~Niels

Re: Wrestling with debconf

[Niels Thykier]

Kip Warner:
> Hey list,
> 
> [...]
> The problem here is this re-running of the myfoo-server.config happens
> before the myfoo-server.postinst. This is bad because the latter is
> supposed to update the values in /etc/myfoo/server.conf to whatever the
> user just entered via debconf prompts.
> 
> Because myfoo-server.config's second invocation sees the newly unpacked
> /etc/myfoo/server.conf, it unintentionally seeds debconf with the
> values contained therein.
> 
> [...]
Hi,

(Having seen your enquiry on IRC, I presume this issue was still relevant)

I read the "newly unpacked /etc/myfoo/server.conf" as you shipping
"/etc/myfoo/server.conf" directly inside the package in that path.  If
that is correctly understood, then I think that is the source of your woes.

As I recall, when you manage a file via debconf, you should *not* ship
it directly in the package.  You can ship a template in a different
location (e.g., /usr/share/myfoo/server.conf.template) and then use that
combined with the debconf answers to generate the initial
/etc/myfoo/server.conf.

Perhaps have a look at openssh-server (postinst + config + file listing)
as an example, which does something similar.  It does use "ucf" for
handling the merge on updates, which is a different approach than yours
for creating/updating the configuration file.
  I can recommend that from a consistency PoV, so your package would
behave the same as other Debian packages if the user were to change the
file directly.  However, I do not think it would be strictly necessary
to migrate to ucf in order to fix your immediate issue.

I hope that helps.

Thanks,
~Niels

Bug#996592: RFS: workflow/0.9.8-1 [ITP] -- Parallel computing and asynchronous web server engine

[Niels Thykier]

Bastian Germann:
> Hi Lance,
> 
> [...]
> 
> You should not need to build depend on dh-exec with debhelper 13.
> 
> Cheers,
> Bastian
> 

Drive by remark/clarification:

 * If you use dh-exec then you need to Build-Depend on it regardless of
   debhelper compat level.

 * With compat 13, debhelper provides a *subset* of the dh-exec and you
   /may/ be able to replace your use of dh-exec with debhelper compat 13
   features.  In this case, you should remove the build dependency on
   dh-exec.

I think Bastian's remark was alluding towards my second bullet but I
feared it might be misread as "just drop the build dependency".

Thanks,
~Niels

Bug#993552: RFS: proton-caller/2.3.2-1 [ITP] -- Run any Windows program through Proton

[Niels Thykier]

BenTheTechGuy:
>> [...]
>>   debian/rules is missing a lot of functionality: mandatory targets like
>>   {build,binary}-arch; passing build flags, handling cross builds, etc.
>>   All of this would be much better done with dh (like the vast majority
>>   of packages in Debian do) -- it does know how to use cargo, etc.
>>   Likewise, there's no need to run install by hand.
> 
> I can't get it to work without manually telling dh_build to run cargo.
> If someone can point me in the right direction of how to format my
> debian/rules to build with cargo then put binaries, config files, and
> such in the right place (there is nothing about that in Cargo.toml)
> that would be very helpful.
> 
> Thank you so much Adam for helping me get some things straightened
> out, the latest upload
> https://mentors.debian.net/debian/pool/main/p/proton-caller/proton-caller_2.3.2-2.dsc
> fixes all the problems you pointed out!
> 

Indeed, the core debhelper tool stack does *not* support cargo out of
the box.  There is a `dh-cargo` add-on that may (or may not) be helpful.

>From a quick look, it should be a better of "Build-Depends: dh-cargo"
and then passing --buildsystem=cargo to dh (or to each of the dh_auto_*
tools).  But I have never used it and I could not spot any obvious
"getting started" documentation for it.

I hope that was useful as a "drive-by remark".

~Niels

Re: Conflicts does not remove old package

[Niels Thykier]

Hilmar Preuße:
> Hi,
> 
> we got https://bugs.debian.org/978431 telling that the upgrade from
> buster to sid fails. This is also visible in piuparts [1].
> 
>   Unpacking texlive-base (2020.20201203-2) over (2018.20190227-2) ...
>   dpkg: error processing archive
> /tmp/apt-dpkg-install-K7a7FC/07-texlive-base_2020.20201203-2_all.deb
> (--unpack):
>    trying to overwrite
> '/usr/share/doc/texlive-doc/generic/iftex/iftex.pdf', which is also in
> package texlive-plain-generic 2018.20190227-2
>   dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
>   Selecting previously unselected package texlive-plain-generic.
>   dpkg: considering deconfiguration of texlive-base, which would be
> broken by installation of texlive-plain-generic ...
>   dpkg: yes, will deconfigure texlive-base (broken by
> texlive-plain-generic)
> 
> When looking at the package texlive-base it already declares a
> 
> Conflicts: (...) texlive-plain-generic (<< 2020.20200417).
> 
> Hence I'd expect that old texlive-plain-generic is removed before the
> new texlive-base is installed. What are we doing wrong here?
> 
> Hilmar
> 
> [1]
> https://piuparts.debian.org/stable2sid/fail/texlive-plain-generic_2020.20201129-2.log
> 

If you move files between packages (which appears to be the case here),
then you need Breaks + Replaces to avoid that error.  In the example
given, it would be something like:

Breaks: (...) texlive-plain-generic (<< 2020.20200417)
Replaces: (...) texlive-plain-generic (<< 2020.20200417)

Yes, it is WET but that is sadly the way.  Conflicts is *not* sufficient
- never has been and never will be.

~Niels

Bug#976180: RFS: libzc/0.4.3-1 -- Command line tool for the libzc library

[Niels Thykier]

Marc Ferland:
> On Sun, Dec 6, 2020 at 6:24 AM Niels Thykier  wrote:
> 
>> Niels Thykier:
>>> [...]
>>>
>>> Thanks, I have uploaded it to unstable.
>>>
>>> ~Niels
>>>
>>
>> Hi Marc,
>>
>> Because this libzc renamed a binary, the upload had to go through NEW.
>> This in turn implied that I had to do a binary upload and the upload
>> will not migrate to testing without a new source-only upload.
>>
>> I can either do that "no change version bump" NMU with your permission
>> or alternatively you can provide me with another update to sponsor (if
>> you have any pending changes or want to wait a bit).  In the latter
>> case, please keep the freeze deadlines in mind[1].
>>
>> Go ahead and make the "no change version bump".
> 
> Thanks,
> 
> Marc
> 

Ok. :) Turns out we could just solve with a binNMU because there was no
arch:all package, so I have arranged for that solution instead. :)

~Niels

Bug#976180: RFS: libzc/0.4.3-1 -- Command line tool for the libzc library

[Niels Thykier]

Niels Thykier:
> [...]
> 
> Thanks, I have uploaded it to unstable.
> 
> ~Niels
> 

Hi Marc,

Because this libzc renamed a binary, the upload had to go through NEW.
This in turn implied that I had to do a binary upload and the upload
will not migrate to testing without a new source-only upload.

I can either do that "no change version bump" NMU with your permission
or alternatively you can provide me with another update to sponsor (if
you have any pending changes or want to wait a bit).  In the latter
case, please keep the freeze deadlines in mind[1].

~Niels

[1]: https://release.debian.org/bullseye/freeze_policy.html

Re: dh_testroot: error: Package needs targeted root but builder has not provided a gain-root command via ${DEB_GAIN_ROOT_CMD}

[Niels Thykier]

Andreas Tille:
> Control: tags -1 pending
> 
> Hi,
> 
> upstream of fis-gtm package[1] confirmed that the build needs some root
> permissions.  Thus I've set
> 
>Rules-Requires-Root: yes
> 
> When trying to build with pbuilder I get:
> 
>dh_testroot
> dh_testroot: error: Package needs targeted root but builder has not provided 
> a gain-root command via ${DEB_GAIN_ROOT_CMD}
> make: *** [debian/rules:21: binary] Error 25
> 
> 
> How can this be fixed?
> 
> Kind regards
> 
>   Andreas.
> 
> 
> [1] https://salsa.debian.org/med-team/fis-gtm
> 


You want "Rules-Requires-Root: binary-targets".

~Niels

Bug#976180: RFS: libzc/0.4.3-1 -- Command line tool for the libzc library

[Niels Thykier]

Niels Thykier:
> Control: tags -1 moreinfo
> 
> Marc Ferland:
>> Package: sponsorship-requests
>> Severity: normal
>>
>> Dear mentors,
>>
>> [...]
>>
>> Changes since the last upload:
>>
>>  libzc (0.4.3-1) unstable; urgency=low
>>  .
>>* New upstream release.
>>* New Dockerfile to simplify debian releases.
>>* Removed zc_file_info_offset() function from API.
>>* Added two new functions to the API: zc_file_info_offset_begin() and
>>  zc_file_info_offset_end().
>>* ABI change libzc4 -> libzc6
>>* Added the possibility to specify the filenames instead of the
>>  offsets in the plaintext cracker in yazc tool.
>>* Added the -S option to the plaintext cracker to print time stats.
>>
>> Regards,
>> --
>>   Marc Ferland
>>
> 
> Hi Marc,
> 
> 
> I found a few issues I would like to see resolved before I will sponsor
> the upload.
> 
> 
> [...]
>
> SONAME bump
> ===
> 
> The library changes SONAME and there is no mention of it.

I take that back, there is a mention in the changelog.  However, the
following part:

> This requires
> a transition if the package has reverse dependencies, but there is no
> comment from you on whether you have started the relevant transition
> procedures or that they are irrelevant because your package has no
> reverse dependencies in unstable and testing.
> 

still stands and still needs an answer.


Apologies for the oversight on my part in my first answer.

~Niels

Bug#976180: RFS: libzc/0.4.3-1 -- Command line tool for the libzc library

[Niels Thykier]

Control: tags -1 moreinfo

Marc Ferland:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> [...]
> 
> Changes since the last upload:
> 
>  libzc (0.4.3-1) unstable; urgency=low
>  .
>* New upstream release.
>* New Dockerfile to simplify debian releases.
>* Removed zc_file_info_offset() function from API.
>* Added two new functions to the API: zc_file_info_offset_begin() and
>  zc_file_info_offset_end().
>* ABI change libzc4 -> libzc6
>* Added the possibility to specify the filenames instead of the
>  offsets in the plaintext cracker in yazc tool.
>* Added the -S option to the plaintext cracker to print time stats.
> 
> Regards,
> --
>   Marc Ferland
> 

Hi Marc,


I found a few issues I would like to see resolved before I will sponsor
the upload.


Changelog
=

I see the following changes since 0.4.1-1 that I cannot find documented
in debian/changelog:

 * Rules-Requires-Root has been set to "no"

 * Multi-Arch has been set to same for two binary packages.

 * Standards-Versions has been bumped to 4.5.0

Please document these in the 0.4.3-1 changelog.


_Pedantic_ side note: It is custom to only mention uploads that have
been uploaded in the debian/changelog.  As 0.4.2-1 was never in Debian
unstable (and I presume in no other distro as well given it says
"unstable") then it should have been omitted.

SONAME bump
===

The library changes SONAME and there is no mention of it.  This requires
a transition if the package has reverse dependencies, but there is no
comment from you on whether you have started the relevant transition
procedures or that they are irrelevant because your package has no
reverse dependencies in unstable and testing.


In #902476, I have exempted you from some of these requirements
previously on the basis that I wanted you to do them correctly next time
(which would be now). :)

~Niels

Re: No "linux-all" architecture wildcard

[Niels Thykier]

Christoph Biedl:
> Hello,
> 
> while packaging something that makes sense on Linux only, but one of the
> built packages is architecture-*in*dependent while depending on some
> of the linux-any ones - in other words, that arch-indep package makes
> no sense on non-linux ...
> 
> The obivous way to declare architecture-all-but-linux-only binary
> packages was
> 
> | Architecture: linux-all
> 
> [...]

Have you tried "linux-any", which would match "any" as the default
wildcard for any architecture specific binary package (vs. "all", which
really means "architecture independent")?

~Niels

Re: sbuild & cross build

[Niels Thykier]

Hilmar Preuße:
> Am 15.04.2020 um 02:45 teilte Wookey mit:
>> On 2020-04-15 00:02 +0200, Hilmar Preuße wrote:
> 
> Hi,
> 
> Thanks for the answer Wookey!
> 
> [...]
> Anyway: we have build failures of texlive-bin on sparch64/powerpc very
> likely b/c there are too many build threads called in parallel. I would
> not have been able to reproduce this issue on my box as my Oracle VBox
> VM has only one CPU. ;-)
> We need to reduce the # of threads on sparc64 & powerpc. Second try
> looks like this:
> 
> NO_MASSIVE_PARALLEL_BUILD := powerpc ppc64 sparc64
> 
> ifneq (,$(filter $(DEB_HOST_ARCH), $(NO_MASSIVE_PARALLEL_BUILD)))
> DEB_BUILD_OPTIONS=parallel=8
> endif
> 
> This works fine, but now I have a lintian warning:
> 
> W: texlive-bin source: debian-rules-sets-DEB_BUILD_OPTIONS line 68
> 
> I also tried "MAKEFLAGS += -j8" inside the if statement, but the option
> was ignored.
> 
> How do I implement the Debian way? Thanks!
> 
> Hilmar
> 

Have you tried to pass --max-parallel=... to dh or the relevant
dh_auto_* helper?


~Niels

Re: dh_dwz failure

[Niels Thykier]

PICCA Frederic-Emmanuel:
> Hello, I am woriking on a new package called bornagain.
> 
> I switched to compat level 12 and now I have this error message.
> I do not know how to fix this ?
> 
> thanks for your help.
> 
> Frederic
> 
>dh_dwz
>   install -d debian/bornagain/usr/lib/debug/.dwz/x86_64-linux-gnu
>   dwz -q 
> -mdebian/bornagain/usr/lib/debug/.dwz/x86_64-linux-gnu/bornagain.debug 
> -M/usr/lib/debug/.dwz/x86_64-linux-gnu/bornagain.debug -- 
> debian/bornagain/usr/bin/bornagain 
> debian/bornagain/usr/lib/bornagain/_libBornAgainCore.so 
> debian/bornagain/usr/lib/bornagain/_libBornAgainFit.so 
> debian/bornagain/usr/lib/bornagain/_libBornAgainGUI.so
> dwz: debian/bornagain/usr/lib/bornagain/_libBornAgainGUI.so: Couldn't find 
> DIE referenced by DW_OP_GNU_parameter_ref
> dh_dwz: dwz -q 
> -mdebian/bornagain/usr/lib/debug/.dwz/x86_64-linux-gnu/bornagain.debug 
> -M/usr/lib/debug/.dwz/x86_64-linux-gnu/bornagain.debug -- 
> debian/bornagain/usr/bin/bornagain 
> debian/bornagain/usr/lib/bornagain/_libBornAgainCore.so 
> debian/bornagain/usr/lib/bornagain/_libBornAgainFit.so 
> debian/bornagain/usr/lib/bornagain/_libBornAgainGUI.so returned exit code 1
> 

Looks similar to the very recently fixed #932019 (except the
architecture note in subject).  Did this failure occur with the new
version of dwz?

Thanks,
~Niels

Re: Elastix: dh_testroot: You must run this as root (or use fakeroot).

[Niels Thykier]

Andreas Tille:
> Hi,
> 
> I intend to upgrade elastix[1] but I'm running into:
> 
> 
> ...
> [100%] Built target itkMevisDicomTiffImageIOTest
> make[2]: Leaving directory '/build/elastix-4.9.0/obj-x86_64-linux-gnu'
> /usr/bin/cmake -E cmake_progress_start 
> /build/elastix-4.9.0/obj-x86_64-linux-gnu/CMakeFiles 0
> make[1]: Leaving directory '/build/elastix-4.9.0/obj-x86_64-linux-gnu'
>create-stamp debian/debhelper-build-stamp
>  fakeroot debian/rules binary
> dh binary-arch --no-parallel
> ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be 
> preloaded (cannot open shared object file): ignored.
> ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be 
> preloaded (cannot open shared object file): ignored.
>dh_testroot -a -O--no-parallel
> ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be 
> preloaded (cannot open shared object file): ignored.
> dh_testroot: You must run this as root (or use fakeroot).
> make: *** [debian/rules:12: binary-arch] Error 255
> dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned 
> exit status 2
> 
> 
> I was able to build this package today with minor changes (on a
> different machine but always in up to date pbuilder chroot).  Any
> idea what might be wrong here?
> 
> Kind regards
> 
>Andreas.
> 
> 
> [1] https://salsa.debian.org/med-team/elastix
> 

Hi Andreas,

Basically, fakeroot fails to load itself properly (that is the
LD_PRELOAD warnings).  I am not sure why though and it might be worth
figuring out what goes wrong there.

Note that you can also use "Rules-Requires-Root: no" in d/control
assuming the package in fact does not need (fake)root (many does not but
some do).  That should side-step the entire issue for this package
(although if you have a broken fakeroot, you will probably run into this
issue again later with a different package).

Thanks,
~Niels

Re: nodoc solution HOWTO -- Avoid building Sphinx documentation on request (was: Bug#905750: RFS: elpy/1.23.0-1)

[Niels Thykier]

Nicholas D Steeves:
> Hi Ben and readers of debian-mentors,
> 
> Solution at bottom.
> 
> [...]
> 
> "export DEB_BUILD_PROFILES=nodoc ; gbp buildpackage" does not work,
> although I expect "DEB_BUILD_PROFILES=nodoc ; export
> DEB_BUILD_PROFILES ; gbp buildpackage" should.
> 

Rather, I think there is a typo in changes.

> ---
>  debian/changelog | 6 ++
>  debian/control   | 4 ++--
>  debian/rules | 8 +++-
>  3 files changed, 15 insertions(+), 3 deletions(-)
> 
> [...]
> diff --git a/debian/rules b/debian/rules
> index a9d70b4..bd4c218 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -11,7 +11,13 @@ export LC_ALL
>  # docs are not generated without this override
>  override_dh_auto_build:
>   dh_auto_build
> - PYTHONPATH=. sphinx-build -N -bman docs/ build/man # Manpage generator
> +# support the nodoc build profile
> +ifneq ($(filter nodocs,$(DEB_BUILD_PROFILES)),)
   ^^

nodocs != nodoc

> + echo -e "\nnodoc build profile enabled, therefor not building docs.\n"
> +else
> + PYTHONPATH=. sphinx-build -N -bman docs/ build/man
>   PYTHONPATH=. sphinx-build -N -btexinfo docs/ build/info
>   makeinfo --no-split build/info/Elpy.texi -o build/info/elpy.info
>   cat NEWS.rst debian/local-var-snippet > build/NEWS
> +endif
> +
> 

Thanks,
~Niels

Bug#902225: RFS: ii/1.8-1

[Niels Thykier]

itd:
> Hi,
> 
> thanks for the review!
> 
> Niels Thykier:
>> # The remark:
> Oops! Fixed, thanks. (Updated Build-Dependency on debhelper.)
> 

Ack. :)

>>  * Relicense the patches to the same as upstream (requires approval from
>>the previous maintainer).  We already spoke about this on IRC.
> Previous maintainer approves (see #902225 message #23). (@Nico: Thanks!)
> (Updated d/copyright.)
> 

Excellent.  For good measure, please document this in the changelog.
Mostly so it is obvious to people who were not following along on these
bugs (and to help ourselves if we are asked to explain it later)

On a related note, there is a minor but relevant mistake in the
debian/copyright file:

"""
Files: *
   debian/patches/*
[...]
License: MIT

Files: debian/*
[...]
License: GPL-2
"""

The problem is that the "debian/*" overshadows the debian/patches/*
entry.  According to the copyright file, debian/patches/* are still
under the GPL-2.
  This is caused by how the copyright file is read.  I a bit surprised
that lintian did not give any warnings about this (it does for some
similar cases), so I have filed #905747 to improve the situation.

>> [... other suggestions ...]
> Done.
> 

:)

>>  * Have you considered setting up a git repository for the packaging on
>>salsa.debian.org?
> Yes. I'm currently using https://salsa.debian.org/itd-guest/ii.
> It has restricted ("internal") visibility, since it's not official. I
> couldn't find a previous repository. "gbp import-dscs --debsnap ii" was
> used to import previous package versions (IIRC).
> 

A good idea for bootstrapping a git repo. :)  Given that you are (about
to be) the official maintainer for ii, please make it public and then
you can add the Vcs-Git + Vcs-Browser fields in debian/control as well. :)
  Alternatively, we can add a "debian/ii" repo that you can work in if
you think that would be better.  (But I do not think it is worth
stalling the upload for that.  Uploads are cheap so we can always do
another one for that)

On a related note, as Axel mentioned, Nico has retired from Debian.
Please replace him with yourself in the Maintainers field (and drop the
Uploaders field).  :)

These bits are less critical and can wait till a later upload if you prefer.

> # Other changes
> * use libbsd-dev to provide strlcpy(3) and exclude "strlcpy.c"
> * apply upstream patch that adds additional user input validation
> 

Excellent. :)

> Thanks again!
> 
> Regards,
> itd
> --
> $ head -n 17 debian/changelog
> [...]
> 


Once again, thanks for working on improving Debian, :)
~Niels

Bug#902225: RFS: ii/1.8-1

[Niels Thykier]

Control: tags -1 moreinfo -pending

On Sat, 23 Jun 2018 15:09:00 + itd  wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> @Nico: I added myself to Uploaders. Please shout, if that is not what
> you meant in #890995 [1].
> 
> [...]
> 
> Changes since the last upload:
> 
>   * New upstream release (Closes: #890995).
>   * Fix watchfile (upstream URL changed).
>   * Bump compat level and debhelper dependency to 11.
>   * Bump standards version to 4.1.4.
>   * Update patch respect_dpkg_buildflags.patch.
>   * Enable hardening (requires dpkg-dev >= 1.16.1.1).
>   * Switch to machine-readable copyright file.
>   * Experimental autopkgtest smoke-test.
>   * Switch to HTTPS upstream links.
>   * Add myself to Uploaders.
> 
> 
> Regards,
> itd
> 
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890995#10
> 

Hi,

Thanks for working on improving Debian. :)

I had a look at reviewing your package; I got one question/remark before
I sponsor it and then some optional suggestions for improvements.

# The remark:

In debian/rules, I noticed the following line:
"""
  rm -f =$(CURDIR)/debian/ii/usr/share/doc/ii/CHANGES
"""

It seems strange that there would be a valid path starting with "=", so
I am guessing that is a typo (AFAICT, left-over from previous versions
of ii).

To be honest, I think the line can be removed if you call
dh_installchangelogs *without* the CHANGES argument and bump the
Build-Dependency on debhelper to "debhelper (>= 11.3.2~)".  As of that
version of debhelper, dh_installchangelogs should do what you want out
of the box.  (This fix though is optional; fixing the above typo is also
a valid solution)

# Optional suggestions:

These are suggestions that I think would make your package better,
easier to maintain in the long turn or otherwise improve it.  These can
be done in a separate upload.

 * Relicense the patches to the same as upstream (requires approval from
   the previous maintainer).  We already spoke about this on IRC.
   - If / when the previous maintainer approves it, it is simply a
 question of updating the debian/copyright to reflect the special
 license for debian/patches/*

 * Set [Rules-Requires-Root] to "no" as the source package does not need
   (fake)root to build the .debs.  It is a one-line change to the
   debian/control file.
   (see attached debdiff)

 * Use debhelper's dh_auto_* tools instead of calling $(MAKE) to support
   cross-building.  Literally no additional changes will be required
   (see attached debdiff).

 * Consider rewriting debian/rules into a "dh7" style rules file.
   (see [rules.tiny] for a basis example to build on).  This will have
   the advantage that dh can skip some helpers automatic if there is
   nothing to do and new helpers will be enabled automatically in new
   compat levels.
   - It might be useful to postpone this change to a later revision.
 Especially if you have never worked with dh(1) before.

 * Have you considered setting up a git repository for the packaging on
   salsa.debian.org?

# Summary:

Once you have resolved the remark about a typo in d/rules, I am happy to
sponsor the package.  The optional suggestions can be done either now or
in later revisions.

Thanks,
~Niels

[Rules-Requires-Root]:
https://www.debian.org/doc/debian-policy/ch-controlfields.html#rules-requires-root

[rules.tiny]:
/usr/share/doc/debhelper/examples/rules.tiny

You will probably also need to read "man dh" to learn about "OVERRIDE
TARGETS".  The dh manpage contains examples for how to use these
override targets.

diff -Nru ii-1.8/debian/control ii-1.8/debian/control
--- ii-1.8/debian/control   2018-06-23 10:49:42.0 +0200
+++ ii-1.8/debian/control   2018-08-08 11:16:33.0 +0200
@@ -6,6 +6,7 @@
 Build-Depends: debhelper (>= 11~), dpkg-dev (>= 1.16.1.1)
 Standards-Version: 4.2.0
 Homepage: https://tools.suckless.org/ii/
+Rules-Requires-Root: no
 
 Package: ii
 Architecture: any
diff -Nru ii-1.8/debian/rules ii-1.8/debian/rules
--- ii-1.8/debian/rules 2018-06-23 10:49:42.0 +0200
+++ ii-1.8/debian/rules 2018-08-08 11:16:33.0 +0200
@@ -12,7 +12,8 @@
dh_testdir
 
# Building package
-   CFLAGS="$(CFLAGS)" $(MAKE) PREFIX=/usr
+   #CFLAGS="$(CFLAGS)" $(MAKE) PREFIX=/usr
+   dh_auto_build
 
touch build-stamp
 
@@ -22,7 +23,8 @@
rm -f build-stamp
 
# Cleaning package
-   [ ! -f Makefile ] || $(MAKE) clean
+   #[ ! -f Makefile ] || $(MAKE) clean
+   dh_auto_clean
 
dh_clean
 
@@ -33,7 +35,8 @@
dh_installdirs
 
# Installing package
-   $(MAKE) install DESTDIR=$(CURDIR)/debian/ii PREFIX=/usr
+   #$(MAKE) install DESTDIR=$(CURDIR)/debian/ii PREFIX=/usr
+   dh_auto_install -- PREFIX=/usr
rm -f =$(CURDIR)/debian/ii/usr/share/doc/ii/CHANGES
 
# Removing double files

Re: Bug#891890: ITP: zfs-linux-git -- zfsonlinux packaging tracking git master

[Niels Thykier]

Antonio Russo:
> On 6/22/18 4:17 AM, Fabian Grünbichler wrote:
>>
>> as promised, and unfortunately delayed a bit longer than I wanted.
>> thanks for the initial push - some of the points are more for a
>> discussion with upstream regarding their inclusion of some variant of
>> this, some are for debian experimental.
>>
>> - compat 12 is IMHO too new for anything except experimental, it's still
>>   subject to change.
> 
> dh_missing was added in debhelper 10.3. I'll remove the use, and suffer
> the deprecation warning.
> 
> [...]

You can use dh_missing with a simple "debhelper (>= 10.3~)" in
Build-Depends in any compat level.  Though in compat level 11 (or
earlier) you will have to explicitly ask dh_missing to do something
(e.g. by using "dh_missing --list-missing").


Thanks,
~Niels

Re: cmake packages fail to build since yesterday even if package has build before

[Niels Thykier]

Mattia Rizzolo:
> On Sun, Apr 08, 2018 at 10:25:44AM +0200, Andreas Tille wrote:
>> since yesterday packages using cmake are failing.
>> Nothing inside libbpp-seq was changed that should affect the build
>> process.  I have the same problem with other cmake based packages.
>>
>> Any clue what might go wrong here?
> 
> Debhelper did a bit of a refactoring of the cmake build system, and here
> you have a debhelper bug :)  https://bugs.debian.org/895181
> 

I have given back the failed builds with a extra dependency on
debhelper/11.2.1.  The build should be retried within the next couple of
hours.

Thanks,
~Niels

Re: Why debian use postinst for declarative actions?

[Niels Thykier]

George Shuklin:
> On 05/03/18 14:35, Paul Wise wrote:
>> On Mon, Mar 5, 2018 at 7:08 PM, George Shuklin wrote:
>>
>>> There is a big question with torture me for awhile. Why some purely
>>> declarative operations are performed by non-standard postinst scripts?
>> Probably dpkg doesn't support declarative mechanisms for those things.
>>
>> Some of them have standardised snippets from debhelper.
> 
> Well, I understand that.
> 
> I rephrase my question:  Is this a well-thought decision or it's because
> "no one done this"? Is there some kind of opposition to (partially)
> declarative format for debs?
> 

Hi,

You may find the following Debian wiki page interesting:
 * https://wiki.debian.org/Teams/Dpkg/Spec/DeclarativePackaging

Thanks,
~Niels

Bug#881946: RFS: keychain/2.8.4+dfsg-1 [ITA]

[Niels Thykier]

Control: tags -1 moreinfo

Paulo Ricardo Paz Vital:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> [...]

Hi,

I have done an initial review of the changes and I have a few remarks.
Please CC me directly on any follow ups to this bug.

> 
> Changes since the last upload:
> 
> keychain (2.8.4+dfsg-1) unstable; urgency=medium
> 
>   * New upstream release
>   * Set DFSG build since the upstream tarball have changed a lot
  

The "dfsg" marker is used solely for the purpose of removing non-free
parts or parts with missing licensing terms.  However, it is not clear
to me with the current wording whether this is the reason why we use
"dfsg" here.

Were the files removed under a non-free license (or missing a license)?

 * If yes, then please use that argument in the changelog a la:
   "Repacked the source package to removed some non-free files"
   (Feel free to adapt the wording)

 * If no, then please either reconsider the repacking or use the "ds"
   (short for "debian source") marker instead of "dfsg"[0].

=> This is my only "blocking" concern.

> [...]
> 
>  -- Paulo Vital   Thu, 16 Nov 2017 11:50:24 -0200
> 
> 
>   Regards,
>Paulo Vital
> 

Beyond my concern above, I also have a few suggestions for some
improvements to the packaging:

 * In debian/uscan-dfsg-clean.sh: Please use "-n" (e.g. "gzip -9n") to
   avoid adding an unnecessary and non-deterministic timestamp to the
   file.

 * debian/dirs: This file appears to be redundant as I can successfully
   build keychain without it.  I am sure it made sense long ago and no
   one discovered until now that it is no longer necessary. :)

 * debian/docs: I am not sure it makes sense to install keychain.pod as
   it is basically used to generate the manpage.  (I know you did not
   introduce this change; I just noticed it and thought it would make
   sense to bring it up).

 * The keychain package can build without using (fake)root.
   Please consider setting "Rules-Requires-Root: no" in d/control in
   the "Source" stanza.
   - It requires no changes to (Build-)Depends in keychain (even if you
 intend to backport keychain to stable once 2.8.4 hits testing)


... and some suggestions regarding the upstream code:

 * Makefile: Upstream uses "gzip -9" (without -n) which /would/ cause
   keychain to become "unreproducible"[1].  However, I suspect that
   dh_installman happens to save us as a side effect.
   - Please consider asking upstream to use "-n" with gzip to ensure
 that their build is natively reproducible.

None of these suggestions are mandatory for getting keychain updated.

Thanks,
~Niels

[0]
https://wiki.debian.org/DebianMentorsFaq#What_does_.2BIBw-dfsg.2BIB0_or_.2BIBw-ds.2BIB0_in_the_version_string_mean.3F

[1] https://reproducible-builds.org/



signature.asc
Description: OpenPGP digital signature

Bug#881946: RFS: keychain/2.8.4+dfsg-1 [ITA]

[Niels Thykier]

Control: owner -1

On Thu, 16 Nov 2017 18:45:58 -0200 Paulo Ricardo Paz Vital
 wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "keychain"
> 
>  * Package name: keychain
>Version : 2.8.4+dfsg-1
>Upstream Author : Daniel Robbins
>  * URL : http://www.funtoo.org/Keychain
>  * License : GPL-2
>Section : net
> 
> [...]
> 
> keychain (2.8.4+dfsg-1) unstable; urgency=medium
> 
>   * New upstream release
>   * Set DFSG build since the upstream tarball have changed a lot
>   * Updated debhelper dependecy to be >= 10
>   * Updated compat to version 10
>   * Updated Standards-Version to 4.1.1
>   * Updated Priority to optional
>   * Set Multi-Arch as foreign
>   * Added debian/watch and uscan script to get releases from GitHub
>   * New maintainer. Closes: #867749
> 
>  -- Paulo Vital   Thu, 16 Nov 2017 11:50:24 -0200
> 
> 
>   Regards,
>Paulo Vital
> 
> 

I will have a look at this. :)

Thanks for considering to adopt the keychain package :)
~Niels

Re: dh_installdocs --link-doc not allowed between arch dep & arch indep?

[Niels Thykier]

أحمد المحمودي:
> Hello
> 
> The package pcb builds 2 arch. dependent packages (pcb-gtk & pcb-lesstif) and 
> an arch independent package (pcb-common) which contains data and 
> documentation. Hence the arch. dependent packages depend on this arch 
> independent package. 
> 
> Previously I ran:
> dh_installdocs --link-doc=pcb-common 
> 
> which worked fine, yet after updating to compat level  10, I get the build 
> error:
> 
> dh_installdocs: --link-doc not allowed between pcb-gtk and pcb-common (one is 
> arch:all and the other not)
> 
> I checked the manpage which mentions that a link from arch. dependent to 
> arch. independent will not work, what is the reason for this? Especially that 
> my use case seems very sensible. Is there a workaround? 
> 
> Please reply me directly since I am not subscribed to the list.
> 

Hi,

Please note that --link-doc between arch:any and arch:all does not
actually work (correctly) in compat 9 either.  You get silent breakage
in some cases (notably binNMUs).  The primary difference is that compat
10 stops you from doing it.


Please see the following link for a longer description:
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767839#43

Thanks,
~Niels

Re: Package not migrating

[Niels Thykier]

Ole Streicher:
> Hi Nils,
> 

Hi,

> Niels Thykier <ni...@thykier.net> writes:
>> Ole Streicher:
>>> Andrey Rahmatullin <w...@debian.org> writes:
>>>> On Thu, Aug 17, 2017 at 08:42:37PM +0200, Ole Streicher wrote:
>> The package is affected by the same issue that chocolate-doom was in the
>> referenced bug (#824169).  The situation in summary:
>>
>>  * The source produces 1 or more binaries in "main" and 1 or more
>>binaries in "contrib"
>>
>>  * During upload, dak can (mistakenly) end up putting the source in
>>both main and contrib at the same time.  Technically, it ends up in
>>different suites (unstable vs unstable-debug), but these suites have
>>to agree.
> 
> Can't they be rmeoved manually here? Or with a dirty script as a workaround?
> 

No clue; I do not understand the technical details of the problem except
what I already wrote.

Based on the rest of your mail, I suspect I should clarify that I wrote
the mail to assist you with understand the problem.  However, I have
very little Debian-related time/energy, so please forgive my lack of
activity in relation to this problem.

If you want this resolved in any timely fashion, your best bet is to
engage with the relevant parties.

>>  * Once britney requests dak to migrate the package to testing, dak
>>will notice the issue and reject the import (resulting in a
>>rollback of all changes to testing).
>>
>>  * The quickest way to untangle the situation is to block the affected
>>package (i.e. ensure britney will not migrate it), so other packages
>>can migrate to testing.  This is most likely why cpl is now blocked
>>by a manual hint.
> 
> But this will prevent from fixing bugs of the package in testing, [...]

Correct.

> The solution to block packages which are
> perfectly fine seems to be a quick, but also a dirty solution.
> 

It is a work around.  The release team have to choose between holding
testing hostage to this bug or just hold the package hostage (and
possibly related packages).  As the latter is a vastly smaller subset of
the former, this is a rather trivial choice.

> [...]
> (And, shouldn't the affected packages be tagged as "affects" in the bug?)
> 

I think you would be quite justified to add that relation.

> I am also wondering why this did not happen before? The cpl package
> structure is unchanged since years, without any reported problems.
> 

I think the problem is non-deterministic.

>> With the situation clarified, here is how it can be fixed:
>>
>>  1a. Have dak patched so it does not do this again.  Depending on the
>>  exact implementation, it may need to be combined with 2).  Once
>>  that is resolved, it will also need 3)
> 
> Which is nothing where I could do much, due to my non-existing dak knowledge.
> 

I listed it as a possible solution in case you (or someone else on the
list) felt like challenge to improve our infrastructure tools.  It is
fine if no one are up to for the challenge; it just means we will live
with this bug in dak a while longer. :)

> [...]

>>  1c. *Maybe* the FTP masters can work around this (I don't remember)
>>  on their side on a per package basis.  This will need to be
>>  combined with 2) (although, the FTP masters will probably do it
>>  as the same time as this item) + 3).
> 
> So, this seems to be the way to go, right? Shall I just open a bug for
> ftp-masters asking for unblock? Or what should I do here?
> 
> Best regards
> 
> Ole
> 

Please contact the FTP team saying that your package is also affected by
#824169 and (with them) figure out how to solve it.  But most likely,
you will get a work around (one way or another) in the absence of a
volunteer to fix dak.

/Once/ that is solved, contact the release team to remove the work
around we applied.

Thanks,
~Niels

Re: Package not migrating

[Niels Thykier]

Ole Streicher:
> Andrey Rahmatullin  writes:
>> On Thu, Aug 17, 2017 at 08:42:37PM +0200, Ole Streicher wrote:
>>> * Not touching package due to block request by adsb (check
>>>   https://release.debian.org/testing/freeze_policy.html if update is
>>>   needed) 
>> https://release.debian.org/britney/hints/adsb:
>> # 20170720
>> # in both main and contrib, breaks britney / dak
>> # (#824169)
>> block cpl
> 
> And what should I do to get it migrated?
> 
> Best
> 
> Ole
> 

The package is affected by the same issue that chocolate-doom was in the
referenced bug (#824169).  The situation in summary:

 * The source produces 1 or more binaries in "main" and 1 or more
   binaries in "contrib"

 * During upload, dak can (mistakenly) end up putting the source in
   both main and contrib at the same time.  Technically, it ends up in
   different suites (unstable vs unstable-debug), but these suites have
   to agree.

 * Once britney requests dak to migrate the package to testing, dak
   will notice the issue and reject the import (resulting in a
   rollback of all changes to testing).

 * The quickest way to untangle the situation is to block the affected
   package (i.e. ensure britney will not migrate it), so other packages
   can migrate to testing.  This is most likely why cpl is now blocked
   by a manual hint.

With the situation clarified, here is how it can be fixed:

 1a. Have dak patched so it does not do this again.  Depending on the
 exact implementation, it may need to be combined with 2).  Once
 that is resolved, it will also need 3)

 1b. Avoid having a source package that builds binaries in multiple
 components.  Sadly, this often implies duplicating the majority
 of the source package.  Combine with 2) + 3)

 1c. *Maybe* the FTP masters can work around this (I don't remember)
 on their side on a per package basis.  This will need to be
 combined with 2) (although, the FTP masters will probably do it
 as the same time as this item) + 3).

 2. Have the FTP masters clean up the old version that is in multiple
components at the same time.

 3. Ask the release team to remove the block hint now that the situation
is fixed (and attempting to migrate cpl will no longer force a
rollback)

Hope that clarified the situation.

Thanks,
~Niels

Re: HELP: Fixing a debconf bug in proftpd

[Niels Thykier]

Hilmar Preuße:
> Hi,
> 
> we got bug #820984 on debconf a while ago. I'm not very familiar w/
> debconf, hence I had a look into the templates/config delivered w/
> debconf itself.
> I'm my eyes the code in proftpd is about a 1:1 copy of the code in
> debconf, nevertheless it does not work as expected.
> 
> 1. Would anybody so kind to have a look at this issue? It is our show
> stopper to get back into testing.
> 2. Is that bug even RC or could we lower it to important and address it
> once we're back in testing?
> 
> Many thanks,
>   Hilmar

Hi,

>From a /very quick glance/, it looks like the package is basically using
"debconf as a registry".

Longer version: In a "config" script, the debconf questions should be
"re-seeded" with the current default value /as defined in the actual
configuration file/ (rather than assuming the debconf database is up to
date).
  See [localepurge template file] for an way of how to do this (ymmv).

Rationale: Users update their configuration files (and not the debconf
database).  If you use the values from the configuration file, the user
receives what they expect.  If you use the debconf database, the user
gets what they selected when they last configured the package (which can
be many years older than their last change to their configuration files).

Thanks,
~Niels

[localepurge template file]:
https://anonscm.debian.org/cgit/collab-maint/localepurge.git/tree/debian/localepurge.config#n89

Re: Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors

[Niels Thykier]

Etienne Dysli-Metref:
> On 17/01/17 18:30, Niels Thykier wrote:
>>>> E: libshibsp7: postinst-must-call-ldconfig 
>>>> usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0
>>
>> This lintian error:
>>
>>  * is aimed at stretch or later, and
>>  * should be ignored for stable and stable-backports

Correction; I was wrong - this lintian error is correct for a lintian
from stable (I confused it with a newer lintian tag).

This occurs because you are using debhelper from backports, which uses a
trigger instead of maintscript to call ldconfig.  The end result is the
same for you though - ignore the warning. :)

> 
> After having overridden this lintian error, it turns out it was a bit of
> a red herring: piuparts still reports files left after purging.
> 
> [...]

Correct, this lintian warning is completely unrelated to your piuparts
issue.

> 
> So is the postrm script from shibboleth-sp2-utils not executed?
> 

It is definitely called - if it wasn't, almost everything would be
failing on piuparts.d.o and dpkg in stable would completely an utterly
broken with us drowning in RC bugs. :)

Most likely, there is an issue with either the postrm script OR the
helpers used in it.  I am not an expert on the helpers, so I cannot help
there.

Thanks,
~Niels

Re: Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors

[Niels Thykier]

Etienne Dysli-Metref:
> Hello mentors,
> 
> Since shibboleth-sp2 2.6.0+dfsg1-4 migrated to testing during the
> holidays, I'm now backporting it to jessie. So far there is nothing to
> change, however piuparts gives me the following error (which does not
> appear on stretch):
> 
>> [...]
> 
> So I bumped the build-dep up a bit to: dh-systemd (>= 9.20160709). But
> then a get a lintian error
> 
>> E: libshibsp7: postinst-must-call-ldconfig 
>> usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0
> 
> [...]
> 
> So hmm... any clues? Who's wrong? me, piuparts, lintian or debhelper?
> 
> [...]
> 
>   Etienne
> 

This lintian error:

 * is aimed at stretch or later, and
 * should be ignored for stable and stable-backports

Thanks,
~Niels

Re: How to ensure GLX extension in xfvb

[Niels Thykier]

Andreas Tille:
> Hi,
> 
> I'd like to fix the autopkgtest of njplot.  The current code in Git[1] is 
> executing:
> 
> xvfb-run --auto-servernum --server-num=20 -s '-screen 0 1024x768x24 -ac 
> +extension GLX +render' /usr/bin/njplot -psonly example.phb
> X server has no GLX extension - required to use OpenGL!
> autopkgtest [14:10:42]: test run-unit-test: ---]
> autopkgtest [14:10:42]: test run-unit-test:  - - - - - - - - - - results - - 
> - - - - - - - -
> run-unit-testFAIL non-zero exit status 10
> autopkgtest [14:10:42]:  summary
> run-unit-testFAIL non-zero exit status 10
> 
> 
> Is there any hint what other option should be added to xvfb-run to let
> this test finally succeed?
> 
> Kind regards
> 
> Andreas.
> 
> [1] https://anonscm.debian.org/git/debian-med/njplot.git
> 

Hi,

A guess being that the message you see from the test is from STDERR and
you haven't set the "allow-stderr" (without which, autopkgtests assumes
your test failed).

~Niels

Re: Preference for build or debhelper installing systemd unit files?

[Niels Thykier]

J.T. Conklin:
> My question, in the case where the same organization/people are
> responsible for both the software and the debian packaging, is whether 
> there is a preference of which method is used.
> 
> --jtc

Hi,

If you are (working on/with) upstream and doing the packaging, I believe
making the upstream build system install the systemd file correctly is
preferred.  The primary motivation being that the service file is then
also installed when:

 * packaging is done for another non-Debian-based distribution
   (possibly done by volunteers outside your organization).

 * an end users wants to compile from source (on a non-Debian-based
   system).

(The argument here is not limited to systemd service files as debhelper
have other tools with similar functionality)

Thanks,
~Niels

Re: Debian packaging for packages that provide the same files

[Niels Thykier]

J.T. Conklin:
> [...]
> 
> A complication is that each platform config package installs the same
> set of files, so the normal package build technique of having all files
> being installed to a common staging directory and each package's files
> being selected by the debian/.install doesn't work.
> 

Hi,

Not quite sure I understand exactly what the issue is, so I might miss
with this.

Are you aware that debian/.install can be made executable and thus
arbitrary filter based on any logic you can devise in said file?

CAVEATS:
 * Requires debhelper using compat 9+ (trivially satisfied in any
   supported Debian, but ymmv if you support other targets)
 * debhelper is very strict with output of executable config files
   (e.g. it does not allow comments, empty lines and does not expand
wildcards).

> I could have the configure script take a platform type parameter, and
> only install the files for that platform, but there doesn't seem to be
> an obvious way to plumb that in to debian/control & debian/rules; in
> particular, I don't think you can conditionalize the output package
> names listed in the control file.
> 

The only two uses in Debian, I know of, rely on the selection being done
/before/ the build starts.  Not quite sure how they well they fit you,
but they are:

 * Generating debian/control from debian/control.in
 * Using Build-Profiles to omit building some packages (using a
   "pkg.${sourcepkg}.${name_of_choice}" profile[1]).

[1] https://wiki.debian.org/BuildProfileSpec

It is primarily targeted as dealing with dependencies bootstrapping
issues, but it does list an "Extension namespace".


> Before I put this on the back burner, I thought I'd ask whether there
> are any existing packages that face this, or similar, types of issues
> that I could use as a template.
> 
> Thanks in advance,
> 
> --jtc
> 

Hope it was useful.

Thanks,
~Niels

Bug#841536: hdparm/9.50+ds-1

[Niels Thykier]

Control: tags -1 moreinfo

On Fri, 21 Oct 2016 14:46:32 +0200 Alex Mestiashvili
 wrote:
> Package: sponsorship-requests
> Severity: wishlist
> X-Debbugs-Cc: mailatgo...@gmail.com
> 
> Dear mentors,
> 
>  [...]
> 
> Best regards,
> Alex


Hi Alex,

Thanks for your contribution.

Have you informed upstream about the following compiler warning?
"""
hdparm.c: In function 'process_dev':
hdparm.c:2256:2: warning: this 'if' clause does not guard...
[-Wmisleading-indentation]
  if (!quiet)
  ^~
hdparm.c:2258:3: note: ...this statement, but the latter is misleadingly
indented as if it is guarded by the 'if'
   if (do_drive_cmd(fd, args, 0)) {
   ^~
"""

I checked it seems benign, so I am not blocking the upload on this.  The
code in question being:


"""
if (security_freeze) {
__u8 args[4] = {ATA_OP_SECURITY_FREEZE_LOCK,0,0,0};
if (!quiet)
^^^ (should be 1 tab further in)
printf(" issuing security freeze command\n");
^^ (should be 1 tab further in as well)
if (do_drive_cmd(fd, args, 0)) {
err = errno;
perror(" HDIO_DRIVE_CMD[...] failed");
}
}

"""

Other minor nits:
 * Spelling error in hdparm binary "Removeable" -> "Removable"
   - NB: Upstream is inconsistent with the spelling, but seems to prefer
 the "Removable" variant.
 * Upstream's build system hardcodes -j2 on "make all" and the packaging
   uses that without any respect to DEB_BUILD_OPTIONS
   - Given the small size and low parallel limit, I don't think it is a
 huge issue (but it would have been for other packages).
 * The debian/hdparm.preinst file appears to be redundant (its replaced
   by the debian/hdparm.maintscript)

Thanks,
~Niels



signature.asc
Description: OpenPGP digital signature

Re: lintian: spelling

[Niels Thykier]

Jerome BENOIT:
> Hello Forum, is there a list where we can deal on how correct spelling error 
> as detected by lintian ?
> 
> For the curious. In the source, there is the sentence:
> 
>   :param int max_no_dec: number of rounds we allow to be stuck
> 
> 
> and lintian complains as follows:
> 
>   allow to allow one to
> 
> 
> I am not a native English speaker, but I guess that the suggested 
> substitution is not valid.
> But on the other hand, I have no idea on how to reshape the sentence.
> 
> Any hint is welcome,
> Jerome
> 

Hi,

The following might be useful:

Quote http://www.xibalba.demon.co.uk/jbr/linux/esl.html#b1:
> B1: disallowed!
> 
> This one crops up so often I'm putting it right at the top.
> 
> You can't “allow to” do something (as in “this option allows to compile 
> code”).  You can say that “this option allows you to compile code”, or “this 
> option allows code compilation”, or even “this option allows code to be 
> compiled”; but if there's no object immediately after the verb, it's almost 
> certainly ungrammatical (and the same goes for “permit to”).  
> Native‐anglophone readers will know what you mean, but they'll also suspect 
> you've got a funny accent.
> 
> Besides, unless the software is something like PAM, how likely is it that it 
> literally “allows” me to do something otherwise forbidden?  It enables or 
> simplifies doing things, or helps me do them, or simply does them. 


Thanks,
~Niels

Re: Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications

[Niels Thykier]

Gianfranco Costamagna:
> Hi,
> 
>> I have uploaded a new package to mentors, with the two outstanding 
> 
>> issues fixed.
> 
> not sure...
> I see you forgot to probably run dh_clean
> (I see debian/autoreconf.before and debian/autoreconf.after files)
> 
> [...]
> 
> G.
> 


That needs a "dh_autoreconf_clean" (before the dh_clean).


Thanks,
~Niels

Re: psocksxx/1.1.0-2

[Niels Thykier]

Andrey Rahmatullin:
> On Fri, Sep 02, 2016 at 10:57:07AM +0200, John Paul Adrian Glaubitz wrote:
>>>   * Set compatlevel at debian/compat to 10.
>>
>> Is using compat 10 already officially endorsed/allowed?
> The manpage says "This compatibility level is open for beta testing;
> changes may occur."
> 

For the curious, I expect the next upload of debhelper to be version 10,
marking compat 10 as stable with no further changes.

Thanks,
~Niels

Re: Bug#800406: RFS sayonara/0.8.2

[Niels Thykier]

Ross Gammon:
> On 05/22/2016 10:03 AM, Ross Gammon wrote:
>> The package is still building here,
> 
> [...]
> I: sayonara: hardening-no-pie usr/bin/sayonara
> I: sayonara: hardening-no-bindnow usr/bin/sayonara
> I: sayonara: hardening-no-bindnow usr/lib/sayonara/libsayonara_somafm.so
> I: sayonara: hardening-no-bindnow usr/lib/sayonara/libsayonara_soundcloud.so
> 
> Assuming the build system supports it, we should be able to enable these
> hardening options. See: https://wiki.debian.org/Hardening
> 

Hi,

Please be careful with the "+pie" since the package is building both
shared libs and executables.  Depending on the upstream build system's
it may "just work" or "break horribly".

See also:
 * https://lintian.debian.org/tags/hardening-no-pie.html
 * https://lists.debian.org/debian-devel/2016/05/msg00297.html

Thanks,
~Niels




signature.asc
Description: OpenPGP digital signature

Re: Trying to disable error=format-security for clapack

[Niels Thykier]

Mattia Rizzolo:
> On Mon, May 16, 2016 at 11:11:54AM +0200, Sebastiaan Couwenberg wrote:
>> On 05/16/2016 11:07 AM, Andreas Tille wrote:
>>> When reading the code it seems to me that actually a test whether this
>>> code works or not is intended and thus fixing the format is not in the
>>> intention of the authors.  So I tried 
>>>
>>> export DEB_BUILD_HARDENING_FORMAT:=0
>>> DPKG_EXPORT_BUILDFLAGS = 1
> 
> DPKG_EXPORT_BUILDFLAGS is a thing only if you include
> /usr/share/dpkg/buildflags.mk, and anyway already done by debhelper in
> compat level 9.
> Dunno what DEB_BUILD_HARDENING_FORMAT is.
> 
>>> [...]

I believe hardening-wrapper subscribed to DEB_BUILD_HARDENING_* flags
like the one above.

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: package stuck in unstable after switching to AutomaticDebugPackages

[Niels Thykier]

James Cowgill:
> Hi,
> 

Hi,

> On Sun, 2016-05-08 at 20:17 +0200, Alex Mestiashvili wrote:
>> Hi All,
>>
>> gearmand package has stuck in unstable due to missing -dbg packages:
>>
>>  https://release.debian.org/migration/testing.pl?package=gearmand
>>
>> The debug packages were removed after switching to automatic debug
>> packages [0].
>>
>> How do I force the migration ?  What is the right way to switch to
>> automatic -dbgsym packages ?
> 
> It's not migrating because the old dbg packages are still in sid.

I suspect you may be right about that though it is not clear to me that
we agree on why. :)  So I'll just clarify one point:

The note from testing.pl is (now) just an informational message.  Have a
look at [1], which notes the following items of interest:

 - "Valid candidate" => Nothing listed is a blocker for migration
 - "old binaries left ... (but ignoring cruft, so nevermind)"
   (which is the part where this is just an informational message)

It does not migrate currently because it would make things
uninstallable.  Admittedly, I did a TL;DR on the britney log, so I don't
know the details and you could be right about the old "-dbg" causing the
issue.

(Mind you, in the "old" days, Britney would ignore the package until had
been decrufted)

> Usually stuff like this is removed automatically by dak's auto
> decrufter but apparently not this time.
> 

Hmm, apparently the auto-decrufter thinks that the removal of
libgearman7-dbg would break libgearman-dbg.  I suspect part of the issue
is that libgearman-dbg is an arch:all package (which has a different
heuristic for depending when it should be decrufted).

> If you file a NBS removal bug against ftp.debian.org then the package
> should migrate after the dbg packages are removed manually.
> 
> James
> 

I agree that it would probably help. :)

Thanks,
~Niels

[1] https://tracker.debian.org/pkg/gearmand




signature.asc
Description: OpenPGP digital signature

Re: Including new packages in Debian

[Niels Thykier]

Joseph Bell:
> Howdy,
> 
> I'm looking to understand how one gets a given software package considered
> for inclusion in Debian.  I have 3 software components, one of which is
> https://github.com/Zewo/libvenice , and I'm curious as to where do I even
> start for getting into the next release of Debian?
> 
> Joe
> 

Hi Joe,

Thanks for your interest in Debian.

For creating packages and including software in Debian, please
consult/use the debian-mentors list (which I have CC'ed) in place of
wnpp@d.o (BCC'ed). :)

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: systemd service unit causing lintian init issues

[Niels Thykier]

Niels Thykier:
> [...]
> 

Sorry, I somehow managed to confuse it with "--onlyscripts", which needs
that treatment.  Please ignore my previous mail. :)

~Niels

Re: systemd service unit causing lintian init issues

[Niels Thykier]

Matt Zagrabelny:
> Hi Tino,
> 
> On Tue, Sep 29, 2015 at 3:41 AM, Tino Mettler  wrote:
>> On Wed, Sep 23, 2015 at 16:36:42 -0500, Matt Zagrabelny wrote:
>>> Greetings,
>>>
>>> I'm packaging up a firewall script that ships with a systemd service
>>> unit file. lintian is complaining about an init script:
>>>
>>> % lintian fw-skel_0.06-1_all.deb
>>> W: fw-skel: init.d-script-not-marked-as-conffile etc/init.d/fw-skel
>>> E: fw-skel: init.d-script-not-included-in-package etc/init.d/fw-skel
>>
>> Hi,
>>
>> I had a similar issue in the past. How does your debian/rules file look
>> like? I'll try to remember what I did wrong.
> 
> I had a minimalistic rules file:
> 
> [...]
> 
> With a Build-Depends on dh-systemd. Those tweaks seemed to fix it. I
> also submitted a wishlist documentation bug:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800043
> 
> Thanks!
> 
> -m
> 

Use:

override_dh_installinit:
dh_installinit -p --noscripts
dh_installinit --remaining

Thanks,
~Niels

Re: Suspicious file changes in -dbg between old and new packages

[Niels Thykier]

On 2015-09-22 08:41, Gianfranco Costamagna wrote:
> Hi Niels,
> 
> [...]
>> As for the build-id and how it is computed.  It is based on the
>> internals of the ELF binary including but not limited to:
>>
>> * The path where the binaries were compiled
>> * The options given to gcc when compiled
>> * Time and day, if such are included in the code (__DATE__ macros
>>   and such).
> 
> 
> So how did it work for Thomas with the previous version installed?
> 
> /me is confused :)
> 
> cheers,
> 
> G.
> 

If the old and the new binary have the same build-id, they can reuse the
same debug symbols - regardless of the debug symbols are installed by
name or by build id. :)

So if Thomas can use the old foo with the new foo-dbg, then I guess:

 * foo-dbg is missing the strict mandatory dependency (or Thomas passed
   force options to dpkg), and
 * Thomas built it in the same path as the previous location with the
   same options, and
 * upstream does not use any time based macros?


On the plus side, this would imply that the ELF binaries are build
reproducibly. :)

Thanks,
~Niels

Re: Suspicious file changes in -dbg between old and new packages

[Niels Thykier]

On 2015-09-22 07:30, Gianfranco Costamagna wrote:
> Hi Thomas,
> 
> 
> 
>> And why does it still work when i install back 1.4.0-2 ?
> 
> 
> 
> 
> well, if -2 and -3 didn't change symbols (e.g.  you didn't patch the source 
> code),
> why shouldn't it work?
> 
> (I'm not sure to know how exactly the build.ids are mapped to the binary 
> code, but I guess
> they work as long as the symbols table don't change)
> 

The debug package needs a strictly equal dependency on the original
package, such as: "foo (= ${binary:Version})".  That is orthogonal to
the usage of build-ids (that is, you must use the strictly equal with or
without build-id based debug paths).

As for the build-id and how it is computed.  It is based on the
internals of the ELF binary including but not limited to:

 * The path where the binaries were compiled
 * The options given to gcc when compiled
 * Time and day, if such are included in the code (__DATE__ macros
   and such).

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: Multi-Arch and debian/control

[Niels Thykier]

On 2015-09-21 12:45, Thomas Schmitt wrote:
> Hi,
> 
> while preparing the correction for a buildd failure on Debian
> GNU/kFreeBSD i got a lintian complaint from kfreebsd-i386 7.9
> (the current "stable"):
> 
> E: libburn4: missing-pre-dependency-on-multiarch-support
> 
> [...]
> 
> 
> Have a nice day :)
> 
> Thomas
> 


What version of Lintian are you using?

Current versions of Lintian (in unstable/testing) should have stopped
emitting that warning, since the multiarch-support Pre-Depends is no
longer required.

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: Access to Debian Test Farm for s390 Testing

[Niels Thykier]

On 2015-09-16 06:47, Jeffrey Walton wrote:
> Hi Everyone,
> 
> I work with a free/open source project. We have a failure report from
> a Debian package maintainer on an s390.
> 

Hi Jeffrey,

Thanks for your interest.  :)

I am directing you over to debian-mentors, since your enquiry is
probably better fitted there (debian-testing is intended for upgrade
reports etc.)

> I have a lot of systems available to me for testing (including GCC's
> test farm), but none of them provide an s390 environment. I tried to
> add QEMU's qemu-system-s390x, but ran into Debian Bug 799120
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799120).
> 
> I'm guessing Debian has the test platform because a maintainer tested
> under it (he told me it was not QEMU based). But searching results in
> spurious noise (https://www.google.com/search?q=debian+test+farm), and
> nothing specific to Debian.
> 
> I have three related questions:
> 
>   (1) Where is the Debian test farm?



I suspect you are looking for our s390x porterbox[1]. :)


>   (2) Does Debian provide access to non-Debian maintainers?
>   (3) How can I acquire [possibly partial] access to it for s390 testing?
> 
> If needed for (2), I'm willing to sign-up to be a Debain maintainer
> for the project which I have subject matter expertise.
> 
> Thanks in advance.
>

We have guest accounts[2] which might be what you are looking for. :)
If you get a guest account, you can use it to get a "chroot" for
building as described at [3].

As suggested in the beginning, if you have any further questions, please
follow up to debian-mentors. :)

Thanks,
~Niels

[1] https://db.debian.org/machines.cgi?host=zelenka

[2] https://dsa.debian.org/doc/guest-account/

[3] https://dsa.debian.org/doc/schroot/




signature.asc
Description: OpenPGP digital signature

Re: Error Lintian hardening-no-fortify-functions

[Niels Thykier]

On 2015-09-06 14:22, "J.S.Júnior" wrote:
> Hi,
> 
> I’m  get error lintian hardening-no-fortify-functions.
> 
> I change in Makefile to `dpkg-buildflags --get CFLAGS` `dpkg-buildflags --get 
> LDFLAGS`
> but no resolve
> 
> Anybody can help me?
> 
> []`s
> JJ
> 

Hi,

The "fortity-functions" is provided via dpkg-buildflags --get CPPFLAGS
(and not CFLAGS nor CXXFLAGS).  Perhaps you are missing that one? :)

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: Placing code after #DEBHELPER# autogenerated code?

[Niels Thykier]

On 2015-09-03 15:53, Patrick Schleizer wrote:
> Hi,
> 
> are there legitimate cases, where it is okay to place code after the
> #DEBHELPER# token?
> 
> Cheers,
> Patrick
> 

Hi Patrick,

Yes.  There are many cases where it in fact does not matter whether your
code is above or below that token.  Though there are also cases where
some code must go before the token (sourcing of the debconf module being
an example).

In summary, it depends on what you need to do.

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: Questions before my first upload attempt

[Niels Thykier]

On 2015-08-23 12:48, Thomas Schmitt wrote:
 Hi,
 

Hi Thomas,

 i worked a bit more on my local libburn package.
 
 [...]
 
 The failure of debuild -b with compat 9 still riddles me.
 
 With 9 it finally complains
 
   dh_install: libburn4 missing files (debian/tmp/usr/lib/libburn.so.4*), 
 aborting
 
 It seems to have outsmarted itself by previous
 
   ./configure ... --libdir=\${prefix}/lib/x86_64-linux-gnu ...
 
 With 8, the configure option --libdir is not used.
 
 After debuild -b with compat 9 i have:
 
   $ ls debian/tmp/usr/lib
   x86_64-linux-gnu
   $ ls debian/tmp/usr/lib/x86_64-linux-gnu
   libburn.a  libburn.la  libburn.so  libburn.so.4  libburn.so.4.93.0  
 pkgconfig
 

Yes, this is caused by bumping to compat 9.  Please have a look at:
  man 7 debhelper

Which (among other things) will list:


COMPATIBILITY LEVELS

[...]

   v9  This is the recommended mode of operation.

   Changes from v8 are:

   -   Multiarch support. In particular, dh_auto_configure
   passes multiarch directories to autoconf in --libdir
   and --libexecdir.


If your package is simple, you can use:


  usr/lib/*/file

instead of

  usr/lib/file

Alternatively, please consider using dh-exec.  This requires three steps:

  Add dh-exec to Build-Depends
  Insert #!/usr/bin/dh-exec in the top of debian/package.install
  chmod a+x debian/package.install


Note this only works in compat 9 and later


Thanks,
~Niels

Re: paflib uploaded to mentors.debian.net

[Niels Thykier]

On 2015-08-21 17:21, Johan Van de Wauw wrote:
 On Fri, Aug 21, 2015 at 4:37 PM, tfauck tfa...@free.fr wrote:

 Dear mentors,

 I am looking for a sponsor for the package paflib I just uploaded
 (ITP - #781117) http://bugs.debian.org/781117 paflib

 debuild passes ok, but lintian -EviIL +pedantic gives the following 
 messages: Do I have to sort them out ?
 lintian  -EviIL +pedantic | grep -v ^N:
 
 note that if you dont add -I grep should not be needed. -I will help
 solving the problem if you read the complete text.

Sorry, but you are confusing -I with -i.  The -i is the show tag
descriptions (vs. -I is --display-info).

To avoid the grep, just use:

  lintian -EIL +pedantic

Thanks,
~Niels

Re: Depend on a package from an other arch

[Niels Thykier]

On 2015-08-12 09:26, Bertrand Marc wrote:
 Dear mentors,
 
 I am trying to fix Debian bug #783875 [1]: playonlinux (which is arch
 independant) should depend on the 32 bits version of wine. Therefore I
 added a dependency on wine32|wine32-development, but it seems the
 package will not migrate to testing [2], because wine32 is not available
 on amd64.
 
 If I understand correctly, I should instead add a dependency on
 wine32:any | wine32-development:any and ask the wine maintainer to move
 to multiarch:allowed. But the best source on this subject is an Ubuntu
 one [3]. I cannot find any reliable Debian source about this.
 
 Could you confirm that I understand this correctly ? Or do you know any
 package with a dependency on a package from an other arch ?
 
 Thanks,
 Bertrand
 
 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783875
 [2] https://packages.qa.debian.org/p/playonlinux.html
 [3] https://wiki.ubuntu.com/MultiarchSpec
 

Hi Bertrand,

Neither solution will work.  This is an artefact of how the testing
migration code handles arch:all packages.

Please file a bug against release.debian.org requesting help with this.

Thanks,
~Niels



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55cafa63.9020...@thykier.net

Re: Depend on a package from an other arch

[Niels Thykier]

On 2015-08-12 09:48, Niels Thykier wrote:
 [...]

 
 Hi Bertrand,
 
 Neither solution will work.  This is an artefact of how the testing
 migration code handles arch:all packages.
 
 Please file a bug against release.debian.org requesting help with this.
 
 Thanks,
 ~Niels
 
 
 

Actually, in hindsight - it might be easier just to make the package an
32bit package (and override the tag from lintian about abusing /usr/share).

Users wanting to install your package will have to have (kfreebsd-)i386
as a foreign architecture anyway.

Thanks,
~Niels



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55cafc6a.8090...@thykier.net

Re: Granting DM rights as a sponsor

[Niels Thykier]

On 2015-07-15 08:45, Ole Streicher wrote:
 Vincent Cheng vch...@debian.org writes:
 There are tools available in the archive to make this entire process
 relatively painless (dput-ng)
 
 But dcut-ng is not in Debian?
 
 $ apt-get install dcut-ng
 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 E: Unable to locate package dcut-ng
 
 When I search on packages.debian.org, I also don't get a result.
 
 Best
 
 Ole
 
 

Hi Ole,

The package name is dput-ng and not dcut-ng. :)

Thanks,
~Niels



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55a6081b.8020...@thykier.net

Re: blocked migration from unstable to testing: old binaries left

[Niels Thykier]

On 2015-07-07 14:50, Jerome BENOIT wrote:
 Hello Niels and all:
 
 As the last package of ovito, which does not depends on tachyon any more,
 has reached testing, I think that the  tachyon package can now migrate to 
 testing:
 how can we unblock its migration ?
 
 Thanks,
 Jerome
 
 [...]

Thanks for taking care of it, I have removed the block hint.  Britney
willing, tachyon should migrate tonight.

Thanks,
~Niels



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/559becce.3000...@thykier.net

Re: blocked migration from unstable to testing: old binaries left

[Niels Thykier]

On 2015-06-19 15:21, Jerome BENOIT wrote:
 Hi Again:
 
 On 19/06/15 14:52, Jerome BENOIT wrote:
 Hi:

 On 19/06/15 08:07, Niels Thykier wrote:
[...]

 Yes, provided it depends on the correct -dev packages.  Though it might
 have to go through NEW at this point.

 At this junction, it /may/ be easier to just update ovito as it is the
 only affected reverse dependency.

 I have just sent an email to the maintainer in this sense.
 
 He is on his way to do so.
 
 Thanks,
 Jerome
 

Hi,

Are there any news on this?

AFAICT, ovito still Build-Depends on libtachyon-dev (rather it seems to
not have been uploadedd in the past 11 months) and there is no bug
report filed against ovito for it.

Thanks,
~Niels



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/558fc916.2080...@thykier.net

Re: blocked migration from unstable to testing: old binaries left

[Niels Thykier]

On 2015-06-19 02:48, Jerome BENOIT wrote:
 Hello,
 
 thanks for your prompt reply.
 
 On 18/06/15 14:55, Paul Wise wrote:
 On Thu, Jun 18, 2015 at 8:22 PM, Jerome BENOIT wrote:

 what am I supposed to do for unblocking ?

 You started a (minor) transition without involving the release team,
 please read this:

 https://wiki.debian.org/Teams/ReleaseTeam/Transitions

 According to the cruft report, the old binaries can't be removed
 because ovito build-depends on libtachyon-dev. You'll need to convince
 the ovito maintainers to switch to the new tachyon dev packages.

 https://ftp-master.debian.org/cruft-report-daily.txt

 
 Will a dummy libtachyon-dev  package solve the problem ?
 
 Thanks,
 Jerome
 
 

Yes, provided it depends on the correct -dev packages.  Though it might
have to go through NEW at this point.

At this junction, it /may/ be easier to just update ovito as it is the
only affected reverse dependency.

~Niels



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5583b192.6050...@thykier.net

Re: blocked migration from unstable to testing: old binaries left

[Niels Thykier]

On 2015-06-18 14:55, Paul Wise wrote:
 On Thu, Jun 18, 2015 at 8:22 PM, Jerome BENOIT wrote:
 
 what am I supposed to do for unblocking ?
 
 You started a (minor) transition without involving the release team,
 please read this:
 
 https://wiki.debian.org/Teams/ReleaseTeam/Transitions
 
 According to the cruft report, the old binaries can't be removed
 because ovito build-depends on libtachyon-dev. You'll need to convince
 the ovito maintainers to switch to the new tachyon dev packages.
 
 https://ftp-master.debian.org/cruft-report-daily.txt
 

As Paul already mentioned, it is due to a transition.


 * Your packages had no reverse dependency left on release
   architectures (but did have on sparc and possibly others).

 * It /did/ have reverse build-dependencies on release architectures,
   but it was decrufted regardless, so those are now broken.

 * As a result, ovito is most likely unbuildable in unstable on (e.g.
   amd64). Haven't tested it, but evidence points to this conclusion.
   For now I have blocked your package from migration.
   - It will show up as a block hint from nthykier or so in many hours
 from now as was not part of the original reason for it being
 blocked.


I am a bit pressed on time atm., so I cannot follow through on this one
right now.  Jerome, please verify that the Build-Depends of ovito are
not installable in unstable (linux-amd64 or linux-i386 should do) and if
so file a serious bug against ovito asking them to migrate to the new
dev package replacing it.

I will get back to you later (in several hours from now or worst case,
tomorrow).

~Niels





-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5582c42b.3070...@thykier.net

Re: Why are old bug reports left open?

[Niels Thykier]

On 2015-06-02 20:10, Thaddeus H. Black wrote:
 [...]
 If I were the maintainer, I believe that I would have closed a bug like this. 
  The actual maintainer however (now emeritus) is smarter than me.  He did not 
 close it.  This suggests that he knew something I do not understand about 
 proper bug handling.
 

The package is orphaned and thus have no actual maintainer.

There are plenty of reasons why the previous maintainer might not have
closed the bug.  The most common/likely one being that he/she simply
forgot about it (and happened to retire before remembering about it).

If I were you, and I saw no reason to keep the bug open, I would close
it.  You will hear from people when they disagree strongly with your
actions, but they will be quiet if they agree or don't care.

 [...]
 
 I am confused.  What should I learn from this example about proper bug 
 handling, please?
 
 (For information, I am thinking of adopting the package in question, orphaned 
 six months.  I am however reluctant to begin by closing bugs the old, smart 
 maintainer saw fit to leave open.  I am not the best possible maintainer for 
 this package, but no one else is maintaining it.  This is why I ask advice.)
 

I believe that [1] is a good resource for you.  None of us were perfect
when we joined and none of us are now despite our best efforts (the
old, smart maintainer included).

If you want a lesson learned:

 * Always tag/update your bugs when you reply to the bug.
 * Frequently revisit the bugs for your packages and check if some of
   them has expired by now.
   - Pro-tip: Have a periodic calender reminder for this.  E.g. spring
 clean the bug page for ${list-of-packages} set for the early
 period of March, where it is still too cold to go outside but light
 enough for you to leave your winter coat at home despite knowing
 you will freeze at the slightest breeze.


Thanks,
~Niels

[1] https://lwn.net/Articles/641779/




signature.asc
Description: OpenPGP digital signature

Re: RC-bug listed on https://bugs.debian.org/release-critical/debian/all.html

[Niels Thykier]

On 2015-04-01 08:06, Werner Detter wrote:
 Hi folks, 
 
 just a short question - a bug which has already been taken care of for wheezy 
 and jessie is 
 still listed as RC bug at 
 https://bugs.debian.org/release-critical/debian/all.html
 
 Package: policyd-weight (debian/main).
 Maintainer: Werner Detter wer...@aloah-from-hell.de
   774772 [] [S] policyd-weight: rhsbl.ahbl.org flags all domains
 
 In PTS the bugreport is closed. Why is it still listed in the RC buglist? 
 
 Cheers, 
 Werner
 
 

Hi Werner,

It is still listed as affecting Wheezy[1], which is why it is still
listed on that page.

Note that uploading it to proposed-updates is not sufficient to mark it
as fixed in stable.  If you have uploaded the fix for the coming point
release, the bug will remain open until the release actually happens.

Thanks,
~Niels

[1]
https://bugs.debian.org/cgi-bin/version.cgi?info=1;absolute=0;fixed=policyd-weight%2F0.1.15.2-10;fixed=policyd-weight%2F0.1.15.2-5%2Bwheezy2;collapse=1;found=policyd-weight%2F0.1.15.2-9;found=policyd-weight%2F0.1.15.2-5%2Bwheezy1;package=policyd-weight



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/551b919e.40...@thykier.net

Re: Python logo license

[Niels Thykier]

On 2015-02-28 16:37, Daniel Stender wrote:
 Hi folks,
 
 I've got the official Python logo image [1] here in a package.
 
 1) what would be the proper license for that file in deb/copyright?
 
 2) what's the best place in Debian to ask copyright/licensing related
 questions like this in the future, the developer's list?
 
 Thanks in advance,
 Daniel Stender
 
 [1]
 https://www.python.org/static/community_logos/python-logo-master-v3-TM.png
 

Hi Daniel,

1) The python logo is subject to the PSF Trademark Usage Policy[1][2].
 At a quick glance, it looks like it is distributable, but I doubt it
complies with the DFSG.

2) If it is about whether a license is DFSG, you probably want either
debian-le...@lists.debian.org or debian-mentors.  I suspect that
debian-mentors is faster when it is trivial to determine whether
something is DFSG-compliant, but you may be punted to debian-legal or
the FTP masters for sufficiently obscure licenses.

Hope that answers your questions,
~Niels

[1] https://www.python.org/psf/trademarks/

[2] https://www.python.org/community/logos/



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54f1f56e.3040...@thykier.net

Re: Testing migragtion of beast-mcmc is blocked but I have no idea why

[Niels Thykier]

On 2014-10-25 13:00, Andreas Tille wrote:
 Hi,
 
 https://qa.debian.org/excuses.php?package=beast-mcmc
 
 says:
 
   beast-mcmc/i386 unsatisfiable Depends: libnucleotidelikelihoodcore0 (= 
 1.8.0-1) 
 
 but I have asked ftpmaster for removal of beast-mcmc from arch i386 and
 packages.debian.org says it is only for amd64.  Any idea how to enable
 the migration?  I guess there might be some remainings from former i386
 versions - but where?
 
 Kind regards
 
  Andreas.
 

Being an arch:all package, it will appear on all architectures.  Britney
uses i386 as the architecture to determine whether an arch:all package
is installable or not.

Please file a bug against release.debian.org requesting assistence for
this special case[1] (explaining the situation).  The alternative is to
make beast-mcmc an arch:amd64 package.  In the given case, it might make
sense...

~Niels

[1] I believe it needs a force-hint, but I leave the final judgement
to the other members of the RT, who has more experience with this kind
of special case.



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/544b8678.4060...@thykier.net

Re: where are these lintian problems coming from

[Niels Thykier]

On 2014-07-12 09:36, Vincent Bernat wrote:
  ❦ 12 juillet 2014 05:19 GMT, T o n g mlist4sunt...@yahoo.com :
 
 Do I need to care about the lintian problems from the binary package that 
 I maintain/build?
 
 Yes, you need to handle at least errors and warnings.
 
 For the following problems, I have no idea where they come from:

  N: Processing binary package ddclient (version 3.8.2-1, arch all) ...
  W: ddclient: using-imperative-form-in-templates ddclient/fetchhosts
  I: ddclient: unused-debconf-template ddclient/hostslist
  I: ddclient: unused-debconf-template ddclient/blankhostslist
 
 Use -v to get more tips about each error. Those are about debconf
 templates declared in debian/ddclient.templates.
 
 [...]
 


I think you mean -i (if you are referring to the tag description).
The -v is already enabled (based on the output shown).

~Niels



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53c0e8e4.8020...@thykier.net

Re: I would like to renew my request to delay the removal of maitreya from testing.

[Niels Thykier]

On 2014-06-25 07:40, Paul Elliott wrote:
 [...]
 
 Therefore, I would like to request additional delay to sometime
 after libwxsqlite3-3.0-dev reaches testing. As matters
 now stand there is no way I can reach the deadline of 
 -- maitreya 7.0.5-1 is marked for autoremoval from testing on 2014-06-28 --
 due to factors outside of my control!
 
 [...]
 
 Thank You for considering my request.
 

Send a status update to #749974.  It will reset the timer.

Also, when you close the bug in an upload, the timer will be reset.
Provided the new version is not stalled considerably beyond the normal
migration delay, it should make it well before the timer.

Finally, the default urgency for package updates is medium.  So unless
you choose low yourself[1], the delay is only 5 days.

~Niels

[1] Or use dch from stable and don't correct it.  It is too old to know
about this rule.





-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53aa62a0.1030...@thykier.net

Re: Testing excuse Section: non-free/science

[Niels Thykier]

On 2014-03-02 12:05, Оlе Ѕtrеісhеr wrote:
 Hi,
 
 after I moved one of my packages (iausofa-c) from main to non-free, I
 had for some time the problem that the source still appeared in
 main. This, however, was solved somehow without any notice.
 
 However, now I get the migration excuse [1] Section:
 non-free/science. What does this mean? The docs [2] doen't list
 anything about that non-free is anyhow different from main.
 
 The package still did not pass the 10-day testing quarantine anyway, but
 I want to make sure that it enters unstable when this time is over.
 
 How should I proceed?
 
 Best
 
 Ole
 
 [1] http://qa.debian.org/excuses.php?package=iausofa-c
 [2] https://www.debian.org/devel/testing
 
 

Hi Ole,

The note is purely informational and has no affect on testing migration
itself.  Basically, it is simply the value of the Section field from
the mirror's Sources file.

~Niels



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5313140a.3070...@thykier.net

Re: debian/copyright + cc-by-sa

[Niels Thykier]

On 2014-02-09 16:51, Felix Natter wrote:
 hi,
 
 I couldn't find a short version of the CC-BY-SA-3.0 license.
 - now I am using this:
 
 Files: ./freeplane_framework/script/freeplane.svg
./freeplane_framework/script/freeplane.png
 Copyright: 2013-2014 Robert Gibson
 License: CC-BY-SA-3.0
  THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE
  COMMONS PUBLIC LICENSE (CCPL OR LICENSE). THE WORK IS PROTECTED BY
  COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS
  AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.
  .
  BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO
  BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY BE
  CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED
  HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS.
 
 which is the header on this page:
 http://spdx.org/licenses/CC-BY-SA-3.0
 
 (it passes cme check dpkg-copyright, but that doesn't say anything
 about the license text)
 
 Is that ok, or, if not, can someone point me to the correct short
 license text?
 
 Thanks and Best Regards,
 

There is no short version you can use in d/copyright - you have to
list the full license of CC-BY-SA-3.0 as it is not in common-licenses.
Though, if you have it in a stand-alone license paragraph, you can just
omit the part you showed above.

~Niels



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f7a810.9000...@thykier.net

Re: debian/copyright + cc-by-sa

[Niels Thykier]

On 2014-02-09 17:29, Felix Natter wrote:
 Hi Niels,
 
 Niels Thykier ni...@thykier.net writes:
 There is no short version you can use in d/copyright - you have to
 list the full license of CC-BY-SA-3.0 as it is not in common-licenses.
 Though, if you have it in a stand-alone license paragraph, you can just
 omit the part you showed above.
 
 Just to be sure: So this:
 
 Files: ./freeplane_framework/script/freeplane.svg
./freeplane_framework/script/freeplane.png
./freeplane/resources/images/Freeplane_splash.png
 Copyright: 2013-2014 Robert Gibson
 License: CC-BY-SA-3.0
  THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE
  COMMONS PUBLIC LICENSE (CCPL OR LICENSE). THE WORK IS PROTECTED BY
  COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS
  AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.
  .
  BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE
  TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY
  BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS
  CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND
  CONDITIONS.
  .
  1. Definitions 
 
  [...]
 
  Except for the limited purpose of indicating to the public that the Work
  is licensed under the CCPL, Creative Commons does not authorize the use
  by either party of the trademark Creative Commons or any related
  trademark or logo of Creative Commons without the prior written consent
  of Creative Commons. Any permitted use will be in compliance with
  Creative Commons' then-current trademark usage guidelines, as may be
  published on its website or otherwise made available upon request from
  time to time. For the avoidance of doubt, this trademark restriction
  does not form part of the License.
 
 (from http://spdx.org/licenses/CC-BY-SA-3.0) is correct?
 
 Thanks and Best Regards,
 


Yes, to my knowledge that would be a valid d/copyright (assuming the
missing  . around [...] is omitted only in this mail).

~Niels



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f7ae8d.1070...@thykier.net

Re: Moving a package (to non-free)

[Niels Thykier]

On 2014-01-30 09:33, Оlе Ѕtrеісhеr wrote:
 Hi,
 

Hi,

CC'ing the FTP masters.

 I was trying to move a package (iausofa-c) from main to non-free with a
 new version. In the developers reference [1], the according paragraph is
 5.9.1:
 
 
 If you need to change the section for one of your packages, change
 the package control information to place the package in the desired
 section, and re-upload the package
 
 So, I changed the section to non-free, and uploaded the new version
 2013.12.02-1 (resp. I asked my sponsor to do so). However, this was
 followed by some unexpected things:
 
 1. I got a traceback with a rejection [2]

Looks like dak is not too happy with this case.  Dear FTP masters, I
think we could use a more human-readable message for this case:


An exception was raised while processing the package:
Traceback (most recent call last):
  File /srv/ftp-master.debian.org/dak/dak/process_policy.py, line 98,
in wrapper
function(upload, srcqueue, comments, transaction)
  File /srv/ftp-master.debian.org/dak/dak/process_policy.py, line 155,
in comment_accept
transaction.copy_binary(db_binary, suite,
binary_component_func(db_binary), allow_tainted=allow_tainted,
extra_archives=[upload.target_suite.archive])
  File /srv/ftp-master.debian.org/dak/dak/process_policy.py, line 136,
in binary_component_func
.join(Component).one()
  File /usr/lib/python2.7/dist-packages/sqlalchemy/orm/query.py, line
2193, in one
Multiple rows were found for one())
MultipleResultsFound: Multiple rows were found for one()



(assuming you haven't implemented it already)

 2. Someone then removed the old binary packages [3]
 3. Then the package got accepted  [4]
 3. After a few days, I got a serious bug that the source is still in
main [5]
 

The uploaded package (from your [4]) does indeed seem to say it wants to
be in non-free:
  [...] non-free/science optional iausofa-c_2013.12.02-1.dsc

My local apt-cache also recognise them as in non-free:


$ aptitude show libsofa-c0 libsofa-c-dev | grep Section
Section: non-free/libs
Section: non-free/libdevel


But the source is located in the main pool!

http://debian.morphium.info/debian/pool/main/i/iausofa-c/iausofa-c_2013.12.02-1.dsc

Note the pool/*main*/, which should pool/*non-free*/ (minus my
emphasis).  This probably means that some part of dak still thinks the
package should be in main...

 No I am unsure what to do. I followed the reference, but it was somehow
 not recognized. The real procedure to move a package seems to be
 different from the documentation. Is this a bug in the manual? And, if
 yes, what is the correct way? If not, should I file a bug against
 ftp-masters saying that the implementation to move a package is wrong?
 
 Or did I something fundamentally misunderstand here? Do I refer to the
 right section of the reference manual and do I interpret it correctly?
 
 Best regards
 
 Ole
 
 [1] 
 https://www.debian.org/doc/manuals/developers-reference/pkgs.html#moving-pkgs
 [2] 
 http://lists.alioth.debian.org/pipermail/debian-science-maintainers/2014-January/022351.html
 [3] http://bugs.debian.org/735677
 [4] 
 http://lists.alioth.debian.org/pipermail/debian-science-maintainers/2014-January/022360.html
 [5] http://bugs.debian.org/737055
 
 

I think we could use some help from the FTP masters side in figuring out
what went wrong here and how to move forward from here.

~Niels



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52ed1e80.2000...@thykier.net

Re: Help: Bug#733407: maude: FTBFS: surface.yy:63:67: error: 'parseResult' was not declared in this scope

[Niels Thykier]

On 2014-01-27 20:30, Andreas Tille wrote:
 Hi,
 
 does anybody have a clue how to fix this C++ issue?
 
 Kind regards
 
  Andreas.
 

It is not a C++ issue, but a change in bison you are looking at.  I had
a similar issue with mscgen not too long ago[1].

~Niels

[1] http://packages.qa.debian.org/m/mscgen/news/20131229T131907Z.html


 - Forwarded message from David Suárez david.sephi...@gmail.com -
 
 Date: Sat, 28 Dec 2013 19:10:41 +0100
 From: David Suárez david.sephi...@gmail.com
 To: sub...@bugs.debian.org
 Subject: Bug#733407: maude: FTBFS: surface.yy:63:67: error: 'parseResult' was 
 not declared in this scope
 X-Debian-PR-Message: report 733407
 X-Debian-PR-Package: src:maude
 X-Debian-PR-Keywords: jessie sid
 X-Debian-PR-Source: maude
 
 Source: maude
 Version: 2.6-4
 Severity: serious
 Tags: jessie sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20131226 qa-ftbfs
 Justification: FTBFS on amd64
 
 Hi,
 
 During a rebuild of all packages in sid, your package failed to build on
 amd64.
 
 Relevant part (hopefully):
 g++ -DHAVE_CONFIG_H -I. -I. -I../..  -I../../src/Utility 
 -I../../src/Temporal -I../../src/Interface -I../../src/Core 
 -I../../src/Variable -I../../src/FullCompiler -I../../src/Higher 
 -I../../src/CUI_Theory -I../../src/S_Theory -I../../src/NA_Theory 
 -I../../src/FreeTheory -I../../src/ObjectSystem -I../../src/Mixfix 
 -I../../src/BuiltIn -I../../src/MSCP10 -I../../src/IO_Stuff 
 -I../../src/ACU_Persistent -I../../src/ACU_Theory -I../../src/AU_Persistent 
 -I../../src/AU_Theory -I../../src/Meta -I../../src/3rdParty 
 -I../../src/FullCompiler -I../../src/StrategyLanguage -D_FORTIFY_SOURCE=2  
 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
 -Werror=format-security -c -o libmixfix_a-surface.o `test -f 'surface.cc' || 
 echo './'`surface.cc
 In file included from ../../src/Interface/term.hh:34:0,
  from ../../src/Variable/variableTerm.hh:28,
  from ../../src/Core/variableInfo.hh:30,
  from ../../src/Core/preEquation.hh:30,
  from ../../src/Core/rule.hh:28,
  from userLevelRewritingContext.hh:34,
  from surface.yy:54:
 ../../src/Core/termSet.hh:35:3: warning: access declarations are deprecated 
 in favour of using-declarations; suggestion: add the 'using' keyword 
 [-Wdeprecated]
PointerSet::cardinality;
^
 ../../src/Core/termSet.hh:36:3: warning: access declarations are deprecated 
 in favour of using-declarations; suggestion: add the 'using' keyword 
 [-Wdeprecated]
PointerSet::makeEmpty;
^
 surface.yy: In function 'int yyparse()':
 surface.yy:63:67: error: 'parseResult' was not declared in this scope
  #define PARSE_RESULT (*((UserLevelRewritingContext::ParseResult*) 
 parseResult))
^
 surface.yy:235:6: note: in expansion of macro 'PARSE_RESULT'
   PARSE_RESULT = UserLevelRewritingContext::QUIT;
   ^
 surface.yy:63:67: error: 'parseResult' was not declared in this scope
  #define PARSE_RESULT (*((UserLevelRewritingContext::ParseResult*) 
 parseResult))
^
 surface.yy:312:6: note: in expansion of macro 'PARSE_RESULT'
   PARSE_RESULT = UserLevelRewritingContext::QUIT;
   ^
 surface.yy:63:67: error: 'parseResult' was not declared in this scope
  #define PARSE_RESULT (*((UserLevelRewritingContext::ParseResult*) 
 parseResult))
^
 surface.yy:319:10: note: in expansion of macro 'PARSE_RESULT'
   PARSE_RESULT = UserLevelRewritingContext::QUIT;
   ^
 surface.yy:573:4: error: expected ';' before '}' token
 }
 ^
 surface.yy:1097:33: error: expected ';' before '}' token
  command  : KW_SELECT  { lexBubble(END_COMMAND, 1) }
  ^
 surface.yy:1102:33: error: expected ';' before '}' token
| KW_DUMP   { lexBubble(END_COMMAND, 1) }
  ^
 surface.yy:63:67: error: 'parseResult' was not declared in this scope
  #define PARSE_RESULT (*((UserLevelRewritingContext::ParseResult*) 
 parseResult))
^
 surface.yy:1490:6: note: in expansion of macro 'PARSE_RESULT'
   PARSE_RESULT = UserLevelRewritingContext::RESUME;
   ^
 surface.yy:63:67: error: 'parseResult' was not declared in this scope
  #define PARSE_RESULT (*((UserLevelRewritingContext::ParseResult*) 
 parseResult))
^
 surface.yy:1494:6: note: in expansion of macro 'PARSE_RESULT'
   PARSE_RESULT = UserLevelRewritingContext::ABORT;
   ^
 surface.yy:63:67: error: 'parseResult' was not declared in this scope
  #define PARSE_RESULT (*((UserLevelRewritingContext::ParseResult*) 
 parseResult))

Re: Help: Bug#733407: maude: FTBFS: surface.yy:63:67: error: 'parseResult' was not declared in this scope

[Niels Thykier]

On 2014-01-27 20:30, Andreas Tille wrote:
 Hi,
 
 does anybody have a clue how to fix this C++ issue?
 
 Kind regards
 
  Andreas.
 

It is not a C++ issue, but a change in bison you are looking at.  I had
a similar issue with mscgen not too long ago[1].

~Niels

[1] http://packages.qa.debian.org/m/mscgen/news/20131229T131907Z.html




-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e6ba54.1010...@thykier.net

Re: Help: Bug#733407: maude: FTBFS: surface.yy:63:67: error: 'parseResult' was not declared in this scope

[Niels Thykier]

On 2014-01-27 22:31, Andreas Tille wrote:
 Hi Niels,
 
 I guess you want to tell me that I want something like
 

 http://anonscm.debian.org/gitweb/?p=collab-maint/mscgen.git;a=blob;f=debian/patches/language.y-parse-param.patch;hb=HEAD
 
 applied to maude code.  I need to admit that I'm to weak with bison and
 can not really make some sense out of its bison input to approach this.
 
 Any help would be welcome
 
   Andreas.
 
 [...]

While I am convinced that the problem is caused by bison, I am not
certain that a similar patch will work in your case.  But at least we
can narrow it down from help with C++ to help make bison generate the
right code.  I won't claim to be bison-savvy enough to be able to help
you with that though, sorry.

~Niels



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e6d1c2.8060...@thykier.net

Re: lintian usage and inconsistence problem

[Niels Thykier]

On 2014-01-27 23:41, Etienne Millon wrote:
 * T o n g mlist4sunt...@yahoo.com [140127 23:37]:
 $ lintian -EviIL +pedantic --color auto --display-experimental
   ../*.dsc
 [...]
 I.e., when I invoke lintian manually, I didn't see problems reported
 by debuild. 
 
 Hi Tong,
 
 Lintian can check both source packages (*.dsc) or binary packages
 (*.deb). By running it on the .dsc file, you only see the results of
 source checks.
 
 The solution to this is to invoke lintian on the .changes file.
 As a consequence it will do both source and binary checks.
 
 Hope that helps !
 

Bonus hint: you can often omit the package argument for lintian, when
you run it from the unpacked source tree.  In that case, lintian will
guess what (changes) file you want to process based on
debian/changelog (which must then be available).

~Niels



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e74f6c.4020...@thykier.net

Re: qiime REMOVED from testing

[Niels Thykier]

On 2014-01-22 00:43, Steven Chamberlain wrote:
 On 21/01/14 18:45, Andreas Tille wrote:
 However, it is kicked because of an old libffi dependency.  I realised
 that it had in fact

libffi6 (= 3.0.4)

 in its dependencies which was included via

${shlibs:Depends}  or
${misc:Depends}

 but I have no idea, how to prevent this.  Would a rebuild be sufficient
 to get the new libffi dependency or do I need to do more?
 
 When I rebuilt it just now on kfreebsd-amd64, the .deb picked up these
 dependencies:
 
 Depends: libc0.1 (= 2.17-91), libffi6 (= 3.0.4), libgmp10, python (= 
 2.7), python ( 2.8), pynast (= 1.2), python-cogent (= 1.5.3), king, 
 python-biom-format
 
 So presumably that's fine, libffi6/3.0.13-10 in jessie+sid satisfies this.
 
 Regards,
 

Thanks for testing this, Steven

Andreas, based on Steven's test, you may want to consider requesting a
give-back for qiime on kFreeBSD[1].  This is, of course, assuming that
such a request haven't been filed for you by Steven.  :)

~Niels

[1] https://release.debian.org/wanna-build.txt

NB: Needs to go to debian-wb-t...@lists.debian.org and not d-release.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52e034d3.6050...@thykier.net

Re: qiime REMOVED from testing

[Niels Thykier]

On 2014-01-21 19:45, Andreas Tille wrote:
 Hi,
 

Hi Andreas and d-mentors,

 I hope this is the correct list to ask this questions - if not please
 redirect me (and also please CC me in your reply). [debian-mentors in
 CC as well - may be some other people have a similar problem.]
 

Seems like a reasonable choice for clarifying removals from testing. :)

 I know that qiime has a serious bug (#731190) where I was seeking for
 help six weeks ago with no real result.  So I would have expected to
 become kicked from testing because of this bug which would be fine.
 

It could have been kicked out for that reason.  Possibly, it would have
been eventually, but qiime would have blocked the transition in question
until then.  I will not rule out that the bug was an enabler for an
earlier manual removal - personally, I have kicked packages out for
having RC bugs if those bugs stalled the transitions longer than my
patience lasted[0].

 However, it is kicked because of an old libffi dependency.  I realised
 that it had in fact
 
libffi6 (= 3.0.4)
 
 in its dependencies which was included via
 
${shlibs:Depends}  or
${misc:Depends}
 
 but I have no idea, how to prevent this.  Would a rebuild be sufficient
 to get the new libffi dependency or do I need to do more?
 
 Kind regards
 
Andreas.
 
 [...]

As you correctly conclude, a binNMU would usually have been sufficient
to update the dependency.  However, qiime currently FTBFS on
kFreeBSD[1].  This makes it impossible to binNMU qiime with the purpose
of completely getting rid of the libffi6 dependency (in testing).


The slightly longer story.  In order to finish the transition, qiime
would have to stop depending on libffi6 in testing.  This generally
happens in one of two ways:
 1. qiime gets removed (as it happened here)
 2. qiime gets updated on *ALL* architectures with a libffi6 dependency
to no longer depend on libffi6 and this update migrates to testing.

The problem with doing 2. in this case, is that the package FTBFS on
kFreeBSD.  So even if binNMUed on all (other) architectures, the
dependency would remain on the kFreeBSD and thus stall the transition.

Now, by the looks of it, this FTBFS has not been filed.  For that, I
believe you have suffered from the problem mentioned in [2].

~Niels

[0] My patience for RC bugs stalling transitions may be a function over
how much time / energy I have to keep track of the transition in
question or how fed up I am with it still not being done yet.

[1] https://buildd.debian.org/status/package.php?p=qiime

[2] https://lists.debian.org/debian-devel/2013/12/msg00611.html

On a related note, I suspect a good part of this problem would go
away if we had an automated tool to deal with the case where a
(sid-only) FTBFS is ignored.  It happens sometimes that the maintainer
does nothing (or, maybe, does not realise the package FTBFS on arch X)
and neither the porters nor the buildd admins filed a bug for it.
  Then it is not until the package gets in way of a transition (or some
other RC bug fix), that the package gets its RC bug.  I have seen a
package stuck in sid for at least 90 days and still no RC bug - the
only thing wrong was an Out of date binaries on some architecture
(don't remember which package nor which architecture).




-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52ded41a.7050...@thykier.net

Re: dch -i injects urgency=medium

[Niels Thykier]

On 2014-01-05 10:06, Thomas Goirand wrote:
 On 01/05/2014 04:55 PM, Andreas Tille wrote:
 Hi,

 since some days I noticed that a `dch -i` creates an entry with
 urgency=medium instead of urgency=low.  Anybody with the same
 observation and what might be the reason for this?

 Kind regards

  Andreas.
 
 That's because it is now the view of the release team that
 urgency=medium is ok for most uploads, and you should do that as well. I
 believe it has been announced through the dda list.
 
 Cheers,
 
 Thomas Goirand (zigo)
 
 

Indeed, it was announced on the 28th of November 2013[1].  See the
Default Urgency headline.

~Niels

[1] https://lists.debian.org/debian-devel-announce/2013/11/msg7.html



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52c923a4.3050...@thykier.net

Re: dpkg-source: version does not contain a revision

[Niels Thykier]

On 2014-01-03 21:28, T o n g wrote:
 Hi, 
 
 What's the cause (and fix) of the following error?
 
dpkg-source -b dbab-1.0.1
   dpkg-source: error: can't build with source format '3.0 (quilt)': 
 version does not contain a revision
   dpkg-buildpackage: error: dpkg-source -b dbab-1.0.1 gave error exit 
 status 255
 
 Thanks
 
 

Hi,

I guess (without having it confirmed) that your package has a native
version (i.e. without a dash).  For 3.0 (quilt) packages your package
must have a non-native version (e.g. 1.0.1-1).  See also §5.6.12 of the
Debian Policy Manual for more info[1].

~Niels

[1]
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version





-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52c72548.2060...@thykier.net

Bug#726791: willing to sponsor awstats

[Niels Thykier]

On 2013-12-28 16:20, Willi Mann wrote:
 Hello Sergey, Hello Niels,
 
 I'd be willing to look at awstats 7.2~dfsg-1 and upload it if it looks
 OK to me.

Hi Willi,

Thanks for considering.


 Is there a packaging-related reason why Niels did not upload
 it for you so far?
 
 Bye
 Willi
 

Sadly, the truth appears to be that I have forgotten that there was a
pending RFS for awstats - Sorry, Sergey.  Willi, if you don't mind,
please have a look at it and sponsor it. I am afraid I won't have time
to take time for in the nearest future and I suspect Sergey has waited
quite long enough.

~Niels


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52bf1467.2020...@thykier.net

Re: About the testing transition known as auto-libunwind

[Niels Thykier]

On 2013-12-22 03:45, T o n g wrote:
 Hi, 
 
 I want to adopt the par2cmdline package, but on its QA page, 
 http://packages.qa.debian.org/p/par2cmdline.html
 it says, 
 
 ,-
 | This package is part of the ongoing testing transition known as
 | auto-libunwind. Please avoid uploads unrelated to this
 | transition, they would likely delay it and require supplementary
 | work from the release managers.
 `-
 
 what's the impact on me adopting/building/uploading the package?
 
 Thanks
 
 

Hi,

In the particular case, not much.  libunwind is somewhat a special case,
which is mostly done except on ia64.  On that architecture, pretty much
everything depends on libunwind because gcc inserts a dependency when it
compiles the binaries.

Note that there are currently two trackers for libunwind (and several
other transitions actually).  A manually set up one[1] and one set up by
a new tool we are testing[2].  The latter are prefixed with auto- to
avoid name clashes with transitions set up manually.

~Niels

[1] http://release.debian.org/transitions/html/libunwind.html

[2] http://release.debian.org/transitions/html/auto-libunwind.html
(also, see the Notes:)



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52b6aef2.6030...@thykier.net

Re: Javahelper automatic depends

[Niels Thykier]

On 2013-10-07 19:37, Wookey wrote:
 I just packaged caveconverter (a fairly small simple command-line java
 package), which uses ant as a build system.
 (currently in new:
 http://ftp-master.debian.org/new/caveconverter_0~20130921-2.html )
 

Hi,

 This all worked fine, except that using
 Depends: ${java:Depends}, ${misc:Depends}
 does not get the right Depends line. 
 I can't recall where I got those magic vars from now. (probbaly
 jh_makepkg)
 

Sounds like something jh_makepkg would add.

 The build-depends line is:
 Build-Depends-Indep: debhelper ( 7), javahelper (= 0.32), ant,
 default-jdk, libcobertura-java, junit
 
 Which results in a Depends line:
 Depends: default-jre | java5-runtime | java6-runtime | java7-runtime,
 jarwrapper (=0.5), junit, libcobertura-java
 
 Which is too much. 
 
 * junit and libcobertura-java are only used for running build tests.

Are they listed in the Classpath (or is it Class-Path?) in the
manifest of the resulting jar file (as installed in the .deb)?  If so,
thats your problem.  Note that jh_depends does not really have a way of
handling optional depends.
  You might still be able to use it to generate the JVM dependency with
-X your-file.jar (to have it ignore your JAR file).

 * default-jre should be default-jre-headless
 * Do I still want those | javaN-runtime options? Are there -headless
 versions?


If memory serves, you want:
  jh_depends --jvm headless

The java5-runtime is possibly a bit redundant, but it shouldn't hurt, so
mah...

 * Should I use java-wrappers instead of jarwrapper? 
 

They work in different ways, so basically it is your call.  The former
requires you to write a shell wrapper to run your jar file (but helps
you find a suitable Java implementation).  On the other hand, jarwrapper
installs a binfmt-misc (or so) rule for making the kernel recognise the
jar file as an executable so that a ./my.jar will DTRT(tm).

jarwrapper is quite possibly simplier to use from a maintainer PoV but
it is also a bit less configurable as I recall.  If you need to pass
options, cd to dirs or set ENV, you probably want java-wrappers rather
than jarwrappers.

 The basic question is is ${java:Depends} useful here. I'd like to have
 a magic var that just does the right thing and will update my
 jre*|java* deps automaticllay on future changes, but if it puts too
 much in then I have a problem? Can I modify it? Or should I just be
 setting Depends manually and if so where is best practice recorded?
 

Assuming the extra depends is caused by Class-Path issues, you should
trivially be able to solve that by fixing the Class-Path to not include
for tests only-dependencies.

 I get the impression that
 www.debian.org/doc/packaging-manuals/java-policy/ is rather out of
 date. Is there somewhere else this stuff is written down?
 

The Java Policy could possibly use an update or two.  I believe someone
signed up for that during the Java BoF at DebConf13, but I forgot who.

 My best guess currently is that the depends line should be:
 default-jdk-headless | java-runtime6 | java-runtime7, java-wrapper, 
 ${misc:Depends}
 

s/runtime\d/-headless/g  (also, see jh_depends --jvm headless)

 Advice welcome.
 
 Wookey
 


~Niels



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5252f4ea.40...@thykier.net

Re: Upgrading the Debian Policy

[Niels Thykier]

On 2013-09-24 14:38, T o n g wrote:
 Hi, 
 

Hi,

 The package that I want to pick up has a status:
 
 The package should be updated to follow the last version of Debian 
 Policy (Standards-Version 3.9.4 instead of 3.8.3). 
 
 I never knew the details of Debian Policy before, but did try to read the 
 policy from 3.8.4 to 3.9.4, and find it a rather long list with no 
 further details. At first, I was trying to find a wiki/blog dedicated to 
 upgrading the Debian Policy, failing to find that, now I'm thinking,
 

I would recommend using the upgrade checklist:
 http://www.debian.org/doc/debian-policy/upgrading-checklist


 If I can fix all lintian reported issues, it'll be safe to say that I've 
 bring the package to the last version of Debian Policy, right? 
 

No. Never[1]:


Lintian is not finished yet and will probably never be. Please don't use
Lintian as a reference for Debian policy. Lintian might miss a lot of
policy violations while it might also report some violations by mistake.
If in doubt, please check out the policy manuals.


 PS. the lintian proposed to me before is:
 
  lintian --color=always -I -E -i --pedantic
 
 Thanks
 
 
 

~Niels

[1] http://lintian.debian.org/manual/section-1.4.html



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52418bf9.6070...@thykier.net

Re: Upgrading the Debian Policy

[Niels Thykier]

On 2013-09-24 14:48, Dominik George wrote:
 If I can fix all lintian reported issues, it'll be safe to say that I've 
  bring the package to the last version of Debian Policy, right? 
 No. It is safe to say that if, and only if, you bump the
 Standards-Version field to 3.9.4 and *then* have lintian be silent.
 

Lintian does not down-scale its checks based on the S-V field; so you
will get (almost) the same result regardless of what value you put in
the field.  The obvious exception is checks that actually cares about
the content of the S-V field (which is something like 5 tags or so).

~Niels



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52419347.2050...@thykier.net

Re: Upgrading the Debian Policy

[Niels Thykier]

On 2013-09-24 16:42, Dominik George wrote:
 
 
 Andrew Shadura bugzi...@tut.by schrieb:
 Hello,

 On 24 September 2013 14:48, Dominik George n...@naturalnet.de wrote:

  lintian --color=always -I -E -i --pedantic
 lintian -vIiE --pedantic --color=auto

 Properly reads as -Evil :)
 
 Hi,
 
 please fix your font and/or try not to be funny when you might confuse 
 newbies.
 
 -nik
 
 

I think Andrew was refering to the mnemonic Evil and pedantic[1].

~Niels

[1]
http://nthykier.wordpress.com/2012/02/23/some-sponsors-are-evil-and-pedantic/



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5241a64e.5020...@thykier.net

Re: pdebuild without orig.tar.gz

[Niels Thykier]

On 2013-06-30 18:21, Torquil Macdonald Sørensen wrote:
 Hi!
 
 I'm having some problems using pdebuild recently. I'm pretty sure this
 command worked before, and I have updated my pbuilder chroot.
 
 I don't have a orig.tar.gz, so I ask it to build a binary package, but I
 get this:
 
 ***
 [...]
 **
 
 Is this not the correct procedure to build binary packages without
 having an orig.tar.gz? Maybe my memory is fooling me, but I think it
 worked earlier.
 
 I'm using Sid.
 
 Best regards
 Torquil Sørensen
 
 

I am fairly sure you can use dpkg-buildpackage -b directly without the
orig.tar (at least I remember doing that in the past).  But if memory
serves, what pdebuild does is build source, run pbuilder on
../file.dsc, so I don't think that ever worked for pdebuild.

~Niels



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51d05c18.1020...@thykier.net

Re: How to handle a package triggering ice or segv during build?

[Niels Thykier]

On 2013-06-17 11:59, Thomas Moulard wrote:
 On Mon, Jun 17, 2013 at 1:34 PM, Paul Wise p...@debian.org wrote:
 [...]

 So what you need to do is move the building of the documentation into
 the build-indep debian/rules target (instead of the build target).
 That way it will not be built and thrown away on the buildds.
 
 Ok, I understand now. I investigated a bit and wrote this patch [1].
 
 However, [2] and [3] seem to imply there is more do to than this simple patch.
 Could you confirm whether these information are obsolete or not?
 
 (this patch works for me in pbuilder / when I call dpkg-buildpackage -B)
 
 [1] 
 http://anonscm.debian.org/gitweb/?p=debian-science/packages/visp.git;a=commitdiff;h=6994be42b1aa3e5d700187fd432a09abb4e542e4;hp=0361f28d746259e3131928c12786e90b7aace299
 [2] http://asylum.madhouse-project.org/blog/2012/01/26/buildd-workarounds/
 [3] http://nthykier.wordpress.com/2011/11/11/build-arch-for-everyone/
 

[2] and [3] are obsolete in the sense that dpkg currently carries a
work around to detect if the build-arch / build-indep targets are
present.  If that can be reliably detected for your d/rules then you
shouldn't have a problem with adding/using these targets[4].

~Niels

[4] Either explicit targets (e.g. build-arch:) and the catch-all
target % works just fine AFAIK.



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51bedf54.8060...@thykier.net

Re: Lintian false positive about virtual package depends?

[Niels Thykier]

On 2013-05-11 20:32, Sven Joachim wrote:
 On 2013-05-11 20:17 +0200, Torquil Macdonald Sørensen wrote:
 
 On 11/05/13 20:10, Sven Joachim wrote:
 On 2013-05-11 19:50 +0200, Torquil Macdonald Sørensen wrote:

 Does anyone know why lintian would think that libmpich-dev, which is a
 new package that will appear with the newer mpich-packages, is a
 virtual package?

 You should probably version the dependency, did you do that?

 Yes, I have:

 Package: libmpich2-dev
 Architecture: any
 Section: libdevel
 Depends: libmpich-dev (= ${binary:Version}), ${misc:Depends}
 Description: ...
 
 In that case it seems to be a bug in lintian, if only because a
 versioned dependency can never be fulfilled by a virtual package.
 
 Just to make sure: there is a libmpich_3.0.4-1_amd64.deb along the
 mpich_3.0.4-1_amd64.changes file?
 
 Cheers,
Sven
 
 

I am fairly sure Lintian emits that tag based on a static data file.  If
you are adding a non-virtual variant that package now for inclusion in
the archive, just file a bug against lintian for those data files to be
updated.

~Niels



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/518e8f86.3000...@thykier.net

Re: Sponsorship

[Niels Thykier]

On 2013-04-20 23:56, Nathan Owens wrote:
 Is there a way I can find out who my previous sponsor for my package
 'dwb' is?
 
 

who-uploads dwb

~Niels



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51730f4b.1020...@thykier.net

Re: Build Debian packages for multiple architectures

[Niels Thykier]

On 2013-03-18 18:15, Adam Borowski wrote:
 On Mon, Mar 18, 2013 at 06:17:01PM +0200, Andrii Senkovych wrote:
 Hello, debian-mentors
 
 I'm sorry in advance if this is the wrong list to ask.
 
 TL;DR: how to build and upload properly packages that provide
 both arch=all and arch=any binary packages without conflicts like
 file already exists with different checksum during upload
 stage?
 
 1) upload source package ond binary packages for one arch (this
 upload seems to include the packages with 'all' arch as well) 2)
 upload binary packages for all other architectures
 
 So, the question is: how should I build packages for multiple 
 architectures without such problems?
 
 dpkg-buildpackage -B
 
 This runs only the binary-arch target but not the rest.
 

Also, see mergechanges(1) from devscripts, which can you from signing
several changes files.

~Niels



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51474d14.5040...@thykier.net

Re: RFS: awstats/7.1~dfsg-1 (2nd try)

[Niels Thykier]

On 2013-02-23 12:26, Sergey B Kirpichev wrote:
 The reason I am asking is that if we do this upload to unstable and
 later we find an annoying important bug (i.e. severity important), then
 we can no longer fix it for Wheezy[1].
 
 Looks like there is testing-proposed-updates for that, isn't?
 
 --8--
 Rule #5. If the version in unstable already includes significant
 changes not related to the bug to be fixed, contact the release team
 about uploading to testing-proposed-updates. Changed dependencies, new
 upstream versions, changed library names and completely rewriting the
 packaging are significant changes.
 --8--
 

Truly, tpu can be used for any RC bug.  However, I was referring to:


  3. fixes for severity: important bugs in packages of priority:
 optional or extra, only when this can be done via unstable;


Btw, there is a caveat here for people maintaining libraries.  A new
version of a library in unstable can prevent other's package from being
able to migrate via unstable.
  Anyway, awstats have no rdeps, so the caveat does not apply here.
Just mentioning for your (and people on d-mentors@l.d.o) information.

 As I see it, this is your package so the final choice is yours in this
 mattter.  I just wanted to make sure you were aware of the possible
 consequences.
 
 Thus, I'm not sure you are correct.  But anyway, there is no important
 bugs right now for this package.
 

I know; I wrote if we later find an important bug.  :)

Anyway, uploaded.

~Niels


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/512a0092.60...@thykier.net

Re: RFS: awstats/7.1~dfsg-1 (2nd try)

[Niels Thykier]

On 2013-02-22 16:59, Sergey Kirpichev wrote:
 On Fri, Feb 22, 2013 at 1:59 AM, Niels Thykier ni...@thykier.net wrote:
 I think I could be convinced to do at least a onetime upload of the package.
 
 Thank you.  Let's hope someday I can handle package myself, as before.
 

Indeed.  :)

 [...]
 
 The upload appears to be targetting unstable while we are in a freeze
 and the changes do not appear to freeze material - intentional or should
 it have been experimental instead?
 
 ??  That's just a regular unstable upload.  It's not supposed to go in 
 testing for wheezy.
 
 [...]


The reason I am asking is that if we do this upload to unstable and
later we find an annoying important bug (i.e. severity important), then
we can no longer fix it for Wheezy[1].
  As I see it, this is your package so the final choice is yours in this
mattter.  I just wanted to make sure you were aware of the possible
consequences.

~Niels


[1] Well, we could revert the 7.1 upload in an 1:7.0 upload.  Anyway,
current freeze policy is:
  http://release.debian.org/wheezy/freeze_policy.html

It is also possible that the fix can go into the first point release,
but that is still post-Wheezy.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5128814d.2090...@thykier.net

Bug#695991: RFS: awstats/7.1~dfsg-1 (2nd try)

[Niels Thykier]

On 2013-02-08 08:16, Sergey Kirpichev wrote:
   Dear mentors,
 
 I am looking for a sponsor for my package awstats. I have problems
 getting in touch with the Debian Developer (Jonas Smedegaard) that
 I've originally worked with.  Could someone else update my DM flag as
 per new procedure[1]?  Or just upload package once?
 

Hi,

I think I could be convinced to do at least a onetime upload of the
package.  Please CC me on replies.

 Closes bugs: 641481 687414 690379 698921
 
  Package name : awstats
  Version  : 7.1~dfsg-1
  Homepage : http://awstats.sourceforge.net/
  License  : GPL-2
  Section  : web
  RFS bug  : http://bugs.debian.org/695991
 
   It builds those binary packages:
 
   awstats - powerful and featureful web server log analyzer
 
   To access further information about this package, please visit the
 following URL's:
 
   http://mentors.debian.net/package/awstats
   http://mentors.debian.net/debian/pool/main/a/awstats/awstats_7.1~dfsg-1.dsc
 
 

In d/changelog, the package on mentors includes an entry for 7.0~dfsg-8
which has not been uploaded to Debian AFAICT (but targets/targeted
unstable).  The lines in that entries seem to be a subset of the ones
for 7.1~dfsg-1, is this by intention.

The upload appears to be targetting unstable while we are in a freeze
and the changes do not appear to freeze material - intentional or should
it have been experimental instead?


You can probably get rid of this code in d/rules:

  
  # Binarize (and cleanup) Debian-shipped non-trademarked Firefox icon
  pre-build::
uudecode -o debian/icons/firefox.png debian/icons/firefox.png.uu
  clean::
rm -f debian/icons/firefox.png
  

With 3.0 (quilt) you can store binary files in the debian part (you
just have to add it to d/source/include-binaries).

There is also a mangle rule in d/rules that looks a bit outdated (I
guess it isn't used anymore?):


  DEB_UPSTREAM_TARBALL_BASENAME_MANGLE = s/(-6\.9)\.(\d)/$$1$$2/


~Niels


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/512698dd.8040...@thykier.net

Re: Hardening-check reports on hardened object

[Niels Thykier]

On 2013-02-20 09:56, Olе Streicher wrote:
 Just override lintian?
 
 Best
 
 Ole

Yes.

~Niels


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51249588.8060...@thykier.net