RFS: zd1211-firmware (updated package)

[Christian Kastner]

Dear mentors,

I am looking for a sponsor for the new version 3.0.0.56-1
of my package "zd1211-firmware".

It builds these binary packages:
zd1211-firmware - Firmware images for the zd1211rw wireless driver


This is a new upstream release from a new upstream source
(vendor-provided). Almost all changes are one-liners; the only exception
is the addition of a trivial python script which generates the binary
images from 10 header files (our old upstream used to do this for us).

The package appears to be lintian clean.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/non-free/z/zd1211-firmware
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/non-free/z/zd1211-firmware/zd1211-firmware_3.0.0.56-1.dsc

I would be glad if someone uploaded this package for me.

Thanks,
Christian




signature.asc
Description: OpenPGP digital signature

RFS: pyrit

[Christian Kastner]

Dear mentors,

I am looking for a sponsor for my package "pyrit".

* Package name: pyrit
  Version : 0.3.0-1
  Upstream Author : Lukas Lueg 
* URL : http://code.google.com/p/pyrit/
* License : GPLv3 + OpenSSL linking exception
  Section : net

It builds these binary packages:
pyrit  - A GPGPU-driven WPA/WPA2-PSK key cracker

The package appears to be lintian clean.

The upload would fix these bugs: 570918


Pyrit is an excellent example of a GPGPU-driven application. It consists
of a main program and optional extensions for various GPGPU
technologies, such as NVIDIA CUDA and OpenCL.

This package provides the main program. It is fully functional version
of Pyrit, but lacks support for non-free technologies such as CUDA.
These technologies will be supported via separately distributed python
extensions (see ITP #582315) in contrib.

Upstream is very responsive.


The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/p/pyrit
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/p/pyrit/pyrit_0.3.0-1.dsc

I would be glad if someone uploaded this package for me.


Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: RFS: pyrit

[Christian Kastner]

On 05/20/2010 03:58 PM, Paul Wise wrote:
> On Thu, May 20, 2010 at 9:24 PM, Christian Kastner  wrote:
> 
>> Pyrit is an excellent example of a GPGPU-driven application. It consists
>> of a main program and optional extensions for various GPGPU
>> technologies, such as NVIDIA CUDA and OpenCL.
> 
> Do we have OpenCL support in Debian main?

Not yet, but it's being worked on. I've been in contact with the NVIDIA
Team, they expect the NVIDIA toolkit (with CUDA and OpenCL support) to
be available RSN, see #581184.

I don't anticipate an OpenCL extension for pyrit, though. That would
require binary packages for each specific vendor implementation (eg
pyrit-opencl-nvidia). You might as well just use pyrit-cuda.


-- 
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/4bf547e6.8000...@kvr.at

Re: RFS: pyrit

[Christian Kastner]

On 05/21/2010 03:27 AM, Paul Wise wrote:
> On Thu, May 20, 2010 at 10:32 PM, Christian Kastner  wrote:
>> On 05/20/2010 03:58 PM, Paul Wise wrote:
>>> Do we have OpenCL support in Debian main?
>> Not yet, but it's being worked on. I've been in contact with the NVIDIA
>> Team, they expect the NVIDIA toolkit (with CUDA and OpenCL support) to
>> be available RSN, see #581184.
> 
> Unfortunately that is non-free. Unless pyrit works with nouveau or any
> of the drivers in Debian main, I think pyrit should go to contrib.
> 
>> I don't anticipate an OpenCL extension for pyrit, though. That would
>> require binary packages for each specific vendor implementation (eg
>> pyrit-opencl-nvidia). You might as well just use pyrit-cuda.
> 
> Err, isn't the whole point of OpenCL that it is cross-vendor???

For reference:
http://lists.debian.org/loom.20100521t083642-...@post.gmane.org



-- 
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/4bf67c1a.1000...@kvr.at

RFS: pyevolve

[Christian Kastner]

Hello,

I am looking for a sponsor for my package "pyevolve".

* Package name: pyevolve
  Version : 0.6~rc1~svn397+dfsg-1
  Upstream Author : Christian S. Perone 
* URL : http://pyevolve.sourceforge.net
* License : Python License (with upstream subsituted for PSF)
  Section : python

It builds these binary packages:
python-pyevolve - Complete genetic algorithm framework written in pure
python
python-pyevolve-doc - Documentation for the Pyevolve genetic algorithm
framework

The package appears to be lintian clean.

The upload would fix these bugs: 580924


Pyevolve is one of the most complete genetic algorithm frameworks
currently available. It is trivially easy to use out-of-the-box and yet
easily extendable. It also provides extensive documentation.

For a good overview of Pyevolve's feautres and capabilities, see ACM
SIGEVOlution Volume 4 Issue 1, available at http://www.sigevolution.org.

Upstream is very responsive.


The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/p/pyevolve
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/p/pyevolve/pyevolve_0.6~rc1~svn397+dfsg-1.dsc

I would be glad if someone uploaded this package for me.


Thanks,
Christian



signature.asc
Description: OpenPGP digital signature

Re: RFS: zd1211-firmware (updated package)

[Christian Kastner]

On 05/10/2010 07:43 PM, Christian Kastner wrote:
> Dear mentors,
> 
> I am looking for a sponsor for the new version 3.0.0.56-1
> of my package "zd1211-firmware".
> 
> It builds these binary packages:
> zd1211-firmware - Firmware images for the zd1211rw wireless driver
> 
> 
> This is a new upstream release from a new upstream source
> (vendor-provided). Almost all changes are one-liners; the only exception
> is the addition of a trivial python script which generates the binary
> images from 10 header files (our old upstream used to do this for us).

I only now realized that this package FTBFS, due to a missing executable
bit after unpacking. Strange, I was sure I had tested the build with
pbuilder.

I have uploaded a fix, and added two more changes: Vcs-* fields, and a
switch to dh syntax.


What's the policy WRT the Debian revision on such changes, here on
mentors? Should I have bumped the -1 to -2? -1 hasn't been sponsored
yet, so I wasn't sure.


Christian


-- 
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/4c02b5a0.3080...@kvr.at

Re: RFS: zd1211-firmware (updated package)

[Christian Kastner]

On 05/30/2010 09:19 PM, David Kalnischkies wrote:
> Bumping the revision implies mostly that the changes files need to include
> also the "older" versions and the toolset needs to be instructed to do so
> as the default is to only include the last version.
> (See e.g. "man dpkg-genchanges" option -v.)

Good point, thanks.

Christian


-- 
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/4c03f898.2000...@kvr.at

RFS: libfann (updated package)

[Christian Kastner]

Hello,

I am looking for a sponsor for the new version 2.1.0~beta~dfsg-1
of my package "libfann".

It builds these binary packages:
libfann2   - Fast Artificial Neural Network Library
libfann2-dev - Development libraries and header files for FANN
libfann2-doc - API documentation for FANN
python-pyfann - Python bindings for FANN

The package appears to be lintian clean.

The upload would fix these bugs: 297951, 366146, 498227, 558887, 583645


Note: the source package has been renamed from libfann1 to libfann. I
will ask for removal of libfann1 as soon as this version hits testing.


The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/libfann
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/l/libfann/libfann_2.1.0~beta~dfsg-1.dsc

I would be glad if someone uploaded this package for me.

Thanks,
Christian





signature.asc
Description: OpenPGP digital signature

Re: RFS: libfann (updated package)

[Christian Kastner]

On 06/07/2010 08:39 AM, Luca Bruno wrote:
> Christian Kastner scrisse:
> 
>> I am looking for a sponsor for the new version 2.1.0~beta~dfsg-1
>> of my package "libfann".
>>
>> It builds these binary packages:
>> libfann2   - Fast Artificial Neural Network Library
>> libfann2-dev - Development libraries and header files for FANN
>> libfann2-doc - API documentation for FANN
>> python-pyfann - Python bindings for FANN
>  
> If nobody step up in the meantime, I'll give it a look in a couple of
> days...

Thanks! A potential sponsor already expressed interest, I hope it's OK
if I ping you if it doesn't work out...

Regards,
Christian


-- 
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/4c0d0147.5010...@kvr.at

Re: RFS: libfann (updated package)

[Christian Kastner]

On 06/06/2010 04:55 PM, Christian Kastner wrote:
> Hello,
> 
> I am looking for a sponsor for the new version 2.1.0~beta~dfsg-1
> of my package "libfann".
> 
> It builds these binary packages:
> libfann2   - Fast Artificial Neural Network Library
> libfann2-dev - Development libraries and header files for FANN
> libfann2-doc - API documentation for FANN
> python-pyfann - Python bindings for FANN

Note for potential sponsors: it was pointed out to me (correctly) that
the git repository was missing the history from libfann-1.2.0 upwards.

I have corrected this, but it requires a fresh clone.


-- 
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/4c0d0223.8000...@kvr.at

Re: Help for watch file

[Christian Kastner]

On 07/09/2010 09:58 AM, Andreas Tille wrote:
> Hi,
> 
> I wonder how I might get a watch file for code.google.com working.
> For FreeDiams I tried
> 
> version=3
> http://code.google.com/p/freemedforms/downloads/list \
>   http://freemedforms.googlecode.com/files/freediams_([.\d]+).*\.tar\.gz
> 
> but uscan does not find any matching entry - probably because all this
> JavaScript which is now injected in this page.  Some time ago the watch
> file worked this way.

version=3
opts=\
downloadurlmangle=s|.*[?]name=(.*?)&.*|http://freemedforms.googlecode.com/files/$1|,\
filenamemangle=s|[^/]+[?]name=(.*?)&.*|$1| \
http://code.google.com/p/freemedforms/downloads/detail[?]name=freediams_([0-9.]+).orig.tar.gz&.*

Taken from #581622 "[qa.debian.org] Please provide a code.google.com redirector"

Regards,
Christian


-- 
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/4c374039.4020...@kvr.at

Re: Problem with uscan --repack

[Christian Kastner]

On Wed, 25 May 2011 06:48:56 +0200, Daniele Tricoli wrote:

Hi all,
I'm taking care of python-peak.util (under the umbrella of DPMT) and 
to
close #606382 I have to obtain a new orig tarball. python-peak.util 
is a

multi-upstream source package but obtain a new orig tarball in not a
difficult task because Stefano Zacchiroli made a get-orig-source 
target

inside debian/rules and you have only to invoke it.

get-orig-source target uses uscan and I'm having problems with it. On 
my

development box with Debian Wheezy (devscripts 2.10.73) I get:

$ uscan --watchfile debian/peak.util-addons.watch --repack \

--upstream-version 0 --package peak.util-addons --download \
--destdir get-orig-source.tmp/ --verbose

-- In debian/peak.util-addons.watch, processing watchfile line:
   
http://pypi.python.org/packages/source/A/AddOns/AddOns-([0-9a-z.]+)\.zip

-- Found the following matching hrefs:
 AddOns-0.6.zip
 AddOns-0.7.zip
Newest version on remote site is 0.7, local version is 0
 => Newer version available from
http://pypi.python.org/packages/source/A/AddOns/AddOns-0.7.zip
-- Downloading updated package AddOns-0.7.zip
-- Repacking from zip to .tar.gz
tar (child): get-orig-source.tmp/AddOns-0.7.tar.gz: Cannot open: No 
such

file or directory
tar (child): Error is not recoverable: exiting now
Repacking from zip to tar.gz failed (could not create tarball)


This is a regression introduced by devscripts 2.10.72. I supplied a fix 
for some other issues (see #615108), and it appears to have been 
incomplete as the --destdir option no longer works with relative paths. 
I'll report a bug against devscripts with a patch tonight.



On Lenny (I don't have a Squeeze box at the moment) the command above
works... man uscan did not help so looking at the source code (I 
don't use

Perl) What am I missing?

I noticed that using --destdir /tmp/ works but is not what I need.


You can temporarily work around this by using an absolute one, eg: 
--destdir $PWD/get-orig-source.tmp



Regards,
Christian


--
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/9ff158e3b336871926f9b7bdae4c1...@kvr.at

Re: Nitpicking: you are doing it wrong

[Christian Kastner]

On 07/08/2011 12:29 PM, Arno Töll wrote:
> On 08.07.2011 18:24, Adam Borowski wrote:
>> If you don't make use of newest shiniest features, higher debhelper
levels
>> just make backporting harder for no gain.
>
> There is debhelper 8 in both, lenny-backports as well as in
> squeeze-backports.

There's no debhelper 8 in Ubuntu Lucid and earlier, though.

(FYI, debhelper 8 is already in Squeeze, you don't need bpo)

> Moreover Debian packages target Sid, not (Old-) Stable, and this is
> where efforts should be invested in. Moreover backports are something
> optional, not a requirement for new packages, or something which should
> even necessarily kept in mind when working on packages.

I disagree strongly on the latter. I try to be kind to backporters, even
to deriviatives (eg, regarding Lucid above: I don't even use Ubuntu), so
unless there is a compelling reason to use compat level 8, I'll stick to 7.

The above of course can be generalized to any package, and simplified to
"unless there is a compelling reason to require version $BAR, I'll stick
to $FOO" -- which I believe is only common sense.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: tophat: Help needed with boost

[Christian Kastner]

On 2014-03-18 14:19, Andreas Tille wrote:
> segment_juncs.o: In function `boost::thread::get_id() const':
> /usr/include/boost/thread/detail/thread.hpp:730: undefined reference to 
> `boost::thread::native_handle()'
> segment_juncs.o: In function `boost::thread::join()':
> /usr/include/boost/thread/detail/thread.hpp:756: undefined reference to 
> `boost::thread::join_noexcept()'
> segment_juncs.o: In function `~thread':
> ...

Looking the command that generates this output, you can see that it's
missing -lboost_thread and -lboost_system:

> g++  -Wall -Wno-strict-aliasing -g -gdwarf-2 -Wuninitialized  -O3 -g -O2 
> -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security 
> -DNDEBUG -pthread -I/usr/include  -I./SeqAn-1.3 -Wl,-z,relro -L/usr/lib  
> -Wl,-z,relro -o segment_juncs segment_juncs.o ../src/libtophat.a   -lbam -l

The generated Makefiles have empty BOOST_THREAD_LIB and BOOST_SYSTEM_LIB
variables. A bit of investigating reveals that it's the location of the
boost libraries that seems to be the problem, because adding the
following to debian/rules seems to fix the issue:

override_dh_auto_configure:
dh_auto_configure -- \
--with-boost-libdir=/usr/lib/$(DEB_HOST_MULTIARCH)

I'm not entirely sure that's the correct solution to the problem,
though. Perhaps someone with more Multiarch + autotools experience can
enlighten us.

Christian





-- 
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/532858b9.3050...@kvr.at

Bug#741501: RFS: libb2/0.96-1 [ITP]

[Christian Kastner]

Hi,

On 2014-03-13 05:57, Robert Ransom wrote:
> I am looking for a sponsor for my package "libb2":

I'm not a DD so I can't sponsor your package, but here is a quick review:


Building


There is one troublesome aspect of the upstream code: AFAICT,
CPU-specific optimizations such as MMX, SSE, etc. are detected and
enabled at compile-time.

That is a problem because your binary packages will end up with
optimizations specific to the buildd they were built upon, but the
platforms they will run upon might lack support for those optimizations.

I suggest you either verify that this is not a problem (eg run-time
support detection) or disable some of those optimizations.

The debian-kernel@l.d.o will probably be able to you which instruction
sets you are allowed to assume as always present in certain
architectures (eg "amd64 always has MMX" or some such).


debian/control:
==

Build-Depends: debhelper (>= 9), not debhelper (>= 9.0.0). IIRC there
exists a (written or unwritten) rule for when one can/should truncate
version numbers, but I can't find a source for that at the moment so I
could be wrong. Regardless, debhelper(7) recommends this.

You do not need to specify the Section: for binary packages if the
intended Section matches the source package section, so the "Section:
libs" can be omitted from binary package libb2-1.

If you're using a VCS for your packaging, it would be nice if you could
include Vcs-* URLS pointing to the repository. This simplifies
contributing to your packaging.


debian/copyright:
=

I'd add the Upstream-Contact field to the header section using the
address you specified in the ITP.


debian/rules:
=

You can drop the "Sample debian/rules that uses debhelper" part.


Later releases (somewhat more advanced topics)
==

You could generate minimal dependencies by creating using a symbols
file, see

https://wiki.debian.org/UsingSymbolsFiles

You could install lintian overrides to silence a couple of informational
and pedantic warnings, see

$ lintian -I --pedantic *.deb *.dsc


HTH,
Christian

> To access further information about this package, please visit the
> following URL:
> 
>   https://mentors.debian.net/package/libb2
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/libb/libb2/libb2_0.96-1.dsc
> 
> More information about libb2 can be obtained from .


-- 
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/532b1d42.7030...@kvr.at

Bug#729534: RFS: libpoly2tri/0.3.3-1 [ITP]

[Christian Kastner]

On 2013-11-14 00:32, Bryan Conrad wrote:
>  I am looking for a sponsor for my package "libpoly2tri"

I'm not a DD so I cannot sponsor your package, but hoping that you are
still interested in contributing to Debian (despite the long time passed
since your ITP) I'd like to offer some feedback.

debian/changelog


In the get-orig-source target of debian/rules, you are removing a file
from the original upstream source. This fact should be reflected in the
upstream version number, usually by appending a +dfsg (indicating that
the motive was DFSG-cleaning).

But TBH, I'd skip removing the file entirely and instead keep the
upstream source as-is. See debian/copyright and debian/rules below.

>   * This is my first Debian package

I'd drop this line, as while commendable :-), it does not really
describe a change.


debian/control
==

Build-Depends: debhelper (>= 9) instead of (>= 9.0.0)

Standards-Version can be updated to 3.9.5

Regarding the package description: I'd lowercase the synopsis and
possibly reconsider the structure of the description. There's nothing
wrong with your approach, but one popular approach I'd like to point out
is for the binary packages to share a common first paragraph and then
differentiate in the second paragraph. libssh2-1 and libssh2-1-dev are
good examples. But again, this is just a matter of taste.


debian/copyright


The proper shortname for the license is BSD-3-clause.

I'd add the Upstream-Contact: field to the header section with the
author you specified in the ITP

If you add another Files: section for the "waf" file you're removing in
the get-orig-source target, also with License: BSD-3-clause but with a
different Copyright:, then you can avoid the hassle of removing it,
because it too is licensed under that license.

If you do perform DFSG cleaning, a brief explanation of what/why in the
form of a Comment: field in the header section would be nice.

Whilst there is nothing wrong in licensing your packaging in debian/*
under the GPL-2+, I'd consider licensing debian/patches/* under the
BSD-3-clause so that any patches you might create can easily be included
upstream.


debian/watch


Upstream apparently doesn't provide tarballs or even tags in the
mercurial repo, but upstream does use version numbers (you evidently
found the 0.3.3 in "wscript"). So I'd politely ask upstream to remedy
this by at least tagging a 0.3.3.

This would simplify quite a few things for you. For one thing, you could
drop the (by necessity, I know) very hacky get-orig-source target in
favor of uscan.


debian/rules


You don't really need to remove the waf file, provided you document its
copyright in debian/copyright.

When repacking the source, consider using xz (-J) instead of gzip (-z).

Hardcoding $HASH.zip and the 0.3.3 version is not really pretty but I
guess that can't be avoided unless upstream agrees to tag a release.


debian/libpoly2tri0.3.symbols
=

This is problematic. First, you need to demangle the symbols in there
with c++filt (for examples, your package FTBFS on my host without this). See

https://wiki.debian.org/UsingSymbolsFiles

at the bottom on how to do this.

But as you will also see from that page, symbols files for C++ can be
quite a hassle and maybe even not worth it, so you might consider
dropping it all together.


debian/patches
==

Consider supplementing your patches with DEP3-headers, see

http://dep.debian.net/deps/dep3/


README.source
=

This is apparently the example README.source. If you don't need to it,
remove it.


debian/source.lintian-overrides
===

This file should actually be called debian/source/lintian-overrides.


HTH,
Christian



> 
> * Package name: libpoly2tri
>   Version : 0.3.3-1
>   Upstream Author : Mason Green 
> * URL : http://code.google.com/p/poly2tri/
> * License : BSD
>   Section : libs
> 
>  It builds those binary packages:
> 
>libpoly2tri-dev - Development headers for libpoly2tri
>libpoly2tri0.3 - Lightweight triangulation library for simple polygons
> 
>  To access further information about this package, please visit the following 
> URL:
> 
>  http://mentors.debian.net/package/libpoly2tri
> 
> 
>  Alternatively, one can download the package with dget using this command:
> 
>dget -x 
> http://mentors.debian.net/debian/pool/main/libp/libpoly2tri/libpoly2tri_0.3.3-1.dsc
> 
>  More information about libpoly2tri can be obtained from 
> http://code.google.com/p/poly2tri/.
> 


-- 
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/532b6279.5040...@kvr.at

Re: Bug#729534: RFS: libpoly2tri/0.3.3-1 [ITP]

[Christian Kastner]

On 2014-03-20 23:21, Jakub Wilk wrote:
> * Christian Kastner , 2014-03-20, 22:49:
>> This is problematic. First, you need to demangle the symbols in there
>> with c++filt (for examples, your package FTBFS on my host without this).
> 
> I haven't looked into details of this particular package, but in general
> unmangling rarely helps curing FTBFS due to missing symbols. The C++
> mangling rules are (mostly?) architecture-idependent. What does vary
> with architecture are how various types (size_t, intN_t, va_list, etc.)
> are typedefed. But demangling doesn't help dealing with this variation.
> 
> For example, symbol names for a f(size_t) function are:
> _Z1fj on i386,
> _Z1fm on amd64.
> 
> After unmangling it becomes:
> f(unsigned int) on i386,
> f(unsigned long) on amd64.

Interesting. TBH, I glanced over the result and prematurely jumped to a
conclusion, I guess. Time to take another look.


-- 
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/532b6bad.4010...@kvr.at

Re: Bug#729534: RFS: libpoly2tri/0.3.3-1 [ITP]

[Christian Kastner]

On 2014-03-20 23:21, Jakub Wilk wrote:
> For example, symbol names for a f(size_t) function are:
> _Z1fj on i386,
> _Z1fm on amd64.
> 
> After unmangling it becomes:
> f(unsigned int) on i386,
> f(unsigned long) on amd64.

Well, after researching a bit, the only somewhat manageable solutions I
can think of are either

A) using symbols.common + symbols.$arch
B) using symbols.common + symbols.arch, using (arch= ) tags
C) using symbols + (c++|regex) tags

None are appealling, and enough doubt about the usefulness has already
been cast by others.

Or did I miss something?


-- 
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/532b731b.40...@kvr.at

Re: Bug#729534: RFS: libpoly2tri/0.3.3-1 [ITP]

[Christian Kastner]

On 2014-03-21 00:00, Christian Kastner wrote:
> On 2014-03-20 23:21, Jakub Wilk wrote:
> A) using symbols.common + symbols.$arch
> B) using symbols.common + symbols.arch, using (arch= ) tags
> C) using symbols + (c++|regex) tags

Missed an obvious one:

D) using symbols + (c++|arch=) tags


-- 
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/532b738a.8010...@kvr.at

Bug#741501: RFS: libb2/0.96-1 [ITP]

[Christian Kastner]

On 2014-03-31 12:37, Robert Ransom wrote:
> On 3/20/14, Christian Kastner  wrote:

>> debian/control:
>> ==
>>
>> Build-Depends: debhelper (>= 9), not debhelper (>= 9.0.0). IIRC there
>> exists a (written or unwritten) rule for when one can/should truncate
>> version numbers, but I can't find a source for that at the moment so I
>> could be wrong. Regardless, debhelper(7) recommends this.
>>
>> You do not need to specify the Section: for binary packages if the
>> intended Section matches the source package section, so the "Section:
>> libs" can be omitted from binary package libb2-1.
> 
> dh-make-0.61 generated the duplicate Section field and a “debhelper
> (>= 8.0.0)” Build-Depends item.  dh-make-0.63 appears to still
> generate these.  When I upgraded the package to debhelper 9 for
> multi-arch support, I changed only the major version number, under the
> assumption that dh-make would not have added the “.0.0” unnecessarily.
> 
> If the changes you suggest are worth making, they are worth making in
> dh-make first.

I submitted a bug for the duplicate section issue, see #743233. The
debhelper version issue has already been reported as #730741.

Also, please note that dh-make, while very helpful, is not an
authoritative tool. Packages should adhere to the Debian Policy and
other authoritative standards regardless of how the packaging was generated.

>> If you're using a VCS for your packaging, it would be nice if you could
>> include Vcs-* URLS pointing to the repository. This simplifies
>> contributing to your packaging.
> 
> I am not using a version-control system for this package.  I would not
> have a trustworthy place to publish a version-control repository for
> this package even if I were using a VCS.

Debian provides such an infrastructure. The following link should get
you started, if you are interested:

https://wiki.debian.org/Alioth/PackagingProject


>> debian/copyright:
>> =
>>
>> I'd add the Upstream-Contact field to the header section using the
>> address you specified in the ITP.
> 
> * dh-make-0.61 and dh-make-0.63 do not include an Upstream-Contact
>   field in the copyright files they generate.

See my remark regarding dh-make above.

> * The e-mail address specified in the ITP bug for this package is
>   hosted on the same domain name as the upstream web site (which is
>   specified in the copyright file and which lists more complete
>   contact information for the upstream maintainers), so in the
>   specific case of this package, I see no possible benefit to
>   including that e-mail address in an Upstream-Contact field.

The driving idea behind the copyright format 1.0 (to which the Format
field refers) is for it to (also) be machine-readable. So while you are
correct in the sense that a human reader might easily deduce this
information, an automatic parser will probably not, so there is indeed a
benefit to including this field.

>> debian/rules:
>> =
>>
>> You can drop the "Sample debian/rules that uses debhelper" part.
> 
> I'm not willing to remove the attribution from that file.
> 
> If the dh-make template authors do not want their work attributed to
> them, they can modify dh-make to not copy that notice into its output.

That notice includes the "use without restriction", which includes
dropping that useless notice.

"Useless" because even without the notice, the trivial content of that
file would almost certainly not be copyrightable, which is also why it
was removed in version 0.63. See #721849.

>> Later releases (somewhat more advanced topics)
>> ==
>>
>> You could generate minimal dependencies by creating using a symbols
>> file, see
>>
>> https://wiki.debian.org/UsingSymbolsFiles
> 
> According to that page, adding a symbols file and maintaining it
> imperfectly is worse than not including a symbols file at all.  Since
> this package is security-critical and I don't expect it to have
> frequent updates, I would prefer to not add a symbols file for it.
> 
> If upstream does start to release new versions frequently, I will
> consider adding a symbols file.

Fair enough, although I'd like to point out that the major problems seem
to come from C++ code, which your library isn't.

Speaking for myself, I found that maintaining symbols files for C is
quite easy, and C++ really is just a burden.

>> You could install lintian overrides to silence a couple of informational
>> and pedantic warnings, see
>>
>> $ lintian -I --pedantic *.deb *.dsc
> 
> It is inappropriate to add overrides for lintian messages at info
>

Bug#740043: RFS: powerline/0~20140216-1 [ITP]

[Christian Kastner]

Hi Jerome,

On 2014-02-25 06:36, Jerome Charaoui wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "powerline"
> 
>  * Package name: powerline
>Version : 0~20140216-1
>Upstream Author : Kim Silkebækken
>  * URL : https://github.com/Lokaltog/powerline
>  * License : Expat
>Section : python
> 
> It builds those binary packages:
> 
>   fonts-powerline - ultimate statusline/prompt utility (font)
>   powerline  - ultimate statusline/prompt utility
>   python-powerline - ultimate statusline/prompt utility (library)
>   python-powerline-doc - ultimate statusline/prompt utility (documentation)
> 
> To access further information about this package, please visit the
> following URL:
> 
>   http://mentors.debian.net/package/powerline
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x
> http://mentors.debian.net/debian/pool/main/p/powerline/powerline_0~20140216-1.dsc

I'm not a DD so I can't sponsor your package. I was hoping to contribute
with a review, but I couldn't find any flaw in your packaging.

A nice-to-have though would be Vcs-* URLs in debian/control to simplify
contributing to your packaging, if you're using a VCS. You can also use
Debian's infrastructure, see:

https://wiki.debian.org/Alioth/PackagingProject

Regards,
Christian


-- 
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/53402367.5070...@kvr.at

Bug#683120: RFS: yadifa/1.0.3-1 [ITP]

[Christian Kastner]

Hi,

On 2014-03-18 22:34, Markus Schade wrote:> However there is one
question, which I am not sure, what is correct.
> Upstream uses /var/zones as base for its zone files. My guess was
> that this is not the proper location for such files in Debian. So I
> changed it to /var/cache/yadifa like bind9, but I welcome any 
> suggestions if there is a more appropriate location.

AFAIK bind9 only stores run-time data in /var/cache/bind (from dynamic
DNS updates, etc). bind9's zone files are in /etc/bind/zones.

The FHS [0] to which Debian adheres (with some exceptions) states for
/var/cache that

"the cached files can be deleted without data loss".

I guess that is not what you want ;-)

I'd either go with /etc/yadifa or /var/lib/yadifa. Check the FHS to
decide which directory fits best.

Note that the example debian/yadifad.conf assumes /var/lib/yadifa.

> I have made some corrections/improvements and re-uploaded the
> package again.

> To access further information about this package, please visit the 
> following URL:
> 
> http://mentors.debian.net/package/yadifa
> 
> Or via dget at
> 
> http://mentors.debian.net/debian/pool/main/y/yadifa/yadifa_1.0.3-1.dsc

I'm not a DD so I can't sponsor your package, but here is a quick review:

debian/control
==

Your Homepage field has trailing whitespace.

If you're using a VCS for your packaging, Vcs-* URLs would be nice (to
simplify contributing to your packaging). You can also use
Debian's infrastructure, see [1].

The Section field of yadifa-dev should be: libdevel.

You're providing static libraries in the -dev package, but not a shared
library package. This is not necessarily wrong, just unusual. Note
that the configure script has an option to build a shared library.


debian/copyright


The Copyright field for the first "Files: *" paragraph seems to be
missing data, the NEWS file lists changes up to 2013.

The License field for that same paragraph should contain the license
short name on the first line, which in your case is standardized as
"BSD-3-clause", see [2].

License: BSD-3-clause


While licensing your packaging under the GPL-2+ is fine, you might want
to consider licensing your patches in debian/patches/* under
BSD-3-clause so that they can easily be including upstream (should you
forward them).


debian/rules


You can drop the "Sample debian/rules" boilerplate, it is useless and
has already been removed from newer versions of dh-make.


Regards,
Christian


[0] http://www.pathname.com/fhs/pub/fhs-2.3.html
[1] https://wiki.debian.org/Alioth/PackagingProject
[2]
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name


-- 
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/53402c6f.6050...@kvr.at

Bug#683120: RFS: yadifa/1.0.3-1 [ITP]

[Christian Kastner]

On 2014-04-09 09:26, Markus Schade wrote:
> thanks for the review, Christian!

Glad I can help :-)

Here is some further feedback:

>> debian/control
>> ==

>> If you're using a VCS for your packaging, Vcs-* URLs would be nice (to
>> simplify contributing to your packaging). You can also use
>> Debian's infrastructure, see [1].

Almost correct. The Vcs-Git URL should use the git:// protocol
specifier, and you could add a Vcs-Browser URL pointing to the github
package, like so:

  -Vcs-Git: https://github.com/asciiprod/yadifa.git
  +Vcs-Git: git://github.com/asciiprod/yadifa.git
  +Vcs-Browser: https://github.com/asciiprod/yadifa

> I had intended to set up a repo after the first upload. But of course it
> is easier to contribute even before that. And since I need a DM approval
> for an Alioth repo, I settled for github for now.

I don't think you need DM approval, you only need a DD to request access
for you (which would probably be the DD sponsoring your package).

But github is more than fine for now, you can always switch later (or
not at all).

>> You're providing static libraries in the -dev package, but not a shared
>> library package. This is not necessarily wrong, just unusual. Note
>> that the configure script has an option to build a shared library.
> 
> Good point. The default was to do static linking. Now with shared libs,
> I have not just two packages but five (three just for the libs). But as
> the recent openssl bug shows, it is easier to just patch a lib than to
> rebuild all depending packages.

Looks good! One major issue though: the libraries are definitely not
Priority: standard :-) (= part of the default Debian installation). You
can simply remove this line, the inherited "optional" is fine.

nit-pick #1: the synopsis refers to Yadifa twice, in different case, and
the other parts should be lowercased. According to the Developer's
Reference[0], something like this would probably be more appropriate:

  -Description: Yadifa DNS Core Shared Library used by YADIFA
  +Description: DNS core shared library used by YADIFA

I like your approach with a common description provided through a
substitution variable! Very efficient.

nit-pick #2: The package descriptions of the libraries could be a bit
more explanatory. (lintian also complains about this). Currently, they
basically just repeat the synopsis. Try to describe what another user of
the library can do with this package. For example, for libdnszone0,

  This library can be use to read and write YADIFA-compliant zone files
  and [...]

(I'm just guessing that, I didn't look). This is much more informative
to developers who might be interested in writing eg GUI client for
modifying zone files. Same goes for the other two libs.

Finally, my personal taste for the package description would be
something like

  - This package contains archive-style libraries and header files for
  - libdnscore0, libdnsdb0 and libdnszone0
  + This package contains the header files and the static libraries
which are
  + needed for developing YAFIDA applications.

but that's highly subjective.

>> debian/copyright
>> 
> 
> I had originally just included upstreams COPYING, but I think it's safe
> to extend the years to include all changes from upstream since then.
> 
> As for my own packaging, I don't mind putting it under a BSD-style license.

Just to clarify: you don't have license all of your packaging under a
BSD-style license., it's sufficient to do that just for the files in
debian/patches/*. The machine-readable copyright format specification[1]
has more details.

> So again, after making these various adjustments and corrections, I have
> re-uploaded the package again.

By the way, if you can't find a sponsor here (it sometimes takes a
while), you can also try pinging either people or teams who might be
interested in your package (eg other DNS maintainers).

Finally, here are some ideas for future versions of your package:
  * build a -dbg package (debhelper can automate lots of this)
  * provide *.symbols files
  * Multi-archification

I say future versions because the value added isn't that big, and when
you've just begun packaging then all this stuff in total can easily
become overwhelming.

Good luck with your package :-)

Christian

> To access further information about this package, please visit the
> following URL:
> 
> http://mentors.debian.net/package/yadifa
> 
> Or via dget at
> 
> http://mentors.debian.net/debian/pool/main/y/yadifa/yadifa_1.0.3-1.dsc

[0]
file:///usr/share/doc/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis

[1]https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/   


-- 
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/53459691.8070...@kvr.at

Bug#683120: RFS: yadifa/1.0.3-1 [ITP]

[Christian Kastner]

On 2014-04-09 20:50, Christian Kastner wrote:
>>> debian/control
>>> ==
> 
> I like your approach with a common description provided through a
> substitution variable! Very efficient.

Oh, I missed something here: you are using the substitution variable
${Description}, but you are not setting it anywhere, which results in
half-empty descriptions (see the output in
debian/libdns*/DEBIAN/control). See deb-substvars(5).

Christian


-- 
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/534598cd.8020...@kvr.at

Re: Library packaging and missing .a file

[Christian Kastner]

On 2014-04-24 08:16, Dariusz Dwornikowski wrote:
> dh_install: libstrophe-dev missing files (usr/lib/lib*.a), aborting
> 
> The libstrophe.a file is installed into /usr/lib/x86_64-linux-gnu,
> instead of /usr/lib. When should the .a file be installed into
> /usr/lib and when into x86... ?

The new destinations are compliant with the multiarch specification[0].
You're probably using debhelper compat level 9, which automates much of
this.

> My .install file looks like this, however dh_auto_install still
> installs files into x86... because it runs before dh_install. Should I 
> override dh_auto_install and 
> depend only on d/install file ?
> 
> usr/include/* 
>   
>
> usr/lib/lib*.a
> usr/lib/lib*.so
> usr/lib/pkgconfig/*
> usr/share/pkgconfig/*

It is sufficient to change these to eg:

   usr/lib/*/lib*.a

but you should definitely read the implementation guide[1] to check for
other gotchas, etc.


[0] https://wiki.debian.org/Multiarch
[1] https://wiki.debian.org/Multiarch/Implementation


-- 
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/5358c9f3.20...@kvr.at

Re: No upstream versioning

[Christian Kastner]

On 2014-04-24 12:45, Dariusz Dwornikowski wrote:
> On 24.04.14 20:12:12, Benjamin Donald-Wilson wrote:
>> Hello,
>>
>> I'm wishing to package ipad-charge[0] for Debian.[1] The only problem I
>> appear to be having is that the upstream don't version their uploads. I've
>> emailed the developer a few days ago but haven't received a response so far.
>> I'm wondering what I should version it as if I do not receive a reply from
>> the upstream developer?
> 
> Create an issue on github to tag his releases.

If that doesn't work, another possibility would be to create a mock
version number based on the date, for example MMDD.{7-digit-commit-ID}.

>> [0]: https://github.com/mkorenkov/ipad_charge
>> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743798
> 


-- 
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/5358ec4d.5060...@kvr.at

Re: Library packaging and missing .a file

[Christian Kastner]

On 2014-04-25 07:58, Dariusz Dwornikowski wrote:
>> On 24.04.14 10:23:23, Christian Kastner wrote:
> I have got another problem. Libstrophe only provides .a file, no .so,
> so basically it should provide only a -dev package. Is it ok to
> package only -dev, or is it agains policies?

Not that I'm aware of, but I very much question the usefulness of having
only a -dev package within the Debian archive.

If I were you, I'd simply patch upstream's build configuration to build
a shared library as well (and then forward the patch). Your upstream is
using autotools, so that should be trivial.

Christian


-- 
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/535a076c.30...@kvr.at

Re: No upstream versioning

[Christian Kastner]

On 2014-04-29 00:22, Octavio Alvarez wrote:
> Wouldn't this version scheme open the possibility an incorrect timeline?
> For example, commit 20140428.1234567 would be considered previous than
> 20140428.2345678 when this may not necessarily be the case in the git
> history.

While theoretically correct, I don't see any practical scenarios where
this might happen. You'd have to create a release based on some upstream
commit, and later on create a new release based on another commit from
that same day (because otherwise MMDD would change, and you'd have
correct ordering again) for this to be a problem.


-- 
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/535ee9f7.90...@kvr.at

Re: managing patches

[Christian Kastner]

On 2016-07-04 06:23, Herminio Hernandez Jr wrote:
> I have a question regarding managing patches. I am wondering is there
> a way to merge multiple patches into one or is there way to rollback
> from a patch?

I'm not quite sure what you mean by "rolling" back from a patch (that's
probably something for a Vcs, or quilt(1)), but regarding the merge: it
sounds as if you're looking for combinediff(1), from package patchutils.

If you're using git, you might want to look at the "git rebase -i" and
"git merge --squash" commands.

If you're using quilt, "quilt fold" might also be helpful.

Regards,
Christian

Bug#756452: RFS: libcap2/2.24-4 [ITA] -- POSIX 1003.1e capabilities

[Christian Kastner]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a new version of package libcap2. It
builds the following binary packages:

  libcap-dev - POSIX 1003.1e capabilities (development)
  libcap2 - POSIX 1003.1e capabilities (library)
  libcap2-bin - POSIX 1003.1e capabilities (utilities)
  libpam-cap - POSIX 1003.1e capabilities (PAM module)

The package builds lintian-clean with sbuild. The source package can be
found here:

http://www.kvr.at/debian/pool/main/libc/libcap2/libcap2_2.24-4.dsc

Changes since the last revision:
  * debian/control:
- Set myself to maintainer. Closes: #756091
- Drop redundant Section
- Drop redundant Priority fields
- Add Multi-Arch field for libcap2-bin
- Point Vcs-* URLs to collab-maint
  * debian/rules:
- Drop dh_builddeb override, xz is now default
- Drop override_dh_makeshlibs; a symbols file is provided now
  * debian/copyright:
- Add myself
- Add missing copyright for manpages
  * debian/symbols:
- Create symbols file
  * debian/watch:
- Create watch file
  * debian/manpages:
- Fix typo in manpage name (getcaps -> getpcaps)
- Drop capsh.8, upstream ships capsh.1 now
  * debian/patches (refreshed):
- Update headers to play more nicely with gbp-pq
  * debian/patches (added):
- 0004-Don-t-hardcode-build-flags
  Needed so that hardening flags get honored
- 0005-Syntax-fixes-for-man-pages


-- 
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/53d81b21.8090...@kvr.at

Bug#756451: RFS: libcgroup/0.41 [ITA] -- control and monitor control groups

[Christian Kastner]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a new version of package libcgroup. It
builds the following binary packages:

  cgroup-bin - control and monitor control groups (transitional package)
  cgroup-tools - control and monitor control groups (tools)
  libcgroup-dbg - control and monitor control groups (debug)
  libcgroup-dev - control and monitor control groups (development)
  libcgroup1 - control and monitor control groups (library)
  libpam-cgroup - control and monitor control groups (PAM)

The package builds lintian-clean with sbuild. The source package can be
found here:

http://www.kvr.at/debian/pool/main/libc/libcgroup/libcgroup_0.41-5.dsc

Changes since the last revision:
  * debian/control:
- Set myself to new maintainer. Closes: #756092
- Use versioned Breaks instead of Conflicts
- Update Vcs- fields to collab-maint
- Drop redundant Section
- Add Multi-Arch fields
  * debian/patches (refreshed):
- Update headers of existing patches to play more nicely with gbp-pq
  * debian/watch:
- Create watch file
  * debian/copyright:
- Added myself
  * debian/patches (added):
- 0005-Syntax-fixes-for-man-pages


-- 
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/53d81b1e.3010...@kvr.at

Bug#756452: RFS: libcap2/2.24-4 [ITA] -- POSIX 1003.1e capabilities

[Christian Kastner]

Hi Vincent,

thanks for another review.

On 2014-08-03 03:28, Vincent Cheng wrote:
>> I am looking for a sponsor for a new version of package libcap2

>> The package builds lintian-clean with sbuild. The source package can be
>> found here:
>>
>> http://www.kvr.at/debian/pool/main/libc/libcap2/libcap2_2.24-4.dsc

I updated this package with a newer version containing the fixes
mentioned below.

>> - Point Vcs-* URLs to collab-maint
> 
> Those Vcs-* urls point to a non-existing git repo; looks like a typo.
> Don't forget to update the collab-maint repo too, with your changes.

That was indeed a typo, thanks.

Regarding the collab-maint repo, what I explained in #756451 applies
here as well, so I've temporarily pushed my changes to this repo:

http://code.kvr.at/git/?p=libcap2.git;a=summary

>>   * debian/rules:
>> - Drop dh_builddeb override, xz is now default
> 
> Similarly, the debian diff (with source format 3.0 (quilt)) is also
> xz-compressed by default, so you can drop debian/source/options.

Dropped.

> debian/copyright:
> - none of the files in contrib/ are documented in d/copyright

I added a block for those files.


Thanks,
Christain


-- 
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/53de0b25.2010...@kvr.at

Bug#756451: RFS: libcgroup/0.41 [ITA] -- control and monitor control groups

[Christian Kastner]

Hi Vincent,

thanks for the review.

On 2014-08-03 03:10, Vincent Cheng wrote:
>> I am looking for a sponsor for a new version of package libcgroup.

>> The package builds lintian-clean with sbuild. The source package can be
>> found here:
>>
>> http://www.kvr.at/debian/pool/main/libc/libcgroup/libcgroup_0.41-5.dsc

I updated this package with a newer version containing the fixes
mentioned below.

>> - Use versioned Breaks instead of Conflicts
> 
> cgroup-tools should also have a versioned Replaces relationship
> against cgroup-bin.

Updated.

>> - Update Vcs- fields to collab-maint
> 
> Please update the collab-maint git repo with your changes.

I'd like to wait with taking over this repository until I have formally
taken over as the maintainer.

In the meantime, I've temporarily pushed my changes to this repo:

http://code.kvr.at/git/?p=libcgroup.git;a=summary

The repo at collab-maint wasn't up-to-date so I git-import-dsc'ed every
missing version from snapshot.debian.org into the repo above.

>>- 0005-Syntax-fixes-for-man-pages
> 
> A small nitpick, DEP-3's Forwarded header usually contains a link to
> the upstream bug report / mailing list archive where the bug was
> forwarded, instead of just "yes".

Habit from other packages, where I talk to upstreams without tracker or
ML directly by mail.

As upstream has a tracker, I removed the Forwarded header for now and
will re-add it, with an URL, once it's added to the tracker. Again, I'd
like to wait until I have taken over the package.

> debian/copyright:
> - src/pam/pam_cgroup.c is dual-licensed BSD and LGPL 2.1, not BSD or
> GPL 2. That also makes the GPL-2 license block in d/copyright
> obsolete.

Hm... while you're right that something is off, the way I read it, it's
mostly (BSD or GPL-2), to which LGPL-2.1 code was added. Therefore, I
updated the License specification and added a standalone block for the
LGPL-2.1.

Side note: it's unclear from the license text and context of this file
which version of the GPL is spoken of, but tracing the original code it
can be seen that it really is the GPL-2.


-- 
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/53de0ae2.4060...@kvr.at

Bug#756451: RFS: libcgroup/0.41 [ITA] -- control and monitor control groups

[Christian Kastner]

On 2014-08-03 12:11, Christian Kastner wrote:
>> debian/copyright:
>> - src/pam/pam_cgroup.c is dual-licensed BSD and LGPL 2.1, not BSD or
>> GPL 2. That also makes the GPL-2 license block in d/copyright
>> obsolete.
> 
> Hm... while you're right that something is off, the way I read it, it's
> mostly (BSD or GPL-2), to which LGPL-2.1 code was added. Therefore, I
> updated the License specification and added a standalone block for the
> LGPL-2.1.
> 
> Side note: it's unclear from the license text and context of this file
> which version of the GPL is spoken of, but tracing the original code it
> can be seen that it really is the GPL-2.

Addendum: I found it strange that the additions to this file were
described as LGPL-2.1, whereas the rest was supposed to be LGPL-2.1+.

It turns out that everything else has always been LGPL-2.1, too.
Upstream ships the full license text, but the individual source files
omit the "[...] or any later version" qualification.

As this is a more serious error, I filed #756915 to document this properly.

A new package with a fix has been prepared at the previously posted
locations.

Christian


-- 
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/53de3184.4070...@kvr.at

Re: Bug#752897:

[Christian Kastner]

On 2014-08-27 03:58, Tobias Frost wrote:
> However, in this case the package needs also different cmake options at
> dh_auto_configure-time, so only override_dh_auto_build-indep will not work as
> you need to disable DENABLE_DOCS during cmake configuration.
> I just wondering if there is also a dh_auto_configure-indep target... (I cant
> test because I'm not near my PC right now)

Yes, there is. There are also *-arch versions of these overrides, so
that you can perform different configurations depending on the build type.

Christian


-- 
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/53fdf74d.4060...@kvr.at

Re: Bug#762228: RFS: ufoai-music review

[Christian Kastner]

Hi Markus,

On 2014-09-20 01:22, Markus Koschany wrote:
> The debian/copyright file is identical for ufoai-data, ufoai-music and
> ufoai-maps.

I find this somewhat confusing.

Generally speaking, I don't believe that listing the copyright of files
which are not part of the source package (in fact, which are part of
another package) is policy-conform, regardless of whether upstream
created the source split, or you.

But specifically, imagine I fork the ufoai package to create my own
modded version, and imagine I think the music is fine so I just depend
on that package instead of forking that one, too. The music package
would then, in its copyright, list incorrect information, as through my
fork, the copyright of some of the other files would have changed.

> I did this on purpose because upstream does not distinguish
> between those files. In fact they maintain everything in one Git
> repository and the LICENSE file contains all copyright information for
> the game data. Thus I decided to use a script to parse all license
> information and then I generated a machine-readable debian/copyright
> file out of them.

> This makes it far easier to review the packages IMO because you only 
> have to check and run the script on LICENSES.

Why not simply modify this script to generate 4 copyright files instead
of 1 (one for each source package)? For example, if the music is in a
subdirectory, you can split by that.

> It also comes with the advantage that all files are machine-readable
> now. Thus wildcards, except for the Files: * paragraph, aren't
> necessary and the whole copyright information are more precise.

If you have a directory base/textures/tex_trak/, and all the files in
there were created by the same author, then listing them individually
or using the "*" glob pattern convey exactly the same amount of
information, but using "*" makes the file far more (human-)readable.


Regards,
Christian



-- 
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/541d3658.5040...@kvr.at

Re: Bug#762228: RFS: ufoai-music review

[Christian Kastner]

On 2014-09-20 13:23, Markus Koschany wrote:
> On 20.09.2014 10:10, Christian Kastner wrote:
>> On 2014-09-20 01:22, Markus Koschany wrote:
>>> The debian/copyright file is identical for ufoai-data, ufoai-music and
>>> ufoai-maps.
>>
>> I find this somewhat confusing.
>>
>> Generally speaking, I don't believe that listing the copyright of files
>> which are not part of the source package (in fact, which are part of
>> another package) is policy-conform, regardless of whether upstream
>> created the source split, or you.
>> But specifically, imagine I fork the ufoai package to create my own
>> modded version, and imagine I think the music is fine so I just depend
>> on that package instead of forking that one, too. The music package
>> would then, in its copyright, list incorrect information, as through my
>> fork, the copyright of some of the other files would have changed.
> 
> Sorry, I don't understand your objection. debian/copyright provides all
> copyright information that you need for the music files in a
> machine-readable format. Did you have a look at the copyright file? What
> information do you think is missing?

Nobody said anything about missing information. It's about superfluous
information. This is inaccurate, at best, and I gave a concrete example
where this might be a problem.

>> Why not simply modify this script to generate 4 copyright files instead
>> of 1 (one for each source package)? For example, if the music is in a
>> subdirectory, you can split by that.
> 
> Yes, you could write even more code to parse nearly 7000 files until
> everyone is satisfied. The question is whether the copyright file is
> Policy compliant already and with the information provided, I think it is.

I did not suggest that. I suggested that instead of writing output to
one one file, your write your output to four.

You're already parsing upstream's LICENSES file in ufoai_copyright.py
and processing it line-by-line, so something as simple as the following
might suffice:

if a_list[0].startswith('base/music'):
   # Do ufoai-music specific output stuff
elif ...
   ...

>>> It also comes with the advantage that all files are machine-readable
>>> now. Thus wildcards, except for the Files: * paragraph, aren't
>>> necessary and the whole copyright information are more precise.
>>
>> If you have a directory base/textures/tex_trak/, and all the files in
>> there were created by the same author, then listing them individually
>> or using the "*" glob pattern convey exactly the same amount of
>> information, but using "*" makes the file far more (human-)readable.
> 
> Debian's copyright format 1.0 is well defined. This is one of the rare
> occasions where you benefit from upstream's careful handling of license
> information and a machine-readable format that makes the accuracy
> visible and in addition it saves time to write d/copyright. There is no
> need for glob patterns if you have a convenient way to reproduce the
> result of the script.

Again, you are ignoring my argument. I said "using * makes the file far
more (human-)readable". MRCF 1.0 just specifies that the format is
*also* machine-readable, but I'm quite sure that the majority of
consumers of debian/copyright are still humans. In the example I gave,
using glob patterns produces the exact same result from a machine's POV,
but a significantly better result from a human's POV.



-- 
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/541d837d.6080...@kvr.at

Re: Bug#762228: RFS: ufoai-music review

[Christian Kastner]

On 2014-09-20 13:02, Markus Koschany wrote:
> On 20.09.2014 09:57, Tobias Frost wrote:
>> My reasoning is, that because of every data package has its own
>> orig.tar, they need to be crafted in a way to so that they will
>> be -- individually looked at -- reach Debian quality requirements. 

To expand on this, try to see this from a contributor's POV.

Say I use ufoai (I do, actually ;-) ), and say I find a bug in the
ufoai-music package. A common way to contribute would `apt-get source
ufoai-music`, and the produce a patch, or debdiff, or whatever.

Say the Security Team wants to upload a security fix for an issue with
ufoai, then they should be able to do so by just getting its source.

Note that these are purely hypothetical examples that are probably not
relevant to ufoai (in total), they serve just to emphasize why it's
important to not just look at a set of (source) packages as a whole, but
also invidually.

> I still don't see why the current copyright file does not meet Debian's
> quality requirements. Instead of one huge 900 MB -data package, the game
> data was simply split into three different source packages. This makes
> it much easier to fix bugs without having to upload all data files every
> time.
> 
> I would like to stress: The source packages are not independent of each
> other, they belong together. It is due to mere technical reasons that
> the -data was split.

I believe that splitting the package was a very good idea, if only to
relieve the buildds (one arch-independent package took almost a day to
build on my Core i7-4770).

However, if you're going to split, then it has to be done "right", as
Tobias emphasized.

> In my opinion we are in full compliance with
> Debian's Policy because
> 
> - we state in d/copyright that the game data was split due to technical
>   reasons
> - we use a reproducible and convenient way to determine all copyright
>   information.

Here's an example for where I see problems with the split: the script to
reproduce the copyright information for ufoai-music is in ufoai, so just
getting ufoai-music's source alone does not help me here.

> - the copyright file is machine-readable and every file in each source
>   package is covered by an license paragraph in debian/copyright.
> 
> Thus the whole copyright file is accurate.

When, in source package $source, you are claiming copyright for a
non-existing file, then that information -- minor issue as it may be --
is most certainly not accurate.

Again, I think you are doing the correct thing with splitting, but I
believe the split is not clean yet.

Regards,
Christian


-- 
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/541d8866.4080...@kvr.at

Re: Bug#762228: RFS: ufoai-music review

[Christian Kastner]

On 2014-09-20 17:33, Markus Koschany wrote:
> On 20.09.2014 15:45, Tobias Frost wrote:
>> Due to the split I say "we now have 4 related, but independent source
>> packages and they should be handled as such".  
>> The Relation is no guarantee that the packages will not diverge in the
>> future. (e.g code could go forward, while data keeps the same, or vice
>> verse)
> 
> Nope, those packages will always be kept in sync with src:ufoai. They
> are not independent source packages and you should simply trust me with
> that statement.

That's the point -- from the POV of the Debian archive, those *are*
independent source packages, regardless of your intentions.

That's why the "cleanliness" of the split is being emphasized so much
here. Nobody is disputing your decision to split (on the contrary I'd
say), but the technical result should conform to what is expected of
*any* source package.

On a side note, there is the possibility that "always be kept in sync"
might not make sense, for example when a hypothetical 2.5.1 release does
not change anything in -music or -maps. (But I may have misunderstood
how far you mean the sync to go).

Christian


-- 
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/541dec08.6010...@kvr.at

Re: Bug#762228: RFS: ufoai-music review

[Christian Kastner]

On 2014-09-20 16:22, Markus Koschany wrote:
> On 20.09.2014 16:02, Tobias Frost wrote:
>> Addendum:
>>
>> On Sat, 2014-09-20 at 15:45 +0200, Tobias Frost wrote:
 Absolutely agreed. But can you point me to examples where the short
 reference to /usr/share/common-licenses was deemed not appropriate by
 the FTP team?
>>
>>
>> From
>> https://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
>> (the FTP master provides that link in their REJECT-FAQ,
>> https://ftp-master.debian.org/REJECT-FAQ.html, under "Copyright")
>> Its from 2006, but still valid)
>>
>>> - Its not enough to have the following two-liner:
>>>   | On Debian systems, the complete text of the GNU General Public License
>>>   | can be found in the `/usr/share/common-licenses/GPL' file.
>>>
>>>   There are license headers, like the one used for GPL in the example 
>>> below, you
>>>   should use those.
>>
> 
> I think that contradicts the information from Debian's Policy and the
> copyright format 1.0 manual and needs further clarification from the FTP
> team. There are many packages that use copyright format 1.0 and the same
> License paragraphs in the same way as I do and I am not aware that
> anybody rejected packages because of that.

Since you are referring to the MRCF 1.0, I think there is a
misunderstanding here. Look at the GPL examples at the bottom that
specification. All Tobias is asking you to do is to prefix your
two-liner with the standard 3-paragraph boilerplate, for a total of 4
paragraphs.


-- 
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/541ded2c.2030...@kvr.at

Bug#767534: FS: librscode/1.3-1 [ITP]

[Christian Kastner]

Package: sponsorship-requests
Severity: wishlist
Control: block 767299 by -1

Dear mentors,

I am looking for a sponsor for my package "librscode".

* Package name: librscode
  Version : 1.3
  Upstream Author : Henry Minsky 
* URL : http://rscode.sourceforge.net
* License : GPL-3+
  Programming Lang: C
  Section : libs

It builds these binary packages:

librscode1 - library implementing a Reed-Solomon error correction
algorithm
librscode-dbg - debugging symbols for RSCODE
librscode-dev - development libraries and headers for RSCODE

To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/librscode

Alternatively, one can download the package with dget using this command:

dget -x
http://mentors.debian.net/debian/pool/main/libr/librscode/librscode_1.3-1.dsc

The git repository for the packaging (gbp) can be found at:

http://anonscm.debian.org/cgit/collab-maint/librscode.git

Changes since the last upload:

* Initial release. Closes: #767299


I'm already a DM, if that helps.


Regards,
Christian Kastner



signature.asc
Description: OpenPGP digital signature

Facilitating contributions by newcomers

[Christian Kastner]

The first steps in contributing to Debian are usually the hardest.
Normally, new contributors are pointed to the standard docs [eg:
1,2,3,4,5], but processing such an amount of information is often a
daunting task, and not a very fun one either.

On the other hand, we have quite a few mentors who would like to help,
but often do not have the bandwidth to walk a mentee through the entire
process of, say, packaging a new software, or to mentor someone
responding to a RFH.

The WNPP list in itself is useful, but when looking at it again
recently, I distinctly recalled how foreign most of the packages were to
me when I first started contributing -- not a great motivator into
getting involved with something. And I recognized a number of RFHs that
have received numerous replies over the time, but couldn't be followed
up upon with because RFHs are frequently the result of a lack of time in
the first place (openldap anyone?).


With the recent gamification of just-about-everything, I was wondering
whether following such an achievement-oriented approach, with
opportunities for contribution formulated as a list of specific tasks,
instead of general avenues, would be helpful in overcoming this initial
difficulty. (This would be in addition to mentors.debian.net and other
established avenues for entry to Debian, not a replacement).


Tasks
=

I see a task having, at least, the following properties:

  * A specific objective (bug fix, enhancement, debugging, cleanup,
documentation, translation, ...). This should probably be tied to a
Debian bug number.

  * A description of the required skills (packaging, debugging, C, ...)

  * A difficulty rating (1:low to 5:very high)

  * An estimation for the amount of work to be done (hours, days)

  * An urgency (influenced by severity, popcon, ...)

  * A list of one or more mentors will to help.


Benefits for Mentees


For mentees, this would:

  * Provide a much simpler entry point into contributing to Debian.
Mentees would be able to start with smallish tasks fitting their
skill and interest profile. They could start contributing without
becoming overwhelmed with dozens of pages of dense documentation.

  * I expect that would to eventually lead to a better understanding
of Debian technically, and to closer personal contacts to the
community.

  * Later on, they could progress to the more difficult tasks, in
preparation towards eventual DM or DD status.


Benefits for Mentors


For mentors, I believe the benefits are even greater:

  * Mentors willing to help but lacking time for full mentorship could
still help with smaller tasks. Every little bit counts.

  * A new avenue for getting things fixed in Debian (QA). Instead of
having ancient O, RFA, and RFH bugs, some of which have been
proven to be insurmountable, the relevant packages can be improved
step-by-step.

  * In a similar vein, regular Maintainers could off-load some of
their work to mentees. I've seen enough bugs in packages where the
only blocker seems to be "lack of time".

  * Mentors could get another perspective on the history of a mentee's
work within Debian.


Costs
=

All in all, I think the additional cost to mentors wouldn't be that
great. It should be easy to write up the tasks: that does not require
time, only a lot of experience.


I'd appreciate feedback on the idea; and if this turns out to be
worthwhile I'll look into an implementation.

Christian


[1] https://www.debian.org/doc/debian-policy/
[2] https://www.debian.org/doc/manuals/maint-guide/
[3] https://www.debian.org/doc/manuals/developers-reference/
[4] http://mentors.debian.net/
[5] Package how-can-i-help


-- 
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/545fbe79.8020...@kvr.at

Re: Facilitating contributions by newcomers

[Christian Kastner]

On 2014-11-10 10:58, Ghislain Vaillant wrote:
> On 09/11/14 21:44, Don Armstrong wrote:
>> On Sun, 09 Nov 2014, Christian Kastner wrote:
>>> With the recent gamification of just-about-everything, I was wondering
>>> whether following such an achievement-oriented approach, with
>>> opportunities for contribution formulated as a list of specific tasks,
>>> instead of general avenues, would be helpful in overcoming this
>>> initial difficulty. (This would be in addition to mentors.debian.net
>>> and other established avenues for entry to Debian, not a replacement).
>> This is an avenue that I'm interested in exploring for the BTS as well,
>> so if people have good ideas, or want to be involved with this, please
>> contact me in #debbugs on irc.debian.org, or email
>> ow...@bugs.debian.org.
>>
> 
> Are you guys thinking of something like the Fedora "badges" or Ubuntu
> "accomplishments" ?

I wasn't aware of these, and they certainly look very interesting.

I didn't have this in mind when I wrote my original submission; I was
only thinking in terms of tasks as steps to complete when working
towards eventual DM or DD status.

But I can see that rewarding individual tasks with badges and the like
can have their appeal, especially for newcomers not yet having
aspirations of becoming DM/DD, instead only wishing to contribute a
little something back to Debian, even if it's just a one-off thing. I
think rewarding contributions in this fashion is a great way to inspire
an "I'm part of this" feeling in contributors.


-- 
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/98f7c00f05c2dbf0e262e3fb55a44...@kvr.at

Re: Facilitating contributions by newcomers

[Christian Kastner]

On 2014-11-10 22:12, Roger Light wrote:
> I think this is a worthwhile idea, but would like to suggest that if
> you're going to go down the approach of badges/accomplishments then it
> would be good to consider how to encourage existing DDs to become
> active in mentoring.

That's one of the key points here: by working with a list of small
tasks, the time commitment needed is much smaller, so this approach
should enable more DDs to help.

> My experience is that making the package is the easy bit, the tricky
> bit is getting someone to take notice, provide feedback and eventually
> upload the package.

In my experience, properly reviewing a package can take a significant
amount of time. Hours, if the packager is inexperienced. And that's only
the review part. Mentoring the packager to a point where the package is
in an acceptable state takes even more time.

I do believe, however, that mentors prefer to (continue to) work with
people they know, so beginning with small tasks could be a good
opportunity to connect with people.


-- 
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/7846a5e19266a680fdb618088d0ee...@kvr.at

Re: Facilitating contributions by newcomers

[Christian Kastner]

On 2014-11-11 03:06, Paul Wise wrote:
> On Tue, Nov 11, 2014 at 9:50 AM, Jordan Metzmeier wrote:
> 
>> How do you see the transition from a mentee to a DM going?
> 
> Something like this:
> 
> Do a bunch of tasks through the proposed program.
> 
> Feel more confident in your knowledge of Debian.

I would add here: meet people in Debian.

I'd expect that once you've done a few tasks with a couple of DDs, the
chances of finding a sponsor later should be much higher.

> Find some software in Debian that you use that isn't well maintained
> or some software you use that isn't in Debian yet.
> 
> Decide you want to work on that software.
> 
> Start working on the package.
> 
> Find a sponsor for the package.
> 
> Do a few uploads through the sponsor.
> 
> Have the sponsor tell you to apply for NM because you are great.
> 
> Apply for NM.

Total agreement here.

The second part (after my remark above) represents the steps of regular
process; these steps can be significant hurdles to a newcomer -- and to
mentors.

By adding the steps above my remark, I'd hope that both contributing and
mentoring should become easier.


-- 
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/aea960cdab1d214a546185a03...@kvr.at

Re: Facilitating contributions by newcomers

[Christian Kastner]

On 2014-11-11 03:59, Jordan Metzmeier wrote:
> It is possible to find packages that are not well maintained, but do
> we have an interface for locating them? Even when they are located,
> contributing to them isn't always easy, especially if the maintainer
> is busy or MIA (assuming the package isn't team maint). I guess we do
> have RFAs and orphaned packages, but not a lot of interesting software
> ends up there.

This is one of the problems I had in mind when I wrote:

On 2014-11-09 20:20, Christian Kastner wrote:
> All in all, I think the additional cost to mentors wouldn't be that
> great. It should be easy to write up the tasks: that does not require
> time, only a lot of experience.

For a newcomer, locating worthwhile tasks indeed is difficult. For an
experienced member (within his or her area), it usually isn't.
Experienced members normally have a good idea of what needs to be worked
on, what kind of work it is (-> what skills are required to fix it), how
much work it is, and so on.

Furthermore, a busy maintainer might not have the time to walk a mentee
through an entire upload, but the chances of finding the time to
"scratch some itches" the maintainer has should be higher. These
"itches" could be expressed well in the form of tasks.

And I also fully agree that RFAs and Os are mostly uninteresting, but
doing general QA work is a very important way of contributing to Debian,
and I'm almost certain that many DDs would help more in this regard if
it didn't entail doing a whole RFA but fixing thing step-by-step
instead.



-- 
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/2e9184d8b1b41be6f687ebe9c6a71...@kvr.at

Re: Facilitating contributions by newcomers

[Christian Kastner]

On 2014-11-09 22:44, Don Armstrong wrote:
> On Sun, 09 Nov 2014, Christian Kastner wrote:
>> With the recent gamification of just-about-everything, I was wondering
>> whether following such an achievement-oriented approach, with
>> opportunities for contribution formulated as a list of specific tasks,
>> instead of general avenues, would be helpful in overcoming this
>> initial difficulty. (This would be in addition to mentors.debian.net
>> and other established avenues for entry to Debian, not a replacement).
> 
> This is an avenue that I'm interested in exploring for the BTS as well,
> so if people have good ideas, or want to be involved with this, please
> contact me in #debbugs on irc.debian.org, or email
> ow...@bugs.debian.org.

I think that using the BTS for this would be the ideal scenario.

A number of other (or additional) solutions have also been proposed
which sound interestung but TBH, I'm not a fan adding
yet-another-service that might eventually start to rot. There really
should be a significant value added.

I'll create a wiki page to collect the problem definition and the
possible solutions discussed so far, and some possible workflows.


-- 
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/712dc87740f84c14c24684ecb3694...@kvr.at

Re: Facilitating contributions by newcomers

[Christian Kastner]

On 2014-11-11 14:43, Stéphane Aulery wrote:
> Le mardi 11 novembre 2014 à 02:30:56, Simon Chopin a écrit :
>> Quoting Stéphane Aulery (2014-11-11 13:51:50)
>>>
>>> A tag "easyhack" (or whatever) for BTS would be welcome, like the 
>>> LibreOffice
>>> project Easy_Hacks made:
>>
>> This already exists, see the tag "gift"[1].
>>
>> [1] https://wiki.debian.org/qa.debian.org/GiftTag
> 
> Never heard of this initiative before. This tag is not documented in the
> help pages of the BTS, it must be remedied. Thank you for this
> information!

I wasn't aware of this either, but it seems to be precisely what this
thread has been discussing. Neat!


-- 
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/54629f03@kvr.at

Re: Facilitating contributions by newcomers

[Christian Kastner]

On 2014-11-11 20:28, Lucas Nussbaum wrote:
> On 09/11/14 at 20:20 +0100, Christian Kastner wrote:
> Do you have how-can-i-help installed?
> The WNPP list might not be the best approach to finding interesting
> packages to adopt. But looking at the intersection with packages you
> have installed locally (using how-can-i-help --old) makes it a lot more
> interesting.

I did look into it, but I have to admit only superficially -- as evident
by the fact that I completely missed the gift tag, which seems match
exactly with what I had in mind with "task".

So AFAIUI, the core stuff is already there, and we'd just have to look
at opportunities to improve it.


-- 
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/5462a0f9.8050...@kvr.at

Re: Facilitating contributions by newcomers

[Christian Kastner]

On 2014-11-11 23:23, Lucas Nussbaum wrote:
> On 11/11/14 at 14:13 -0800, Don Armstrong wrote:
>> On Tue, 11 Nov 2014, Lucas Nussbaum wrote:
>>
>>> [0] https://wiki.debian.org/qa.debian.org/GiftTag
>>
>> Does anyone have any thoughts about elevating the gift tag to a
>> fully-fledged BTS tag?
> 
> I am totally in favor of turning it into a real tag.
>
> There has been discussions about renaming the tag [...] entry-point

I, too, like this idea very much.

Going even further, what would you see as possible solutions for
augmenting bug reports tagged 'entry-point' with the information I
mention in first post, ie:

On 2014-11-09 20:20, Christian Kastner wrote:
>   * A specific objective (bug fix, enhancement, debugging, cleanup,
> documentation, translation, ...). This should probably be tied to a
> Debian bug number.
>
>   * A description of the required skills (packaging, debugging, C, ...)
> 
>   * A difficulty rating (1:low to 5:very high)
> 
>   * An estimation for the amount of work to be done (hours, days)
> 
>   * An urgency (influenced by severity, popcon, ...)
> 
>   * A list of one or more mentors will to help.

Personally, I think that the "required skills" and the "difficulty
rating" would be very valuable additions.

It may be possible to infer the other attributes from the other metadata
eg: urgency ~ severity.


-- 
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/5462a49f.9030...@kvr.at

Re: Facilitating contributions by newcomers

[Christian Kastner]

On 2014-11-12 02:14, Don Armstrong wrote:
> On Wed, 12 Nov 2014, Christian Kastner wrote:
>> Going even further, what would you see as possible solutions for
>> augmenting bug reports tagged 'entry-point' with the information I
>> mention in first post, ie:
>>
>> On 2014-11-09 20:20, Christian Kastner wrote:
>> >   * A specific objective (bug fix, enhancement, debugging, cleanup,
>> > documentation, translation, ...). This should probably be tied to a
>> > Debian bug number.
>> >
>> >   * A description of the required skills (packaging, debugging, C, ...)
>> >
>> >   * A difficulty rating (1:low to 5:very high)
>> >
>> >   * An estimation for the amount of work to be done (hours, days)
>> >
>> >   * An urgency (influenced by severity, popcon, ...)
>> >
>> >   * A list of one or more mentors will to help.
>>
>> Personally, I think that the "required skills" and the "difficulty
>> rating" would be very valuable additions.
>>
>> It may be possible to infer the other attributes from the other metadata
>> eg: urgency ~ severity.
> 
> I'd suggest using the BTS's summary command, which enables you to
> nominate a message whose first paragraph will summarize the bug.
> 
> This is free form, but that's probably good enough (at least for
> starters).

I'd argue it's good enough for the task itself, but searching for areas
to contribute to could still be improved significantly. For example,
given the following list of motivations a new contributor might have

   "I want to help fix simple bugs in C programs."
   "I want to help fix difficult bugs in Java programs."
   "I want to help with translations."
   "I want to help multiarchify packages."
   
a search by the "entry-point" tag alone would indeed reduce the list of
issues to hundreds (thousands?) of entries, but that's still a lot. On
the other hand, if these were possible, I think the value should be
evident (FTR, all flags to how-can-i-help made up):

$ how-can-I-help --difficulty low --skills C
$ how-can-I-help --difficulty hard --skills Java
$ how-can-I-help --type translation
$ how-can-I-help --difficulty low --skills packaging

And, of course, a web interface for entry-point also wouldn't hurt, I
guess.


-- 
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/0b0a7bc39a3fd47693eb1c524f69b...@kvr.at

Re: Making "entry-point" nee "gift" a real BTS tag [Re: Facilitating contributions by newcomers]

[Christian Kastner]

On 2014-11-13 09:42, Stefano Zacchiroli wrote:
> On Wed, Nov 12, 2014 at 07:42:33PM +0100, Stéphane Aulery wrote:
>> entry-point
>> The maintainer can easily solve this bug by himself, but he
>> wants to take it to new contributors who wish to get involved
>> in Debian. Bugs of any difficulty can be offered in order to
>> attract and increase skill.
> 
> I don't think we should include the initial part about "maintainer can
> easily solve...", as it does seems a bit patronizing ("that's easy for
> me, but I won't do it because..."). My take: just include the part about
> being a good entry point (hence the name) for new contributors and scrap
> the rest.

Perhaps the choice of words could be improved, but I always understood
the "easy" part as "this issue has a more or less clear solution" (and
it's just a question of who will put resources into it), as opposed to
an RFH bug, for which a solution is beyond the capabilities of the
maintainer. Mentees might find this distinction helpful -- tasks can be
less intimidating when a correct solution is known.

What do you think of the following?

entry-point
-The maintainer can easily solve this bug by himself, but he
-wants to take it to new contributors who wish to get involved
-in Debian. Bugs of any difficulty can be offered in order to
-attract and increase skill.
+This bug has a known solution but the maintainer requests
+someone else implement it. This is an ideal task for new
+contributors who wish to get involved in Debian, or who
+wish to improve their skills.

The maintainer is committed to providing assistance to new
contributors. This gateway is a complement more accessible to
mentors.debian.net.


-- 
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/1624917a9dcf44b56d5641b80c2bc...@kvr.at

Re: Making "entry-point" nee "gift" a real BTS tag [Re: Facilitating contributions by newcomers]

[Christian Kastner]

On 2014-11-13 12:43, Stéphane Aulery wrote:

> I'm sorry my English is poor and I can hardly do better. I wanted to
> summarize the main ideas of the second paragraph on page [1] which I
> find very good. The maintainer should know the first glance by reading
> the description if it can offer the bug without having to read another
> page. Another formulation:
> 
> entry-point
>  This bug has a known solution but the maintainer thinks it is
>  an ideal task for new contributors who wish to get involved in
>  Debian, or who wish to improve their skills. This gateway is a
>  complement more accessible to mentors.debian.net.
>
>  The maintainer is committed to providing assistance to new
>  contributors and been able to upload an updated package in a
>  timely manner. Bugs of any difficulty can be offered.

I like this version the much!

> [1] https://wiki.debian.org/qa.debian.org/GiftTag


-- 
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/c0ecb2a52d989b5b5c453de36e3fa...@kvr.at

Bug#770636: RFS: gitinspector/0.3.2+dfsg-1 [ITP]

[Christian Kastner]

Package: sponsorship-requests
Severity: wishlist
Control: block 768508 by -1

Hi,

I am looking for a sponsor for my package "gitinspector".

 * Package name: gitinspector
   Version : 0.3.2+dfsg-1
   Upstream Author : Ejwa Software 
 * URL : http://code.google.com/p/gitinspector/
 * License : GPL-3+
   Section : vcs

It builds the following binary packages:

  gitinspector - statistical analysis tool for git repositories

To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/gitinspector

Alternatively, one can download the package with dget using this command:

  dget -x
http://mentors.debian.net/debian/pool/main/g/gitinspector/gitinspector_0.3.2+dfsg-1.dsc

Changes since the last upload:

  * Initial release. Closes: #768508


I'm already a DM, if that helps.

Regards,
 Christian Kastner


-- 
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/5470f881.2060...@kvr.at

Bug#770638: RFS: python-cachetools/0.7.0-1 [ITP]

[Christian Kastner]

Package: sponsorship-requests
Severity: wishlist
Control: block 767298 by -1

Hi,

I am looking for a sponsor for my package "python-cachetools".

 * Package name: python-cachetools
   Version : 0.7.0-1
   Upstream Author : Thomas Kremmer
 * URL : https://github.com/tkem/cachetools
 * License : Expat
   Section : python

It builds the following binary packages:

  python-cachetools - extensible memoizing collections and decorators
for Python
 python3-cachetools - extensible memoizing collections and decorators
for Python 3

To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/python-cachetools

Alternatively, one can download the package with dget using this command:

  dget -x
http://mentors.debian.net/debian/pool/main/p/python-cachetools/python-cachetools_0.7.0-1.dsc

Changes since the last upload:

  * Initial release. Closes: #767298


I'm already a DM, if that helps.

Regards,
 Christian Kastner


-- 
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/5470fb31.4030...@kvr.at

Bug#770636: RFS: gitinspector/0.3.2+dfsg-1 [ITP]

[Christian Kastner]

On 2014-12-02 18:42, Andrey Rahmatullin wrote:
> On Sat, Nov 22, 2014 at 09:56:33PM +0100, Christian Kastner wrote:
>>   dget -x
>> http://mentors.debian.net/debian/pool/main/g/gitinspector/gitinspector_0.3.2+dfsg-1.dsc
>>
>> Changes since the last upload:
>>
>>   * Initial release. Closes: #768508
> Uploaded, thanks! I didn't tag this in SVN because
> Add-missing-HTML-footer-to-htmlembedded-output.patch is newer in the
> mentors package, please commit it and tag.

Ow. Apparently I added an Applied-Upstream header to the patch, but
forgot to commit that.

Corrected, then tagged.

Thank you very much for sponsoring gitinspector and python-cachetools!

Christian


-- 
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/547e5f5a.8050...@kvr.at

Bug#770638: RFS: python-cachetools/0.7.0-1 [ITP]

[Christian Kastner]

Hi,

On 2014-12-05 22:07, Thomas Kemmer wrote:
> As the upstream author of this I feel flattered, but just for the records:
> It's Thomas KEMMER, not
> 
> Upstream Author : Thomas Kremmer

sorry about that! I will correct it in the next upload for 0.8.0.

Regards,
Christian


-- 
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/5482269b@kvr.at

Re: Bug#771774: RFS: libmongo-client/0.1.8-2 [ITA]

[Christian Kastner]

On 2014-12-05 08:43, Gergely Nagy wrote:
>> "Jörg" == Jörg Frings-Fürst  writes:
> >> * Why move --dbg-package from DH_OPTIONS to an override?
> 
> Jörg> --dbg-package is only needed in dh_strip[1]. 
> 
> Yes. But it works fine in DH_OPTIONS too, without any ill side-effects,
> and is shorter there. (Personal thing, but I hate overrides, and if
> there's another way to do what I want, which isn't convoluted, I'd
> choose that)
> 
> But override or DH_OPTIONS, in this case, doesn't matter.

The reason I prefer the override, even though it is longer, it that it
clearly limits the scope of the option I'm setting. This is helpful to
contributors to the package, or new maintainers. `man dh_strip` gives
them all the info they need.

The effects of DH_OPTIONS=--dbg-package might be obvious to an
experienced packager but a newcomer might not know that it only affects
dh_strip, hence instead of `man dh_strip`, an internet search or IRC
inquiry is required.


-- 
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/54831b29.3070...@kvr.at

Bug#770638: RFS: python-cachetools/0.7.0-1 [ITP]

[Christian Kastner]

On 2014-12-19 19:00, Thomas Kemmer wrote:
> FYI: Version 1.0.0 has just been release on PyPi and GitHub

A package based on 1.0.0 has just been uploaded. Thanks!


-- 
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/5494a211.7090...@kvr.at

Re: simple shell question

[Christian Kastner]

On 2015-02-18 21:40, Paul Gevers wrote:
> I am wondering about the following, what is the practical difference in
> a shell script between
> [ "$foo" ] and [ -n "$foo" ]

POSIX [1] mandates it:
  | -n  string
  | True if the length of string is non-zero; otherwise, false.

  | string
  | True if the string string is not the null string; otherwise,
  | false.

The bash builtin test / [ ] complies with that:
  | string
  | -n string
  |True if the length of string is non-zero.

As does [ ] from test(1):
  | -n STRING
  |the length of STRING is nonzero
  |
  | STRING equivalent to -n STRING

> or
> [ ! "$foo" ] and [ -z "$foo" ]

These follow from above.

Regards,
Christian

[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html


-- 
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/54e63ec5.3060...@kvr.at

Re: Using root privileges to build a package

[Christian Kastner]

On 14.01.20 12:14, Leopold Palomo-Avellaneda wrote:
> El 14/1/20 a les 10:54, Andrey Rahmatullin ha escrit:
>> Sorry, are you saying you think it's fine for a package build process to
>> modify the build host system?
> 
> just to install some files and yes, I understand that it shouldn't.

It's not that it shouldn't, it's that it *can't*. Otherwise any upload
could be used to compromise the buildd host.

> debhelper/upstream-make-install: The dh_auto_install command will run the
> "install" target from the upstream's Makefile under (fake)root (for the
> "makefile" build system or one derived from it).
> 
> 
> that's what I want: run dh_auto_install target from the upstream's Makefile
> under root.

It doesn't, though. The point of fakeroot is (surprise) to fake actual
root operations. It doesn't really do anything.

The installation you are alluding to is not an installation on the
buildd, but part of the package being created.

Most packages don't need this faking, hence they set
Rules-Requires-Root: no. But when, for example, your build depends on
the installation chown'ing some files, then you'd probably need
Rules-Requires-Root: yes so that fakeroot can fake the chown operation
succeeding when creating the package.

If this library that the two libraries depend on is a public one, then
it should probably be packaged separately. Dependency management is a
key point of our archive.

If this library is private, and you just need it for building or for
tests, then use LD_LIBRARY_PATH (or PYTHONPATH, or whatever suits your
library) to point the build process to the currently created one.

Re: sbuild VM or Server

[Christian Kastner]

On 2020-04-13 12:36, Jörg Frings-Fürst wrote:
> I want to set up a VM or a dedicated server for it. Is there a prepared
> VM and/or a description?

autopkgtest-build-qemu will create a VM with vmdb2, and will customize
it so that you can use it for most development needs.

For example, sbuild has a --chroot-mode=autopkgtest. You can use it with
the created VM to build packages.

It's working so well for me that I've basically got rid of my unstable
host, I can do development for all releases (each with a VM) on my
buster host now. It's great!

The only improvement I would wish for, were a simpler way to create VMs
for architectures other than amd64 and i386.

Bug#968450: RFS: anacron/2.3-30 [QA] -- cron-like program that doesn't go by time

[Christian Kastner]

Hi Jpaulo,

I can sponsor this.

You seem to have based directly off of 2.3-29. However, git contains a
handful of newer commits.

Could you fork the repo on salsa.debian.org and add your changes on top
of the current HEAD, so that (1) those changes are included and (2) your
work can also be merged back into the repo?

On 2020-08-15 16:46, Jpaulo wrote:
>  anacron (2.3-30) unstable; urgency=medium
>  .
>    * QA upload.
>    * debian/anacron.preinst: Update for the new revision.

I don't think this is correct. That script said that if we're upgrading
from -24 or older, then a particular transition code snippet is to be
run. Updating this to -30 means that the code snippet will be run again.

>    * debian/control:
>        - Bumped debhelper-compat from level 12 to leve 13.
>        - Bumped Standards-Version to 4.5.0.
>    * debian/changelog: Correction of spelling error.
>    * debian/upstream/metadata: created.
>    * debian/rules:
>        - Removed flag not required.
>        - Removed trash
You also converted d/copyright to MRCF 1.0 (great!), please also add a
changelog entry for that.

Thanks!
Christian

Repack source lacking root directory?

[Christian Kastner]

Hi,

I have an upstream source that ships files as a ZIP file, with no root
directory in that file. So contents are something like

  file1.txt
  file2.c
  subdir/file3.h
  file4.tx

uscan will automatically repack the ZIP, but I couldn't figure out the
magic incantation necessary in debian/watch to move these to a root
folder 'srcname'.

Can anyone help? Is this even possible with a plain debian/watch, or
will it need a custom repacker?

Best,
Christian

Re: Repack source lacking root directory?

[Christian Kastner]

On 2023-08-16 13:28, Mattia Rizzolo wrote:
> On Wed, Aug 16, 2023 at 08:23:14AM +0200, Christian Kastner wrote:
>> uscan will automatically repack the ZIP, but I couldn't figure out the
>> magic incantation necessary in debian/watch to move these to a root
>> folder 'srcname'.
> 
> Why would you need to do so?
> 
> dpkg-source handles tarballs with no top-level directory just fine,
> AFAIK.

Huh, bad assumption on my part. Indeed, it works fine.

Thanks!
Christian

Re: ROCm installation

[Christian Kastner]

On 2022-01-12 22:15, M. Zhou wrote:
> If shlibs are installed to somewhere like /usr/lib/rocm/lib/,
> we are still able to tamper with ld.so.conf.
> If binary executables are installed to /usr/lib/rocm/bin/,
> then we are screwing up with the default shell PATH.
> This is a deadend because we are not going to patch all
> POSIX and non-POSIX shell configs. Neither do we introduce weird
> scripts for the user to source.

Not that I'd advocate it, but for some initial version, installation to
/usr/lib/rocm/bin could be worked around by symlinks if changing this
can't be changed easily/quickly.

For example, from Firefox:

 $ readlink -e /usr/bin/firefox-esr
 /usr/lib/firefox-esr/firefox-esr

Best,
Christian

Re: Separate GPG subkey for package signing

[Christian Kastner]

On 2022-06-24 18:40, Dániel Fancsali wrote:
> I thought, I'll create a separate subkey for signing the package (and
> keep my master key off-line, and the others keys separate from this
> debian-signing-subkey). Would that be considered good practice? Or is
> there something I can't see here?

This is done quite commonly, actually. [1] and [2] have more info.

Best,
Christian

[1] https://wiki.debian.org/GnuPG/AirgappedMasterKey

[2] https://wiki.debian.org/Subkeys

Re: Bug#683120: RFS: yadifa/1.0.3-1 [ITP]

[Christian Kastner]

On 2015-08-15 16:17, Jakub Wilk wrote:
> * Christian Kastner , 2014-04-09, 20:50:
>> The Vcs-Git URL should use the git:// protocol specifier, and you
>> could add a Vcs-Browser URL pointing to the github package, like so:
>>
>>  -Vcs-Git: https://github.com/asciiprod/yadifa.git
>>  +Vcs-Git: git://github.com/asciiprod/yadifa.git
> 
> The original URL is clone'able by git, too.
> So what's wrong with using HTTPS in Vcs-Git?

lintian complained about vcs-field-not-canonical, IIRC (although
admittedly, it's just an informational tag).

Bug#683120: RFS: yadifa/2.0.5-1 [ITP]

[Christian Kastner]

Hi Markus,

On 2015-06-05 13:52, Markus Schade wrote:
> New package for yadifa 2.1.0 is available
> 
> http://mentors.debian.net/debian/pool/main/y/yadifa/yadifa_2.1.0-1.dsc
>
>  It would be great if someone could sponsor this package. I think
> the history of this bugreport proves that the package is well
> maintained. And it is much better than upstream referencing my github
> repo as the canonical way to get yadifa to run on Debian/Ubuntu.

I just checked your package and I think that it is almost ready for
upload. Here are just a few minor points:

debian/copyright:
- lintian complains about non-unique license specifications.
Applying the pattern from Example #2 of [1] should resolve this
issue.

debian/control:
- You can drop the version restriction for dpkg-dev. The version in
oldstable (wheezy) is already higher.

debian/changelog:
- Please remove all entries except the newest one which documents the
initial release.

debian/yadifa.default
debian/yadifa.service:
- AFAIUI, when using systemd, the contents of /etc/default/yadifa
will be ignored. This might be a problem for users switching
from sysvinit to systemd later on. If they changed the default,
eg by changing the location of the configuration file, this
change will no longer be honored after the systemd switch.

One way you can address this problem is by using EnvironmentFile in
the service file. The cron package does it that way, for example.

debian/rules:
- I believe the "export DH_OPTIONS [...] to make magic work" can be
dropped. I think this is a remnant from a time long past; I can't
find any reference to this in recent documentation. dh(1), for
example, makes no mention of this. Second opinions welcome...

[1] 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#stand-alone-license-paragraph

Regards,
Christian




signature.asc
Description: OpenPGP digital signature

Re: Bug#683120: RFS: yadifa/1.0.3-1 [ITP]

[Christian Kastner]

On 2015-08-16 13:43, Jakub Wilk wrote:
> * Christian Kastner , 2015-08-15, 23:57:
>>>> The Vcs-Git URL should use the git:// protocol specifier, and you
>>>> could add a Vcs-Browser URL pointing to the github package, like so:
>>>>
>>>>  -Vcs-Git: https://github.com/asciiprod/yadifa.git
>>>>  +Vcs-Git: git://github.com/asciiprod/yadifa.git
>>>
>>> The original URL is clone'able by git, too.
>>> So what's wrong with using HTTPS in Vcs-Git?
>>
>> lintian complained about vcs-field-not-canonical, IIRC
> 
> I don't think it did. vcs-field-not-canonical, as currently implemented,
> is only about Alioth URLs.

I could have sworn that my initial comment was triggered by a lintian
warning, but trying to produce anything else with an older version of
lintian yielded nothing either.

Therefore, I'm definitely misremembering something, and looking at the
policy, I see no such restriction, so my initial comment was wrong.

Re: Questions before my first upload attempt

[Christian Kastner]

On 2015-08-20 18:33, Thomas Schmitt wrote:
> Currently i am stuck at:
> 
> - https://wiki.debian.org/DebianMentorsFaq#How_do_I_make_my_first_package.3F
>   "Put a package together, built against a current version of sid."
> 
>   I'm on Jessie 8.1. The dependencies of the packages in question
>   are very basic. The package sources are portable to any X/Open
>   compliant system. Tested upstream on very old GNU/Linux, FreeBSD,
>   Solaris, and NetBSD.
>   I understand i have to submit source packages anyway.
> 
>   So is there a way to do my packaging work in Debian 8.1 ?

Generally speaking, the advice to "build against a current version of
sid" is an important one, because that's where the package eventually
gets uploaded to, and your package must work with what's in there, and
not with what's in 8.1.

But yes, there are ways you can do development against sid whilst
remaining mainly in an 8.1 environment. Commonly used solutions are
chroots and VMs, which provide a sid environment more or less isolated
from the host environment.

>   (The PackagingTutorial says i shall write "9" into
>debian/compat. Is that enough of a sid ?)

As Johan already indicated, the "9" is unrelated to the Debian version.
It refers to the feature set of debhelper, a helper program very
frequently used by packages.

The section "COMPATIBILITY LEVELS" of debhelper(7) has more details, but
you probably shouldn't care about these yet. Completing a few tutorials
and becoming familiar with the "big picture" first are probably more
important, so you are non the right track :-)

>   Else: Is there a shortcut description how to quickly set up
>   Debian package development in a virtual machine and how
>   to keep it up to date ?
>   (Hardware is plenty but my own VM scripts date back to Debian 6.)

The simplest way I can think of is to create a qemu-based VM with
vmdebootstrap(8). The following should create a useful result, which you
can then further modify:

$ sudo vmdebootstrap \
--distribution sid \
--image mysid.img \
--size=5g \
--mirror http://httpredir.debian.org/debian \
--configure-apt \
--package build-essential \
--package devscripts \
--enable-dhcp \
--hostname mysidvm \
--serial-console \
--owner ${USER}

$ qemu-system-x86_64 -enable-kvm -m 2048 mysid.img

Adapt the QEMU options to your hardware environment and to the features
you need, and inside the VM, adapt to your liking.

> - I still did not find a hands-on description of fulfilling
>   the demand of http://mentors.debian.net/intro-maintainers:
> "All packages must be signed with the GnuPG key you configured
>  in your control panel."
> 
>   http://mentors.debian.net/my has my public key now. I guess
>   this does the necessary configuration.
>   But how to use gpg or other programs to sign the packages ?
[...]
>   Suspiciously all newbie tutorials for Debian packaging
>   propose to use options -us -uc, which i understand prevent
>   some kind of signing.

You only want to sign the final result of your packaging efforts;
signing every intermediate result of the development process is
unnecessary and annoying, hence the -us -uc.

As Johan already mentioned, simply omit these, and you will be asked for
a signature.

Alternatively, if you used -us -uc, and you'd like to sign the result
later on, you can use the debsign(1) utility from the devscripts package.

Regards,
Christian

Re: Questions before my first upload attempt

[Christian Kastner]

On 2015-08-20 18:33, Thomas Schmitt wrote:
> i am the upstream developer of freshly orphaned packages libburn4,
> libisofs6, libisoburn1, cdrskin, and xorriso. Now preparing to get
> them in shape for sponsorship and for closing old bug reports.

By the way, in that case, you should retitle the respective bug reports
from O for "orphaned" to ITA for "intent to adopt".

This clearly communicates that you are working on them, and thereby
reduces the chance of redundant work and/or conflicts with other
maintainers.

See 
https://wiki.debian.org/DebianMentorsFaq#How_do_I_adopt_an_existing_package.3F

Re: Questions before my first upload attempt

[Christian Kastner]

On 2015-08-21 13:21, Danny Edel wrote:
> On 20/08/15 18:33, Thomas Schmitt wrote:
>>   Else: Is there a shortcut description how to quickly set up
>>   Debian package development in a virtual machine and how
>>   to keep it up to date ?
>>   (Hardware is plenty but my own VM scripts date back to Debian 6.)
> 
> Hi Thomas,
> 
> Debian actually has ready-made VM scripts for you.
> 
> You want to take a look at the "sbuild" system, it can create a minimal
> sid tarball chroot-"virtualmachine" and use it to build packages for
> you. Using sbuild will be as close as it gets to the official buildd
> machines, helping you to prevent FTBFS¹. sbuild machines install a bare
> minimum of packages plus your specified build-dependencies into a
> throwaway directory, build the package and delete everything except the
> build log and created .deb, returning to a clean state.
> 
> Pointer: https://wiki.debian.org/sbuild
> 
> Once sbuild is setup, you can call either "sbuild --dist sid" from
> inside the source directory (quick result, but I wouldn't recommend it)
> or call "debuild -S" on your host machine first:
> This will create a .debian.tar.xz and a (signed) .dsc file in "..", then
> you can call "sbuild --dist sid your-package_version.dsc". If that goes
> through, you know your dsc is good and you can upload it to mentors with
> "dupload --to mentors my.changes". (That's why I recommend this two-step
> route, since than you have "this" dsc that built correctly. Btw, the
> dupload step will check if you signed correctly)
> 
> For bonus points, if you are on a machine that can chroot different
> arches (for example amd64 hosts can create a i386 chroot) you can verify
> it compiles on both.
> Just call another sbuild-createchroot with --arch i386 and then call
> "sbuild --dist sid --arch i386 my.dsc" to build on it.

I agree that sbuild is ultimately the best way to go. I myself use it,
and keep chroots of various distributions on it.

The reason I posted the qemu-based approach was that it was, at first
sight, not as complex as the sbuild approach, seeing as it only required
one command.

Re: Questions before my first upload attempt

[Christian Kastner]

On 2015-08-21 13:15, Thomas Schmitt wrote:
> I already began installing yesterday evening.
> It is instructive, but i would have preferred to postpone
> the qemu adventures until i explore passthrough of DVD drives.

Yes, that makes sense.

> How about publicly available accounts on a sid machine,
> where programmers like me can test building of their packages ?

Well, we have them. They are called "porter boxes", and they exist for
many architectures. However, it is sometimes not easy to get access to
these as a non-DD.

Regardless: if you want to do Debian development, having a sid
environment really is unavoidable, even if it might be a hassle.

>   Now i have:
> # uname -a
> Linux ts6-sid 4.1.0-1-amd64 #1 SMP Debian 4.1.3-1 (2015-08-03) x86_64 
> GNU/Linux
>   Cannot really tell whether this is sid. I did my best, at least.
>   /etc/apt/sources.list currently has these two active lines
> 
> deb http://ftp.de.debian.org/debian/ unstable main
> deb-src http://ftp.de.debian.org/debian/ unstable main
> 
>   Anything more to add there ?

No, looks good!

>> By the way, in that case, you should retitle the respective bug reports
>> from O for "orphaned" to ITA for "intent to adopt".
> 
> How to do this ?
> (I see few risk that anybody would take care of the packages
>  in the next days.)

The Debian BTS is manipulated via email. You can see an example for
changing from O to ITA here [1]. I then suggest you read [2] to
understand what exactly is happening, and finally [3] as a general
overview of the BTS.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553654#15
[2] https://www.debian.org/Bugs/server-control
[3] https://www.debian.org/Bugs/Developer

> Do i get it right that i should do
>   apt-get dist-upgrade
> every time before i begin to package something ?

Your build environment should be recent. This doesn't mean that you have
 to update before every build, but I'd update it at least daily.

Ideally, your final build should be against an up-to-date sid environment.

Regards,
Christian

Re: Questions before my first upload attempt

[Christian Kastner]

On 2015-08-23 16:08, Thomas Schmitt wrote:
> Remaining questions:
> 
> - Shall i dput -f now ?

Yes.

I don't know if you have to remove the package first (eg via the web
interface). Can someone more familiar with mentors.debian.net add some
enlightenment here?

> - What to do about the complaint:
> "The uploader is not in the package's "Maintainer" or "Uploaders" fields"
>   Add myself to "Uploaders" ? Am i entitled ?

Orphaning a package means that there is no maintainer anymore;
therefore, you would normally set yourself as Maintainer.

However: it appears that this package is team-maintained. In that case,
you leave the Maintainer as-is, and add yourself to Uploaders.

There's an alioth [1] project, with mailing list and all:

https://alioth.debian.org/projects/pkg-libburnia/

As you can see, there are a number of committers there, and the current
Uploaders field of the package lists one of them.

IMHO, taking over this package correctly would mean to also take over
the alioth project as admin by
1. Requesting to join the team
2. Having the current admin set your new account as admin
3. Removing the old admin

Once you have completed the above, add yourself to Uploaders. Then, add
an entry to debian/changelog, such as:

  * Add myself to Uploaders. Closes: #XX

The XX refers to the bug number with which the package was orphaned,
and which you still need to retitle and of which you still need to claim
ownership :-)

Alternatively, if you no longer wish to team-maintain it, and if the
remaining uploader is OK with this, you could set yourself to
Maintainer, remove the Uploaders, and add the following entry to
debian/changelog:

  * New Maintainer. Closes: #XX

However, you should then get the alioth project removed, to avoid confusion.

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

Re: +dfsg extension with Files-Excluded: in d/copyright

[Christian Kastner]

Hi Jakub,

On 2015-09-01 12:22, Jakub Wilk wrote:
> * Ole Streicher , 2015-09-01, 11:51:
>> when using the Files-Excluded: tag in debian/copyright, in the past
>> there was an "+dfsg" suffix added to the version number automatically.
>> This seems to have changed; is there a reason for that? Is there any
>> case to use Files-Excluded: *without* actually adding the suffix?
> 
> See #748465. Some people abuse debian/copyright for excluding files for
> reasons unrelated to DFSG...
> 
> My recommendation is to never use Files-Excluded. It's a broken design.

could you elaborate, or point to a discussion, on why this design can be
considered broken?

Regards,
Christian

Bug#787328: RFS: mpd-sima/0.13.1-1

[Christian Kastner]

Hi Geoff,

Gianfranco already beat me to the review; nevertheless, here are some
additional notes I had prepared, based on the package I saw on Sunday
(the package is no longer visible on mentors.d.n).

On 2015-09-14 12:32, Gianfranco Costamagna wrote:
> lets review:
> 
> 1) you dropped 0.10.0-2 entry from changelog
> 2) entry 0.10.0-1 is targeted wrongly
> 3) bump compat level not mentioned in changelog
> 4) according to setup.py
> install_requires=['python-musicpd>=0.4.1', 'requests>= 2.0.2'],
> 
> so I guess there is no need to specify them to runtime dependencies
> (please check)
> 
> 5) please mention copyright updates
> 6) mpd-sima.default
> "+## NOTA BENE:"
> this seems to be italian, please use english
> 
> 7)
> +## only works with SysV init
> +## With systemd init: "touch /etc/mpd-sima_not_to_be_run" to prevent 
> mpd-sima from being started
> 
> 
> well, can't you use some systemd facilities to do the same?
> 
> http://www.freedesktop.org/software/systemd/man/systemd.unit.html
> http://www.freedesktop.org/software/systemd/man/systemd.service.html
> 
> (or make systemv script behave in the same way)

d/control:
  - The Vcs-Browser URL refers to the gitweb viewer, whereas the current
viewer seems to be cgit (the gitweb URL just redirects there)

d/changelog:
  - typo: convertion -> conversion
  - When bumping S-V, while not necessary, it is good practice to
indicate what changes were made in the process, or "no changes
needed" if that was the case
  - It is helpful to be more explicit about some changes. You mention,
for example, that the package has been converted to Python 3. The
fact that the Python 2 package has been dropped is merely implied.
That is IMHO a significant change, and should be worth a hint

d/copyright:
  - The Upstream-Source URL lists something completely different to the
the Homepage field in d/control. Could it be that one of them needs
to be updated?

d/NEWS:
  - The upgrade path suggestion for the conffile in /etc isn't
really the prettiest solution, although I really don't know what
other path I could suggest that wouldn't seem like overkill. How
did upstream handle this change? Do they perhaps have a script or
tool that could assist in this process?

d/
  - I encountered a lintian warning when building your package

Apologies for not providing more accurate references and/or possibly
outdated information. I had your package source in /tmp, which of course
didn't survive a reboot...

> (note, some of them might be not issues or just nitpicks, feel free to tell 
> me so if
> you think they are good that way)

Same here.



signature.asc
Description: OpenPGP digital signature

Bug#787328: RFS: mpd-sima/0.13.1-1

[Christian Kastner]

(replying just to the issues I raised)

On 2015-09-15 21:00, Geoff wrote:
>>   - It is helpful to be more explicit about some changes. You mention,
>> for example, that the package has been converted to Python 3. The
>> fact that the Python 2 package has been dropped is merely implied.
>> That is IMHO a significant change, and should be worth a hint
> Indeed, though, this is not a python module but only an application.

Oh, my bad! Sorry about that. (Hence also why I hadn't posted my notes
earlier -- the review was still somewhat rough)

>> d/NEWS:
>>   - The upgrade path suggestion for the conffile in /etc isn't
>> really the prettiest solution, although I really don't know what
>> other path I could suggest that wouldn't seem like overkill. How
>> did upstream handle this change? Do they perhaps have a script or
>> tool that could assist in this process?
> 
> Well, I'm actually upstream, I did not write any tool to migrate the
> conf.

Oh -- another thing I seem to have missed.

> Since the package is not that popular (popcon ~ 100) and because
> target users are quite probably advanced users and command line lovers,
> I did not try to handle a nice and smoothly conf upgrade.
> 
> Well I think the current tradeoff to be acceptable given the package
> popularity and users profile.

I believe you are right. After all, you are preserving possible user
changes to the conffile, in accordance with the Policy.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Splitting a source package with a new upstream version

[Christian Kastner]

Hi,

libfann 2.1.0~beta+dfsg-1 in Debian currently builds a library as
binary package libfann2, and Python bindings for it as binary package
python-pyfann.

The new upstream version 2.2.0 of libfann no longer provides the Python
bindings; they are now provided by an external contributor instead.
(Apart from this, is otherwise a fairly minor update of the library.)

I'm now wondering how to best handle this split.

The simplest solution, as far as I see it, would be to
  1. upload a 2.2.0 version of the library, with the Python bindings
 dropped. python-pyfann currently has a versioned dependency on a
 specific version of the library, libfann2 (=2.1.0~beta+dfsg-1).
 Therefore, The library itself will not be upgradeable without
 breaking or removing python-pyfann.
  2. Upload the Python bindings from the new upstream source, built
 against the new version of the library
  3. After the bindings have passed NEW, both library and bindings
 should be upgradeable smoothly.

Before getting into the other, more complex, alternatives: am I seeing
this correctly, or am I overlooking some important issue?

Regards,
Christian

Re: Splitting a source package with a new upstream version

[Christian Kastner]

On 2015-09-23 11:56, Jakub Wilk wrote:
> * Christian Kastner , 2015-09-22, 11:08:
>> 1. upload a 2.2.0 version of the library, with the Python bindings
>> dropped. python-pyfann currently has a versioned dependency on a
>> specific version of the library, libfann2 (=2.1.0~beta+dfsg-1).
>> Therefore, The library itself will not be upgradeable without breaking
>> or removing python-pyfann.
>> 2. Upload the Python bindings from the new upstream source, built
>> against the new version of the library
>> 3. After the bindings have passed NEW, both library and bindings
>> should be upgradeable smoothly.
> 
> Sounds good to me.

Thank you for the feedback!

> Although to minimize time when python-pyfann is uninstallable, you
> might want to do it in a different order: upload src:pyfann first, 
> wait until it's accepted, then upload src:libfann that no longer
> builds python-pyfann.

That is better indeed.

Regards,
Christian

Re: How to accomodate test files that move after installation?

[Christian Kastner]

Hi Jeffrey,

On 2015-09-30 14:17, Jeffrey Walton wrote:
> Crypto++ has test files. When they are run from $PWD, them they work
> fine. After installation into, say, /usr/share/, they break because
> the location is an implicit dependency. So the two requirements are
> self test must always run from: (1) the build directory, and (2) the
> installation directory.

I'm not entirely sure I've understood the issue, but are you sure about
the last sentence? It's sounds like you expect (1) and (2) to hold at
the same time. Purely intuitively, I would have expected something like
" self test must always run from: (1) the build directory _at build
time_, and (2) the installation directory _after installation_" instead.

If that is the case, then I wouldn't try to tackler both problems with
one solution, but instead prepare the tests for use in scenario (2),
where there is a general interest and continuous utility, and work with
a modified copy in scenario (1), where there is only a one-time interest
by the buildd. For scenario (2), it would be great if you would also
provide an autopkgtest [1] suite for your package to provide
"as-installed" testing.

If that is not the case, apologies!

[1] http://dep.debian.net/deps/dep8/

Regards,
Christian

Bug#790104: RFS: lightdm-gtk-greeter-settings/1.2.0-1 [ITP]

[Christian Kastner]

Hi James,

a review of your package follows:

On 2015-06-27 06:59, James Lu wrote:
> I am looking for a sponsor for my package "lightdm-gtk-greeter-settings".
> 
>  * Package name: lightdm-gtk-greeter-settings
>Version : 1.2.0-1
>Upstream Author : Andrew P. 
>  * URL : http://launchpad.net/lightdm-gtk-greeter-settings
>  * License : GPLv3
>Section : utils


> Changes since the last upload:
> 
> lightdm-gtk-greeter-settings (1.2.0-1) unstable; urgency=medium
> 
>   * Initial Debian release, imported from Ubuntu. (Closes: #788614)
>   * debian/ folder changes:
> - Add a watch file pointing to Launchpad.
> - Write a manpage (lightdm-gtk-greeter-settings.1), dropping
>   the binary-without-manpage lintian override
>   for /usr/bin/lightdm-gtk-greeter-settings.
> - Add a get-orig-source target for debian/rules.
> - Set myself as maintainer.
> - Set package source/format to 3.0 quilt.
> - debian/links: symlink the root NEWS file as an upstream changelog.
>   This fixes the no-upstream-changelog Lintian pedantic warning.
> - debian/rules: override dh_auto_clean to remove
>   po/lightdm-gtk-greeter-settings.pot, so that successive builds work.

d/control:
 - The frontend for git at anonscm.d.o has been changed from gitweb to
   git; please update Vcs-Browser URL accordingly
 - Developer's Reference §6.2.2 says that the synopsis is not a
   sentence, so you don't need to start it with a capital letter
 - synopsis / long description: GTK is spelled with all-caps, however
 - Depends seems to be missing Pango, going by PKG-INFO

d/copyright:
 - The license appears to be GPL-3, not GPL-3+ (at least in the handful
   of files I checked). This also requires correction of the free-
   standing license block (the last paragraph)
 - In the header, the field's name is "Source", not "Upstream-Source"
 - There's a formatting issue in the free-standing license text (line
   27 is not indented)

d/lightdm-gtk-greeter-settings.lintian-overrides:
 - Instead of adding lintian override for the missing man page of
   lightdm-gtk-greeter-settings-pkexec, symlinking it to the
   manpage of lightdm-gtk-greeter-settings, as some other packages do
   for -pkexec files (eg: src:mate-system-tools), would be more useful

d/rules:
 - You don't need a get-orig-source target for a mere uscan invocation.
   g-o-s is for cases in which downloading via uscan produces something
   that does _not_ match the orig tarball uploaded to the Debian
   archive: for example, when files have been removed from the original
   source (think: DFSG cleaning), or when you can only recreate the
   tarball by checking out from a repository

I'm happy to sponsor your package, but out of curiosity: have you tried
pinging the lightdm-gtk-greeter maintainers? They could be interested in
this package, and are probably in a much better position to assist you
with issues related to this program than I am.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: Bug#790104: RFS: lightdm-gtk-greeter-settings/1.2.0-1 [ITP]

[Christian Kastner]

On 2015-10-05 22:47, Christian Kastner wrote:
>  - The frontend for git at anonscm.d.o has been changed from gitweb to
>git; please update Vcs-Browser URL accordingly

I meant cgit, sorry.




signature.asc
Description: OpenPGP digital signature

Bug#790104: RFS: lightdm-gtk-greeter-settings/1.2.0-1 [ITP]

[Christian Kastner]

On 2015-10-11 07:54, James Lu wrote:
>> d/copyright:
>>  - The license appears to be GPL-3, not GPL-3+ (at least in the handful
>>of files I checked). This also requires correction of the free-
>>standing license block (the last paragraph)
> 
> I see. Ubuntu's packaging wrote the license as GPL-3+ for both the
> packaging and the source, but I guess the license of the individual
> files must prevail here. Fixed.

Hm, I just realized that I overlooked something here, namely the license
of the packaging that came from Ubuntu :-/

that makes things a bit more complicated, because:
* It is clear that upstream wanted GPL-3 for the upstream source
* It is clear that Ubuntu's packager wanted GPL-3+ for the
packaging, even if this motive was inspired by the erroneous
assumption of the GPL-3+ for the upstream source (asking the
packager directly might resolve that)

IOW, my initial advice was wrong. You need to keep GPL-3+ for the
packaging, and add GPL-3 for the upstream source.

Sorry about the mixup!

>>  - There's a formatting issue in the free-standing license text (line
>>27 is not indented)
> 
> I'm not sure what this means. Is it supposed to be indented to the width
> of "X-Comment: "? That's what I did.

Oh, I see what you meant to do now -- it wasn't lacking indentation, it
was beginning a new field.

However, in that case, the field's name is just "Comment" [1], without
the "X-" prefix.

[1] 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#stand-alone-license-paragraph

Regards,
Christian




signature.asc
Description: OpenPGP digital signature

Bug#801237: mactel-boot review

[Christian Kastner]

On 2015-10-23 21:47, Bernhard Reiter wrote:
> Am 2015-10-23 um 18:47 schrieb Gianfranco Costamagna:
>> Control: owner -1 ! Control: tags -1 moreinfo
> 
>> Hi, the packaging looks fine, however I don't understand what the 
>> code is supposed to do.
> 
>> seems that the purpose of this code is to send an ioctl call and 
>> nothing more?
> 
> That's correct -- its sole purpose is to set an HFS+ partition as
> bootable. See the included man file, and
> http://heeris.id.au/2014/ubuntu-plus-mac-pure-efi-boot/#fixing-efi for
> some more context.

That article seems to contain some misinformation. For example:

  | So why is the system unbootable? The problem is that the Mac
  | bootloader expects the EFI partition to be formatted as HFS+, the
  | typical Mac filesystem.

I have a MacBook Air (2013), and the EFI system partition came formatted
as FAT. Isn't this even required by the spec?

At least with Jessie, installation was a breeze. With wheezy and
earlier, I remember having to jump a few hoops to get everything running
smoothly (like "blessing" from within OSX, and what not), but Jessie
just worked out of the box.

A one-step alternative that has always worked for me was copying
Debian's grubx64.efi to the default boot/bootx64.efi in the ESP, and
newer versions of grub offer to do this automatically for you.

[To be clear: I don't mean to say that mactel-boot isn't useful, only
that the article above should probably be double-checked.]

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#804343: RFS: libsvm/3.20-1 [NMU] -- library implementing support vector machines

[Christian Kastner]

Hi,

On 2015-11-07 18:21, Gianfranco Costamagna wrote:
>>libsvm (3.20-1) unstable; urgency=medium
>>
>>  * Non-maintainer upload.
[...] 
> 
>>  * Import new upstream version.
> 
> 
> this is really out of an NMU scope, do you have any evidence about the
> maintainer
> being MIA/not interested anymore, or acking you to upload a new release?

I'm the maintainer of LIBLINEAR, a package related to LIBSVM. I pinged
the maintainer of LIBSVM a while ago. He indicated that he's still
interested in maintaining it, but had to schedule the time.

I'll ping the maintainer again, and see whether he can make the time
soon.

In any case, LIBSVM's structure is very similar to LIBLINEAR, so an up
to date packaging could be taken from the latter and adapted to the
former.

Regards,
Christian

Bug#822360: RFS: sequitur-g2p/0.0.r1668-3 -- Grapheme to Phoneme conversion tool

[Christian Kastner]

control: owner -1 !

Hi Giulio,

I'd be happy to sponsor your package.

On 2016-04-23 21:06, Giulio Paci wrote:
> I am looking for a sponsor for an updated version of my package "sequitur-g2p"
> 
> You can download the package with git using this command:
> 
>git clone git://anonscm.debian.org/collab-maint/sequitur-g2p.git

First, a general note: more specific commit messages would facilitate
reviewing (at least for me). For example:

commit c98be9ed397b0ba4be9aa6c82f1ce1be54e06acf
Author: Giulio Paci 
Date: Tue Apr 19 21:56:57 2016 +0200

Updated control file.

What update was that? From the other commits, I can deduce that this was
merely a refreshing of d/control from d/control.in, and the actual
changes -- namely bumping Standards-Version, and updating Vcs-* --
happened earlier. This was a bit confusing, so being explicit about this
could be helpful.

Furthermore, the "better" your commit structure and messages, the more
you get out of them yourself. You seem to be using git-buildpackage, so
using the magic command `gbp dch`, you can have gbp initialize a
debian/changelog entry from your commit history for you. And the better
your commit history, the less polishing you need to do.

On to the specific notes:
  * d/copyright:
- Refers twice to the "GNU _Lesser_ General Public License". Seems
  to be copy-pasta, as all other references to GPL-2 are correct

  * d/patches:
- Please consider making the headers DEP3-compliant (although it's
  not a "hard" requirement): http://dep.debian.net/deps/dep3/
- Patches should be sufficiently self-describing. I can understand
  the motivation for 1013, 1014, and 1015 but not the others:
+ 1011: Why change multigram size? Did this improve something?
+ 1012: Why add SWIG options? How did this affect the build?

  * d/changelog:
- Please indicate why Vcs-* fields were changed. Something like:
  "Switch to secure URIs in Vcs-* fields"

Your package built cleanly and without lintian errors or warnings, so as
soon as you address the above issues, I'd be ready to upload.

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Bug#823470: RFS: sequitur-g2p/0.0.r1668.r3-1 -- Grapheme to Phoneme conversion tool

[Christian Kastner]

Hi Giulio,

On 2016-05-05 03:57, Giulio Paci wrote:

> I am looking for a sponsor for an updated version of my package "sequitur-g2p"

>git clone git://anonscm.debian.org/collab-maint/sequitur-g2p.git

> A package review is very welcome as well.

Looks good to me. Nice to see that upstream included so many of your
patches.

One thing I'm not quite sure I follow yet is the change in the version
numbering scheme, both upstream and in the package. This is how it looks
to me:

  1. Upstream re-used revision r1668 and added a -r3 suffix
  -> "r1668" trades a bit of revision semantic for version semantic

  2. Hence your switch to version semantic in d/changelog

Is my interpretation correct?

Regards,
Christian




signature.asc
Description: OpenPGP digital signature

Bug#823470: RFS: sequitur-g2p/0.0.r1668.r3-1 -- Grapheme to Phoneme conversion tool

[Christian Kastner]

On 2016-05-05 17:16, Giulio Paci wrote:
>> One thing I'm not quite sure I follow yet is the change in the version
>> numbering scheme, both upstream and in the package. This is how it looks
>> to me:
>>
>>   1. Upstream re-used revision r1668 and added a -r3 suffix
>>   -> "r1668" trades a bit of revision semantic for version semantic
>>
>>   2. Hence your switch to version semantic in d/changelog
>>
>> Is my interpretation correct?
> 
> You are right. The change is due to the fact that they relied on svn 
> revisions for releases in the past. Now they have switched to another 
> repository (probably still svn),
> and I understand that they are around revision 70 on the new one.
> 
> My understanding is that they have private versions of intermediate packages 
> that they did not publish.
> 
> I have not talked with upstream about this anyway.

I'd do that when you get the chance, just to clarify what release plans
they have. Some upstreams may even benefit from a bit of guidance, eg:

https://wiki.debian.org/UpstreamGuide#Releases_and_Versions

In this particular case, I'd actually suggest that you stick to your
previous approach, and just modify it slightly:

   g2p-r1668.tar.gz => 0+r1668
g2p-r1668-r3.tar.gz => 0+r1668.r3 (or even just keep -r3!)

The solution above retains the largest flexibility in the face of
the current ambiguity. For example, if upstream were to release a version
'0.0.1', your new solution would no longer work:

$ dpkg --compare-versions '0.0.r1668.3-1' lt '0.0.1-1' || echo "oops!"
oops!

You can achieve the aforementioned modification by chaining patterns in
uversionmangle using a semicolon. Based on your previous version:

-opts="uversionmangle=s/^(.*)$/0+$1/"
+opts="uversionmangle=s/^(.*)$/0+$1/; s/-r(\d+)/.r$1/"

$ uscan --report-status | grep -A4 'newest first'
uscan info: Found the following matching hrefs on the web page (newest 
first):
   g2p-r1668-r3.tar.gz (0+r1668.r3) index=0+r1668.r3-1 
   g2p-r1668.tar.gz (0+r1668) index=0+r1668-1 
   g2p-r103.tar.gz (0+r103) index=0+r103-1 
   g2p-r96.tar.gz (0+r96) index=0+r96-1

On a side note: I believe you can simplify the version matching pattern
in your watch file. You currently match for many possible suffixes, but
upstream apparently only uses .tar.gz.

Regards,
Christian




signature.asc
Description: OpenPGP digital signature

Re: Package Naming

[Christian Kastner]

On 2016-05-11 03:41, Benda Xu wrote:
> Hi,
> 
> I am packaging a library called "casacore" which provides
> 
>   libcasa_python3.so.2 and libcasa_python.so.2
> 
> with SONAME=2.
> 
> How should them be named when the python major version and SONAME could
> cause confusion?
> 
> I can think of
> 
>   libcasa2-python3 vs libcasa2-python
> 
> or
> 
>   libcasa-python3-2 vs libcasa-python-2
> 
> or
> 
>   python3-libcasa2 vs python-libcasa2
> 
> or
> 
>   python3-casacore2 vs python-casacore2

According to the Debian Python Policy [1] and assuming from [2] that the
module name is "casacore", the name should be:

Python2: python-casacore
Python3: python3-casacore

After all, one would "import casacore", and not "import casacore2".

[1] 
https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names
[2] http://casacore.github.io/python-casacore/

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: Package Naming

[Christian Kastner]

On 2016-05-11 22:13, Ole Streicher wrote:
> Christian Kastner  writes:
>> On 2016-05-11 03:41, Benda Xu wrote:
>>> I am packaging a library called "casacore" which provides
>>>   libcasa_python3.so.2 and libcasa_python.so.2
>>> with SONAME=2.
>>> How should them be named when the python major version and SONAME could
>>> cause confusion?
> 
>> According to the Debian Python Policy [1] and assuming from [2] that the
>> module name is "casacore"
> 
>> [2] http://casacore.github.io/python-casacore/
> 
> That is another package. As far as I understand it, the libraries
> mentioned by Benda are just some data type converters; they don't
> contain an importable module. The package in [2] is built on top of this
> library (but a package that is built independently), and this should
> ofcourse get the name given in the policy.
> 
> The library Benda speaks about is not covered by the Python Policy, but
> a normal shared library that should be covered by the standard Debian
> Policy.

I should have looked into it more. Thank you for correcting me!

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: Salsa CI documentation updated

[Christian Kastner]

On 2024-09-27 11:09, Jeroen Ploemen wrote:
> On Fri, 27 Sep 2024 10:12:29 +0200 Christian Kastner  wrote:
>> For src:rocminfo, we have pipelines that fail [1,2,3] because
>> rocminfo depends on bin:libhsa-runtime64-1 also from experimental.
> 
> That should be a matter of setting the RELEASE variable, if it
> weren't for several long standing bugs:
> https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/57
> https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/58
> https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/85

Thanks for the pointers, Jeroen. The three linked issues explain all the
failures that we are seeing.

Best,
Christian

Re: Salsa CI documentation updated

[Christian Kastner]

Hi Otto,

On 2024-09-24 18:18, Otto Kekäläinen wrote:
> We've overhauled the README.md at
> https://salsa.debian.org/salsa-ci-team/pipeline to be as complete as
> possible, yet clear and to the point. If you are not yet using Salsa
> CI for pre-upload quality assurance for your package, you might want
> to check out what Salsa CI offers, or just review that your current
> usage is optimal.

thanks, this is really useful to me (who just tends to cargo-cult stuff).
> Feedback and improvement suggestions are also welcome as Merge
> Requests are via email.

Could you add a note on how to best run things in experimental?

For src:rocminfo, we have pipelines that fail [1,2,3] because rocminfo
depends on bin:libhsa-runtime64-1 also from experimental.

Best,
Christian

[1]: https://salsa.debian.org/rocm-team/rocminfo/-/jobs/6342778
[2]: https://salsa.debian.org/rocm-team/rocminfo/-/jobs/6327115
[3]: https://salsa.debian.org/rocm-team/rocminfo/-/jobs/6327111

Re: Can Debian Maintainers sponsor packages?

[Christian Kastner]

Hi Tiago,

On 2025-01-17 14:51, Tiago Bortoletto Vaz wrote:
> It is very much appreciated that you were diligent and consulted
> documentation (and this list) before trying to sponsor packages as a DM.
> Technically, it's not possible. See:
> 
> https://wiki.debian.org/DebianMaintainer#Granting_Permissions

I think there might be a misunderstanding here: the above article is
about granting someone else upload privileges. Whereas here, we have a
DM who already has upload privileges, who would upload a version of a
team-maintained package that was prepared by another team member who
themselves aren't a DM yet.

This obviously cannot be a problem if contributions to the new version
were split 50/50 or even 80/20 between the DM and non-DM, as that is the
nature of a team-maintained package.

I posit that it shouldn't be a problem for the DM to upload even in the
0/100 case. If the DM is given trust do to uploads, that implies trust
that the DM will review the uploads, and has the necessary skills to
identify and correct any defects, including those caused by other team
members (DD or not).

This is just the "formal" view. On a technical level, I don't see what
could stop a DM for going ahead with this regardless, as the only
obstacle could possibly be the Changes line, and the DM could simply
change that before upload.

Best,
Christian