Re: Policy consensus on transition when removing initscripts.

[Jakub Wilk]

* Russ Allbery , 2023-06-27 23:19:
for some reason I thought we normally always combine Replaces with 
Breaks or Conflicts even for other cases.


There is a good reason.

Consider the following scenario:

* Package A 1.0-1 is installed providing file F.
* File F is moved to package B as of package A 1.0-3.
* User installs package B, which replaces the file in package A.
* User uninstalls package B.

F is now gone, even though it's supposed to be still shipped by A 1.0-1.

--
Jakub Wilk

Re: Bug#1033248: ITP: python-onetimepad -- python library for the onetimepad algorithm

[Jakub Wilk]

* Matthias Geiger , 2023-03-20 18:36:

https://github.com/jailuthra/onetimepad


Misleading package name. Should be: 
python-toy-xor-encryption-do-not-use.


No, really, don't upload this to Debian.


it's a dependency for banking (#1013317).


It seems banking uses this via an embedded copy of 
<https://github.com/harshnative/pysqlitecipher>, which is also 
horrifying.


--
Jakub Wilk

Re: Problems verifying signed github releases (Re: Q: uscan with GitHub)

[Jakub Wilk]

* FC Stegerman , 2023-02-19 21:08:

(There was a recent LWN article covering this, see
https://lwn.net/Articles/921787/.)


That seems to be subscribers-only :(


Here you go:
https://lwn.net/SubscriberLink/921787/ff1350f40f12fb8e/

--
Jakub Wilk

Re: ppc64el porterbox replacement: plummer.d.o -> platti.d.o

[Jakub Wilk]

* Johannes Schauer Marin Rodrigues , 2022-10-24 06:40:
this is the first time I hear about $arch-porterbox.debian.net. This is 
super cool! When was that announced


Not sure if that counts as an announcement, but jamessan blogged about 
it back in 2015: https://jamessan.com/~jamessan//posts/porterbox-logins/



and who maintains it?


Nobody...

Oh, you mean who owns the DNS records? That would be me.

I haven't done any porting work for years, so I would be glad if someone 
more active took over these records.


--
Jakub Wilk

Re: IPv6-only testing

[Jakub Wilk]

* Jakub Wilk , 2022-02-04, 15:38:

unshare -c -r --keep-caps


Oops, I meant "unshare -n -r --keep-caps".


$ python3 -c 'from socket import *; getaddrinfo("127.0.0.1", port=1, 
flags=AI_ADDRCONFIG)'


Note that the above does not fail when only loopback is configured, so 
it seems to be something else than #952740.


I haven't figured out what's exactly going on in #1004461, because the 
package FTBFS for me in a different way that I don't understand. :-/


--
Jakub Wilk

Re: IPv6-only testing

[Jakub Wilk]

* Julien Puydt , 2022-02-04, 12:34:
I got an RC bug on python-anyio, because its testsuite fails when run 
on an IPv6-only host [1].


I'm pretty sure "IPv6-only" means "the only non-loopback addresses this 
host has are IPv6", rather than "it doesn't have any IPv4, not even 
127.0.0.1."


This project uses AI_ADDRCONFIG: "IPv4 addresses are returned […] if the 
local system has at least one IPv4 address configured, […] The loopback 
address is not considered for this case as valid as a configured 
address."


Somewhat surprisingly, this means that getaddrinfo("127.0.0.1", ...) can 
fail even when the 127.0.0.1 address exists.


To reproduce this, unshare the network ("unshare -c -r --keep-caps" or 
"sudo unshare -n") and run:


$ ip link set lo up

$ ip link add dum0 type dummy

$ ip link set dum0 up

$ ip -br addr
lo   UNKNOWN127.0.0.1/8 ::1/128
dum0 UNKNOWNfe80::50aa:f3ff:fe1a:e828/64

$ python3 -c 'from socket import *; getaddrinfo("127.0.0.1", port=1, 
flags=AI_ADDRCONFIG)'
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.9/socket.py", line 954, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -9] Address family for hostname not supported

--
Jakub Wilk

Re: Help needed: C++ compile error with nix 2.5.1

[Jakub Wilk]

* Thomas Koch , 2022-01-16, 11:23:

https://github.com/NixOS/nix/issues/5923


The first bad commit is:
https://github.com/nlohmann/json/commit/0e694b4060ed55df

(This happens to be also the first bad commit for 
<https://github.com/nlohmann/json/issues/3204>, so I guess it's the same 
issue.)


I don't know what's going on here, but the attached patch seems to fix 
it.


--
Jakub Wilk
diff --git a/src/libstore/realisation.cc b/src/libstore/realisation.cc
index f871e6437..eb3ca0198 100644
--- a/src/libstore/realisation.cc
+++ b/src/libstore/realisation.cc
@@ -78,7 +78,7 @@ Realisation Realisation::fromJSON(
 auto fieldIterator = json.find(fieldName);
 if (fieldIterator == json.end())
 return std::nullopt;
-return *fieldIterator;
+return std::string(*fieldIterator);
 };
 auto getField = [&](std::string fieldName) -> std::string {
 if (auto field = getOptionalField(fieldName))

Re: Huh?? sbuild fails and pbuilder succeeds in building a Fortran-containing Python package

[Jakub Wilk]

* Johannes Schauer Marin Rodrigues , 2021-02-11, 00:15:

If I wrap the call to dh in debian/rules in strace -p


s/-p/-f/?


--chroot-setup-commands="chmod 777 /dev/shm"


s/777/1777/. (World-writable directories need the sticky bit.)

Or, better, mount tmpfs there to get the correct permissions for free.

--
Jakub Wilk

Re: possible MMBF regarding Depends: locales without | locales-all?

[Jakub Wilk]

* Ivan Shmakov , 2020-05-10, 06:57:
localehelper is just a wrapper to run localedef on missing locales; 
presumably this code path would simply never be followed with 
locales-all installed.


Yes; this is #839180.

--
Jakub Wilk

Re: file(1) now with seccomp support enabled

[Jakub Wilk]

* Christoph Biedl , 2019-07-27, 03:55:

The file program should[citation needed] not write to any file


...except when using the -C option.

--
Jakub Wilk

Re: Bug#912745: ITP: libregexp-wildcards-perl -- converts wildcard expressions to Perl regular expressions

[Jakub Wilk]

* Christoph Biedl , 2018-11-03, 12:41:

It handles the * and ? jokers,


s/joker/wildcard/ ?


Backspace (\) is used as an escape character.


I like the idea of backspace as escape character, but you probably meant 
"backslash" here. :-)


--
Jakub Wilk

Re: Bug#906250: ITP: execline -- small and non-interactive scripting language

[Jakub Wilk]

* Shengjing Zhu , 2018-09-02, 14:42:
When I try to package execline(a non-interactive shell script)[1], it 
installs following binaries in default PATH,


cd, if, exec, wait, 


Three of them (cd, umask, wait) clash with shell's regular built-in 
utilities. POSIX requires them to be exec(2)able[0][1]. Debian doesn't 
currently provide standalone executables for them (which is a bug), but 
some other distros do. The execline's implementation are of course not 
compatible with POSIX, and therefore must not be included within PATH.


[0] 
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tagtcjh_18
[1] 
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap01.html#tag_23_01_07

--
Jakub Wilk

Re: Bug#900286: ITP: spm -- simple password manager

[Jakub Wilk]

* Paride Legovini , 2018-05-28, 17:33:

spm is a single fully POSIX shell compliant script


Somehow these kind of grandiose claims are never true.

This script:
- has a shebang[0];
- passes -G to grep (not in POSIX);
- uses readlink(1) (not in POSIX).

But anyway, this is an implementation detail, so I don't think it 
belongs to the package description.



with basic tools such as find(1) and tree(1).


find(1) is in POSIX, so I'm not sure it was mentioned explicitly.
tree(1) is not "basic". It's obscure.

Passwords are stored as GPG encrypted files with directories funtioning 
as (sub)groups.


Typo: funtioning -> functioning


In Debian the script will be installed as 'spm.sh'


That would be against Policy §10.4.
Please talk to upstream about choosing a different name.


[0] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
“If the first line of a file of shell commands starts with the 
characters "#!", the results are unspecified.”


--
Jakub Wilk

Re: Keysafe dynamic UID

[Jakub Wilk]

* Vincent Bernat <ber...@debian.org>, 2016-10-23, 00:14:
I am using the username 'keysafe'.  I do not anticipate any collision with 
any other package, but policy says I should e-mail you to confirm that.
It is better to use either _keysafe or Debian-keysafe to avoid collision with 
existing users (like Kevin Eysafe).


Maybe we could fix #429671?
I know it's been only 9 years old, but still...

--
Jakub Wilk

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Jakub Wilk]

* Lars Wirzenius <l...@liw.fi>, 2016-10-18, 19:14:
The WTFness of this code is certainly way above what we're normally used to, 
but (AIUI) it's only used as a fallback for nodejs < 4. Debian currently has 
4.6.0.


In that case, perhaps this package isn't needed in Debian at all?


You would have to patch the depending packages to use os.homedir() directly 
rather than through the wrapper this package provides. But that might be easier 
than surviving the debian-devel discussion. :-P


--
Jakub Wilk

Re: Bug#841196: ITP: node-os-homedir -- Node.js 4 `os.homedir()` ponyfill

[Jakub Wilk]

* Lars Wirzenius <l...@liw.fi>, 2016-10-18, 17:57:

if (process.platform === 'linux') {
return home || (process.getuid() === 0 ? '/root' : (user ? 
'/home/' + user : null));
}

Things are more complicated than that. What exactly is this code meant to be 
used for?


This is so wrong, I would like to ask that this package not be allowed into 
Debian until it's fixed.


The WTFness of this code is certainly way above what we're normally used to, 
but (AIUI) it's only used as a fallback for nodejs < 4. Debian currently has 
4.6.0.


If you assume /root is root's home directory, and it's actually someone else's 
directory, and you trust /root/.ssh/authorized_keys is root's authorized ssh 
keys, you're going to have a bad time.


Er, no. Making /root writable to another user is almost as clever as making 
/bin or /etc writable to others. A sysadmin who does that must be prepared to 
suffer consequences.


--
Jakub Wilk

Re: When should we https our mirrors?

[Jakub Wilk]

There's nothing stopping mirror operators from enabling HTTPS. Some of them 
actually have done it already:

https://crt.sh/?q=ftp%25.%25.debian.org
(and there's more in non-*.debian.org domains)

We should have an official list of HTTPS mirrors, and encourage more operators 
to enable it.


On a semi-unrelated note:

Some of ftp*.*.d.o and cdimage.d.o mirrors serve random free (and sometimes 
non-free) software that is not Debian[*]. This may mislead inexperienced people 
into thinking that this software is endorsed or even produced by Debian. Should 
we insist that only Debian is served from these domains?



[*] See e.g.: https://ftp.se.debian.org/

--
Jakub Wilk

Re: Network access during build

[Jakub Wilk]

* Jérémy Lal <kapo...@melix.org>, 2016-10-06, 17:48:
Is there some simple way to check, when using sbuild, that the build does not 
access network ?


It probably doesn't count as simple, but:

I have a separate user for building, and log (and block) all outgoing traffic 
of this user using iptables/ip6tables.


--
Jakub Wilk

Re: package builds crashing under fakeroot

[Jakub Wilk]

* Graham Inggs <gin...@debian.org>, 2016-10-04, 12:33:
Not sure how to fix it for aster as apparently building the elements catalog 
is part of the upstream install run.  Maybe the upstream build system can be 
modified to build that catalog during build, not install?


I'm not really familiar with aster's build system.  I happened to upload the 
last NMU in order to fix a build with PETSc.


Let me see:

$ ./waf --help | grep buildelem
 buildelem : execute the build for elements catalog only using 
an installed Aster (also performed at install)

So it should be a matter of adding "waf buildelem" to override_dh_auto_build... 
Nope, that would be too easy:


$ ./waf buildelem
Waf: Entering directory `/home/jwilk/aster-11.5.0+dfsg2/build'
No function build_elements defined in 
/home/jwilk/aster-11.5.0+dfsg2/catalo/wscript

I've filed a bug upstream:
https://bitbucket.org/code_aster/codeaster-src/issues/84

--
Jakub Wilk

Re: Bug#839210: ITP: bash-unit -- bash unit testing enterprise edition framework for professionals

[Jakub Wilk]

* Pascal Grange <pas...@grange.nom.fr>, 2016-09-30, 08:53:

* URL : https://github.com/pgrange/bash-unit


404

--
Jakub Wilk

Re: package builds crashing under fakeroot

[Jakub Wilk]

* Alastair McKinstry <mckins...@debian.org>, 2016-10-03, 15:50:
What do DDs think should be done about this - move all tests outside 
binary-arch?


Yes. Everything that doesn't require root privileges should be done in build*, 
not in binary*.


In the long run, I'd love if Debian supported building packages without 
fakeroot at all.


--
Jakub Wilk

Re: package builds crashing under fakeroot

[Jakub Wilk]

* Svante Signell <svante.sign...@gmail.com>, 2016-10-04, 08:54:

From memory I think this is due to usage of the default rule:
%:
dh $@

with no override_dh_auto_build and override_dh_auto_test rules. By default the 
tests are run under fakeroot,


No, they're not.

--
Jakub Wilk

Accepted openjade 1.4devel1-21.3 (source) into unstable

[Jakub Wilk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 01 Oct 2016 17:01:25 +0200
Source: openjade
Binary: openjade libostyle1c2 libostyle-dev
Architecture: source
Version: 1.4devel1-21.3
Distribution: unstable
Urgency: low
Maintainer: Neil Roeth <n...@debian.org>
Changed-By: Jakub Wilk <jw...@debian.org>
Description:
 libostyle-dev - OpenJade libraries, developer support
 libostyle1c2 - Runtime libraries for OpenJade
 openjade   - Implementation of the DSSSL language
Closes: 823419
Changes:
 openjade (1.4devel1-21.3) unstable; urgency=low
 .
   * Non-maintainer upload.
   * Pass -fno-lifetime-dse to GCC to work around invalid assumptions about
 object lifetimes (closes: #823419). Thanks to Daniel Schepler for the bug
 report.
Checksums-Sha1:
 8bde67a32878c64d3899ff0abd9081f925370f3d 1896 openjade_1.4devel1-21.3.dsc
 d6f6fe5d2697957fe7655efa177c5c01491f2b7a 226350 openjade_1.4devel1-21.3.diff.gz
Checksums-Sha256:
 e00dfa8b5684351745679ffbe9184e43d276abdbb149af6b2f44e89bd737ee1f 1896 
openjade_1.4devel1-21.3.dsc
 5ada855d66edd745cf9319273ea49cd01da364c68e19871aa332f3d86798fb98 226350 
openjade_1.4devel1-21.3.diff.gz
Files:
 218de2cd4e0de4852ff370624c971420 1896 text optional openjade_1.4devel1-21.3.dsc
 3df60bd87e82475137cce4abb61dc147 226350 text optional 
openjade_1.4devel1-21.3.diff.gz

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJX79Z1AAoJEC1Os6YBVHX1wvYQAI3ok9f1kqKHhsDbEoIULbLR
GPQVbDnLdFKBUI06UrcCRyIZdkTXBv35bxA5iXajA8Fy3l21G+4HOO7vWqTzy51a
3BUDyiGBST7DzBenexOX2LC3yfVIThHanGWBgZvY4uKsE4X6w9ufnLfOqSwQ4AtG
f/3RodOyyTFNhHZB94w0Zb9vQjavi9XX/Ub4K9Nbv3RTSag/O/Hhe8XQLY2GQ1TE
12EY0kDHCy8OpipM+nzwmU10dwTIyf69E/82h2PGyiJsSpYmcm8cj51eTAZNSwxv
hQ4lJQ5Qe7eX6rjD3OPMBgoD48dex7vhPlczZYOVeuSfVO07kL6hblu/Ho8bHtYS
p+9JA4c5PDM94R9no5FbCI+4uuKPe0lMBWKYLzaPcV1vZsLfDVwBjq1assE0RA6M
bW6LS+EMtvzMtDY5LaPP6b3leyY04I4NcWWIN7Q8fBAd+50eHXCDKg3gqAgLN2nD
YcE4+BRgo2jwO8HM74YHccdPaMO7bIP3UfwjsJyvdQ+Jgm3xHSIBXiRebww0+mnO
gZj/P51mYLQnkexirrPcnwcAMUCGKYS2cIkpsfo8XyIm/JDmQOx/EIV126OFdsXO
iRiYwdII8waGjtfRsr0gwSScdULB0iBc1ghVhzQq051biLTxUdhqQUat8LGgGcNJ
ah5dTmwj8oqoyd1gpe+k
=GkW7
-END PGP SIGNATURE-

Re: Alternative solution

[Jakub Wilk]

* Nikolaus Rath <nikol...@rath.org>, 2016-09-30, 14:07:

Luckily, glibc has a way to disable DNS queries without LD_PRELOAD trickery:

$ RES_OPTIONS=attempts:0 wget http://www.example.com/


Wow, I wonder many people have used this innocent environment variable name 
and been bitten by weird network failures..


The name is not great, but it's been like that at least since 1995. It's not 
going to be changed.



Couldn't they at least call it LIBC_RES_OPTIONS?


codesearch.d.n tells me this variable in not (g)libc-specific. There are other 
resolvers that honour it, too. 


--
Jakub Wilk

Re: Alternative solution (was: Re: Network access during build)

[Jakub Wilk]

* Ian Jackson <ijack...@chiark.greenend.org.uk>, 2016-09-30, 15:03:

you can completely disable external network with socket_wrapper
... which is a pretty heavy-weight solution, and in fact it breaks asyncssh's 
tests.

Then that is clearly a bug in asyncssh's tests


... or in socket_wrapper, or in the way I used socket_wrapper. (Most likely the 
last one.)


--
Jakub Wilk

Re: Alternative solution (was: Re: Network access during build)

[Jakub Wilk]

* Jakub Wilk <jw...@debian.org>, 2016-09-07, 23:49:

you can completely disable external network with socket_wrapper


... which is a pretty heavy-weight solution, and in fact it breaks asyncssh's 
tests.


Luckily, glibc has a way to disable DNS queries without LD_PRELOAD trickery:

$ RES_OPTIONS=attempts:0 wget http://www.example.com/
--2016-09-29 22:49:22--  http://www.example.com/
Resolving www.example.com (www.example.com)... failed: Temporary failure in 
name resolution.
wget: unable to resolve host address ‘www.example.com’

--
Jakub Wilk

Re: removal instead of orphaning?

[Jakub Wilk]

* Adam D. Barratt <a...@adam-barratt.org.uk>, 2016-09-18, 11:28:
"Fixed in NMU" has not been a distinct state for several years, since the 
introduction of BTS version tracking.


To clarify, the state still exists:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=fixed
... but I guess most packages were tagged like this by mistake.

BTS version tracking was introduced in July 2005:
https://lists.debian.org/20050718110629.ga...@riva.ucam.org

dak started closing bugs for NMUs and experimental uploads only in February 
2007:

https://anonscm.debian.org/cgit/mirror/dak.git/commit/?id=141673ae65e8160c78464c1eac1ecb615aedfc54

It's been less than a decade, so it's normal people aren't used to it yet. :-P

--
Jakub Wilk

Re: Network access during build

[Jakub Wilk]

* Paul Wise <p...@debian.org>, 2016-09-19, 09:09:
The only controversial cases seem to be tests, and these can run optionally 
after the packages have been built.


Has anyone already thought of moving such tests into a separate optional step 
after the build is completed?


IIRC DEP-8 has a 'needs network access' option for tests.


No, it doesn't have. #743029

--
Jakub Wilk

Re: PIE and static libraries

[Jakub Wilk]

* Bálint Réczey <bal...@balintreczey.hu>, 2016-09-12, 13:21:
Reading up on the subject so far, I got the impression that most 
static libraries should be built with PIE, but not necessarily PIC (to 
allow building PIE(xecutable)s, but discourage creating shared 
libraries from those static ones.)


How does it discourage creating shlibs?

Also, is there a reliable way for a static checker (such as Lintian) to 
distinguish between -fPIC and -fPIE static libraries?


I don't see why should not we encourage using static libs in shared 
libs and recommending PIC would also simplify the currently mandated 
build process:


Meh, this complexity lies in upstream build system most of the time.

--
Jakub Wilk

Re: Upcoming change to perl: current directory in @INC

[Jakub Wilk]

* Lars Wirzenius <l...@liw.fi>, 2016-09-08, 14:04:
See https://docs.python.org/2/library/sys.html#sys.path for details. 
That page documents the cases where the empty string (effectively the 
same as .) are inserted into the beginning of sys.path, but they're not 
relevant for installed software: one is for when you run python and 
import on the REPL command line, the other is when you provide the 
script on the command line ("python -c 'foo bar'").


There's plenty of installed shell scripts that call "python -c 'foo 
bar'".


And there's even software that creates Python scripts in /tmp and then 
calls them: https://bugs.python.org/issue16202 *cough*cough*cough*


--
Jakub Wilk

Re: Uploading existing source but with different size

[Jakub Wilk]

* Marcin Kulisz <deb...@kulisz.net>, 2016-09-09, 13:08:
I have a package (libpqxx) where I was using my own repack script for 
quite a long time.


Now I want to upload new (Debian) version of it with existing (in the 
archive) upstream version but fixing some issues including 
reproducibility, etc. and using **File-Excluded** instead my repack 
script.


Unfortunately there is difference in size for *.orig.tar.gz between 
what's in the archive and what's updated package produces thus upload 
fails.


I'm not sure why this difference occurs (it's 27 bytes).

Any ideas how can I sort this out?


There's nothing to sort out.
Just use the .orig.tar that is in the archive.

--
Jakub Wilk

Re: Network access during build

[Jakub Wilk]

* Guus Sliepen <g...@debian.org>, 2016-09-09, 16:19:

AFAIK, at the moment it's only the buildds that block network access.


Do they? [citation needed]

--
Jakub Wilk

Re: [Request] Is there any way to get the full source codes of Debian?

[Jakub Wilk]

* Christoph Egger <christ...@debian.org>, 2016-09-08, 15:55:

(resending with less-mangled To field)


It's actually still mangled, in a different way though.

Was: "우승훈 <seunghoon...@korea.ac.kr>,"@bendel.debian.org

Now: =?utf-8?Q?=EC=9A=B0=EC=8A=B9=ED=9B=88 <seunghoon...@korea.ac.kr>


It is not? The ``Now`` part is proper, compliant encoding of header 
lines (before there can be mime encoding)


s/proper, compliant/broken/

"?=" after "=88" is missing.

Source: https://tools.ietf.org/html/rfc2047#section-2

--
Jakub Wilk

Re: Alternative solution (was: Re: Network access during build)

[Jakub Wilk]

* Christian Seiler <christ...@iwakd.de>, 2016-09-07, 07:43:
That way, you can force host name resolution to not use DNS for your 
test suite (via just using a hosts file), then there will be no network 
access during package build, and you don't have to keep rebasing a 
patch. And, even better, IF there is a host name called 'fail' on the 
local network, using nss_wrapper the package build will still succeed.


With nss_wrapper you can have your own hosts file, but I don't think it 
lets you force a name to fail to resolve.


However, you can completely disable external network with 
socket_wrapper:


$ LD_PRELOAD=libsocket_wrapper.so SOCKET_WRAPPER_DIR=$PWD wget 
http://www.example.com/
--2016-09-07 23:36:51--  http://www.example.com/
Resolving www.example.com (www.example.com)... failed: Temporary failure in 
name resolution.
wget: unable to resolve host address ‘www.example.com’

--
Jakub Wilk

Re: Network access during build

[Jakub Wilk]

* Russ Allbery <r...@debian.org>, 2016-09-07, 09:26:
Now, that said, assuming that "fail" is not a valid host in the local 
domain isn't a good assumption and makes the build fragile. My packages 
that perform a similar test use the DNS name addrinfo-test.invalid to 
force a failure, which is guaranteed by IANA reservations to not exist.


RFC 6761, §6.4.3 says:

Name resolution APIs and libraries SHOULD recognize "invalid" names as 
special and SHOULD always return immediate negative responses.  Name 
resolution APIs SHOULD NOT send queries for "invalid" names to their 
configured caching DNS server(s).


Unfortunately, glibc doesn't seem follow these recommendations. :-\

--
Jakub Wilk

Re: Network access during build

[Jakub Wilk]

* Vincent Bernat <ber...@debian.org>, 2016-09-07, 07:17:

both pbuilder and sbuild are using an isolated network namespace


I know about pbuilder, but [citation needed] for sbuild.

--
Jakub Wilk

Re: Alternative solution (was: Re: Network access during build)

[Jakub Wilk]

* Christian Seiler <christ...@iwakd.de>, 2016-09-07, 07:43:
And, even better, IF there is a host name called 'fail' on the local 
network


...or when your ISP hijacks all NXDOMAIN responses...


, using nss_wrapper the package build will still succeed.


--
Jakub Wilk

Re: Is missing SysV-init support a bug?

[Jakub Wilk]

* Adam Borowski <kilob...@angband.pl>, 2016-09-03, 22:40:

* https://jdebp.eu./Softwares/nosh/debian-binary-packages.html#run


I'm afraid your page is not working, on any of: Firefox, Chromium, Edge:
there's both a certificate name mismatch, then wrongly configured SNI.

Of course, dropping the stray dot helps, but as you insist on using it 
you need to configure your server appropriately.  I'm not sure you can 
get a cert with the dot signed by a CA, though.


elinks does accept it, but I'm afraid that limits your audience rather 
sharply.


And that's because certificate verification in elinks is broken:
https://bugs.debian.org/740981

--
Jakub Wilk

Accepted gsfonts 1:8.11+urwcyr1.0.7~pre44-4.3 (source) into unstable

[Jakub Wilk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 22 Aug 2016 22:53:12 +0200
Source: gsfonts
Binary: gsfonts
Architecture: source
Version: 1:8.11+urwcyr1.0.7~pre44-4.3
Distribution: unstable
Urgency: low
Maintainer: Masayuki Hatta (mhatta) <mha...@debian.org>
Changed-By: Jakub Wilk <jw...@debian.org>
Description:
 gsfonts- Fonts for the Ghostscript interpreter(s)
Closes: 618635 817488
Changes:
 gsfonts (1:8.11+urwcyr1.0.7~pre44-4.3) unstable; urgency=low
 .
   * Non-maintainer upload.
   * Bump debhelper compatibility level to 5 (closes: #817488).
 Thanks to Niels Thykier for the bug report.
   * Fix typo in the postrm scripts (closes: #618635).
 Thanks to Nathan Handler for the bug report and the patch.
   * Add build-arch and build-indep targets.
   * Add "Depends: ${misc:Depends}".
Checksums-Sha1:
 a37ec5f321988c9e391730d586ce8baf9f1384ad 1954 
gsfonts_8.11+urwcyr1.0.7~pre44-4.3.dsc
 c4d9198a73361532fa6de7161b428a471489e58b 6805 
gsfonts_8.11+urwcyr1.0.7~pre44-4.3.diff.gz
Checksums-Sha256:
 a559bdb044b36c2bfda00b4817ddad2c3f06af8013f908b0bf3c31905e44d5a3 1954 
gsfonts_8.11+urwcyr1.0.7~pre44-4.3.dsc
 1bc028fee68515d9888ed7e518533306eecd4ca185e4d81c326b900aae3aa79f 6805 
gsfonts_8.11+urwcyr1.0.7~pre44-4.3.diff.gz
Files:
 bf7aa80b5b64c4f23120cc412b703dad 1954 text optional 
gsfonts_8.11+urwcyr1.0.7~pre44-4.3.dsc
 0a7a74c0fce5abc9e584828bb6cad256 6805 text optional 
gsfonts_8.11+urwcyr1.0.7~pre44-4.3.diff.gz

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJXu2anAAoJEC1Os6YBVHX1NcAQAMv7ok7bM9geDvbkkx8Op8Nl
PBRBThOEqjO0Hje4E+o5h9UMR6S70jwHexVV6xSJn3NpPMTeQhVbFXKu5zi7FwZF
31fsICN/4V1FgPl3wWQYa1iuYJXSmMjLl8cwMzfeHw+QDoyKD/24xA9ibhi/3Mur
Q4X7qPCk9mDeEuh+E+oj09jBBNtJXWCe1AOtnE6X1AVtSE/sQwzEinJNTeb3DHwP
Aw5qRGUHzeBO5fBSWv8glCiKVWjmbj+8MxV2+G+N5kLiY2H0w44H4CFu+9B4MxT4
JVlo6tcofDGgRx4rCwoKuszOGSXVbloU+//1azwarLdbSJDZvqbX/gRQyJyRwWWQ
8vCYk82PpWFnWYWvTFYGlkZOL7RL4hcf2WBfdV3dbnx5kQD/UMNQ+lbEkNCqUdMK
ummQ+JmDfb5w0h7IzKc1PtcCW1ZmNVGqzN32DdyaYR3VMe0tiMfSRWH7JtDEOffT
V0RUfKME258GQncX/78CR6NWhOiEAZNCHETDp9y5LcUxGvbFAe1Ky5E3pJyzDheQ
0NvnMntgxCY53OUj0Mp5XqyEbgmyrbpceBajIG76n8WnFF2qWproCdGXJPBPhATg
6M5oYxDvFIrUJxqGgtjRcNnJ9Zd8VSiCUppXl0jTnhb0aXj9qtK76Hipz0dwJWmN
xocgy3kTvSBCp4IHibE3
=2r9F
-END PGP SIGNATURE-

Re: removal instead of orphaning?

[Jakub Wilk]

* Sebastian Reichel <s...@debian.org>, 2016-08-27, 02:24:

rc-alert -dU `wnpp-alert | grep "^O " | cut -d' ' -f 3`


I don't think this handles the case when the RC bug was filed against a 
binary package that has a different name than the source package.


Anyway, it's not like orphaned are the only packages that are neglected 
(or that all orphaned packages are neglected). Please consider running 
rc-alert against all packages you have installed (which incidentally 
make the command-line much simpler):


$ rc-alert -dU

--
Jakub Wilk

Accepted toilet 0.3-1.1 (source) into unstable

[Jakub Wilk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 22 Aug 2016 21:05:36 +0200
Source: toilet
Binary: toilet toilet-fonts
Architecture: source
Version: 0.3-1.1
Distribution: unstable
Urgency: low
Maintainer: Sam Hocevar <s...@debian.org>
Changed-By: Jakub Wilk <jw...@debian.org>
Description:
 toilet - display large colourful characters in text mode
 toilet-fonts - collection of TOIlet fonts
Closes: 805961
Changes:
 toilet (0.3-1.1) unstable; urgency=low
 .
   * Non-maintainer upload.
   * Fix FTBFS when building only architeture-independent packages
 (closes: #805961). Thanks to Santiago Vila for the bug report and the
 patch.
Checksums-Sha1:
 122ddbdf6b40c25102a0e798e2a42672e71d80e5 1860 toilet_0.3-1.1.dsc
 f899fc576b0c8d79c1890d025df03611ee9157f7 2784 toilet_0.3-1.1.debian.tar.xz
Checksums-Sha256:
 e8875e2ab895ae1f11ac12ec81a4aab1ef76bc5a948d4b6fde9ec1045408491e 1860 
toilet_0.3-1.1.dsc
 b3b022bc20273d20f2813a094631f64ff89b327f430a90f517c146077569634a 2784 
toilet_0.3-1.1.debian.tar.xz
Files:
 519ed07437225182ce518148bfef662f 1860 libs optional toilet_0.3-1.1.dsc
 3a7d45d28de147b6ef354859fcd304a3 2784 libs optional 
toilet_0.3-1.1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJXu08bAAoJEC1Os6YBVHX1ghgQAIPeZs03imX99WYCCI0WnxB3
ol8WFIu/8WCihJfCMkRRNJyY4/N4VsuAnGgV3Y43trTfK5mPaPPWIYc37uUQFlho
D5sCWZ1wj91awA3EbaQ8bJCVs3JcpO/mLHfYWbiZgwb6BniwjP1FmKRnL3O42Cm0
OFy1OXn5OITZMLpAjrHYDrP0iJUEBi9csKmwQfn/rGIGwHcjrwtezRYr9nZPNBKU
Wd63+F2CPPhjslQgYgi8tPcYluUYqTeUJb/qLuj6BUqvwny5QL+y//bqZeGvdW1/
HVclwq1FNCh/8acm8LsByYc0PYKLgSrHSwOwp7+F7/m7uhRdzeSLW7cbL6LXAcal
cRu4wCa8YCd8ZbupoAIaYJfPKf+DsOxFMHcB0Uavut9YkKNocKBh2UZTdpXmviHh
WFb2nso+riP+05RzqNBrDmvOPf0PVEIwIL85W10/84FX6vOjmO4kzJlkzHLlt7A8
2ky0XUcg1YVFkyMwVWGTYPog/kCFi0ILrHtiwtRIDTOXOMucbj21SZNXpzKgnkv0
FZ2SIqQUOICDwCjHl2HvObFzNcnXz4ejANqdgvN8ujPIGYIRr3mMI7IqSVdSbGsw
328YuBn51WvsvfgNV0QSW0XD5IyT1q216dE2efEFZAbrq2tu8RB7YtSQ9UJ48AVu
uNSok2RS4/yuCT8S2bK6
=RcSv
-END PGP SIGNATURE-

Re: Maybe helpful - tool to check for chains of trust and collisions in GPG signatures

[Jakub Wilk]

[Please CC Johannes Thomas Nix on replies; he's not subscribed.]

* Johannes Thomas Nix <johannes.thomas@posteo.net>, 2016-08-11, 09:16:
Found on Reddit a mention of the debian-devel thread about finding GPG 
key collisions for developer keys.


Why I write, a while ago I thought about these issues of key 
verification, and resulted in making a small tool which can discover 
and check trust paths  within the PGP web of trust. It uses the "PGP 
pathfinder" service to discover signature chains. It also warns about 
collisions.


The thing is still somewhat experimental (probably not suited for 
general use) but it might be helpful in situations like this.


https://gitlab.com/jnxx/check-trustpaths


Very interesting.

Sounds vaguely similar to Enrico's verify-trust-paths:
https://github.com/spanezz/verify-trust-paths


I am not writing this to debian-devel as I am not myself on the list.


We welcome contributions from people who are not subscribed, too.

If you think this is on topic and helpful, you are allowed to share 
this message.


Done!

--
Jakub Wilk

Re: Key collisions in the wild

[Jakub Wilk]

* Samuel Thibault <sthiba...@debian.org>, 2016-08-10, 01:17:

Samuel Thibault, on Wed 10 Aug 2016 00:47:43 +0200, wrote:

€ gpg --search-key samuel.thiba...@gnu.org
...
(1) Samuel Thibault <samuel.thiba...@gnu.org>
4096 bit RSA key 7D069EE6, created: 2014-06-16


And it has 55 signatures from 55 colliding keys...


The forger botched it up, because all its signatures have almost the 
same creation time. You can tell it's a sham key from quite a long way 
away.


--
Jakub Wilk

Re: Key collisions in the wild

[Jakub Wilk]

https://codesearch.debian.net/search?q=%5Cbgpg2%3F%5Cb.*--recv%28-keys%3F%29%3F%5Cs%2B%280x%29%3F%5B0-9a-fA-F%5D%7B8%7D%5Cb

(And there's probably more that this simplistic search doesn't catch...)

Any volunteers to file bugs?

--
Jakub Wilk

Re: sybase license and openWatcom DFSGness

[Jakub Wilk]

* Guus Sliepen <g...@debian.org>, 2016-08-01, 14:01:
Virtualbox is under GPL-2 with a lot of exception, allowing it to be 
used with MPL, Apache 2.0, OpenSSL.


So, LGPL-3 will be too restrictive I think for them.


It should be fine to combine GPL-2 and LGPL-3.


No, GPLv2 and LGPLv3 are not compatible:
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility

--
Jakub Wilk

Re: Policy 12.3: should I rename?

[Jakub Wilk]

* Shachar Shemesh <shac...@debian.org>, 2016-07-16, 23:04:
The package currently ships the docs in a package calles 
"libargtable2-docs" (plural). I am wondering whether I should rename 
it, and how to do it.


As far as I can tell, I have three options:

1. Don't rename. It's only a "recommends".
2. Rename with full transitional package
3. Rename without transitional package

The incentive for doing 3 is that the dev package already depends on 
the docs package, so a transitional package might not be all that 
important.


Another question I have is regarding packaging. The Policy suggests 
that libargtable2-doc should install the docs to 
/usr/share/doc/libargtable2.


Policy is rather unclear about the details[0], but I don't think anybody 
would expect to find API documentation in /usr/share/doc/libargtable2, 
especially when no package named "libargtable2" exists.


I would expect to find these files in /usr/share/doc/libargtable2-dev.

It seems that debhelper is not a friend in that regard, pushing me to 
install to /usr/share/doc/libargtable2-doc.  Am I missing some option 
that would make that easy?


You can use dh_install, instead of dh_installdocs, which lets you choose 
destination directory.


Or maybe you could merge -dev and -doc(s) packages? The documentation is 
currently pretty big, mostly because of suspiciously large PDF and PS 
files. Perhaps you could make them smaller somehow, or get rid of them 
completely? I think HTML documentation would be sufficient for most 
(all?) users.



[0] Literal interpretation of §12.3 is that documentation for 
"libargtable2-dev" should be in the package named 
"libargtable2-dev-doc", but I don't think that's what we want.


--
Jakub Wilk

Re: Replacing web assets with symlinks to packaged versions

[Jakub Wilk]

* Thomas Goirand <z...@debian.org>, 2016-07-12, 14:54:
The usual way to do things here, is to delete the files from the tree 
before building the package, just to make sure that you're not using 
it. But my understanding is that it's otherwise fine to just leave it 
there,


ACK

even though it'd be better to repack it and remove the .min.js files if 
you have enough time to spare doing so.


I wouldn't remove .min.js stuff just because I have enough free time.
We should use pristine upstream tarballs whenever we can.

--
Jakub Wilk

Re: So I received a gpg-signed email, can I trust it?

[Jakub Wilk]

* Simon Richter <s...@debian.org>, 2016-07-08, 14:33:
given that it is now possible to generate arbitrary short key ID 
collisions[1], and that it's now computationally feasible to at least 
generate a pair of keys with colliding long key IDs, I'd like to 
rethink practices and tools.


With the web of trust, in principle there shouldn't be a problem.

I have a valid trust path to Piotr's correct key. I don' have any to 
the fake key, because no one I trust has signed a key from the evil32 
set

...yet.

Given that many crypto tools have --feel-free-to-shoot-me-in-the-foot as 
the default, and some even don't have --do-not-shoot-me-in-the-foot as 
an option (see #800134), it's only a matter of time before someone slips 
up.


Or maybe it's already happened? Check out debian-hiding-problems@, er, I 
mean debian-private@ archives.


--
Jakub Wilk

Re: So I received a gpg-signed email, can I trust it?

[Jakub Wilk]

* Enrico Zini <enr...@enricozini.org>, 2016-07-08, 11:21:

 $ mkdir /tmp/keyring
 $ chmod 0700 /tmp/keyring


This way of creating a directory inaccessible to other is racy. Between 
mkdir and chmod calls, the directory could be opened by an attacker (and 
then kept open forever). A non-racy way looks like this:


$ mkdir -m 0700 foobar


And you really shouldn't use /tmp as a personal scratch space.
/tmp is word-writable and therefore not suitable for this purpose.

(Yes, I realize that these are just examples. But let's not teach people 
bad habits.)


--
Jakub Wilk

Re: mutt concentration camp (was Re: Neomutt packages available)

[Jakub Wilk]

* Adam Borowski <kilob...@angband.pl>, 2016-06-24, 17:32:
I have no idea what you are referring to here, but it reminds me to 
say that I think the name "mutt-kz" is a NO-GO. I know it's from the 
authors initials, but… to me it sounds like "mutt-hitler" or probably 
worse.


Send complaints to Karel's parents...

Every other two-letter sequence is going to mean something dreadful in 
some language. For example, millions[0] of Poles are offended when you 
talk about UBSan[1], or MO[2] files, or the .SS macro.


These, like mutt-kz, are pure coincidences.  For the original argument 
to hold any water, you'd need to find an _intentional_ example.


Like, say, KGB (kgb-{bot,client}).  And here, despite it being a vile 
murderous organisation (and far more murderous before name change in 
1954), I don't see any protests.  People see the bot's name as a joke.  
And I agree.


What about stalin ("extremely aggressive Scheme compiler")?

I find "kgb-*" a good joke and "stalin" distasteful, but I can't 
rationally explain the difference in these gut feelings.


But in either case, I wouldn't go as far as to demand package rename or 
removal.


--
Jakub Wilk

Re: mutt concentration camp (was Re: Neomutt packages available)

[Jakub Wilk]

* Holger Levsen <hol...@layer-acht.org>, 2016-06-24, 09:05:

I am suggesting that I remember what happened with mutt-kz.
I have no idea what you are referring to here, but it reminds me to say 
that I think the name "mutt-kz" is a NO-GO. I know it's from the 
authors initials, but… to me it sounds like "mutt-hitler" or probably 
worse.


Send complaints to Karel's parents...

Every other two-letter sequence is going to mean something dreadful in 
some language. For example, millions[0] of Poles are offended when you 
talk about UBSan[1], or MO[2] files, or the .SS macro.



And I don't think this is a german thing (well…)


It's not a thing in Poland, at least.


[0] for very small values of "million"
[1] https://en.wikipedia.org/wiki/Ministry_of_Public_Security_%28Poland%29
[2] https://en.wikipedia.org/wiki/Milicja_Obywatelska

--
Jakub Wilk

Re: Neomutt packages available

[Jakub Wilk]

* Clint Adams <cl...@debian.org>, 2016-06-24, 08:44:

I am suggesting that I remember what happened with mutt-kz.


What happened with mutt-kz?

--
Jakub Wilk

Re: Keysigning via Video Conferencing

[Jakub Wilk]

* Nikolaus Rath <nikol...@rath.org>, 2016-06-23, 09:23:
I am wondering if the extra burden is worth the gain in security. If 
everyone were to follow this procedure then the bar to becoming a 
Debian developer would be raised significantly.


As as data point, if everybody[0]'s key signing policy had been that 
establishing "social bonds" was a prerequisite, I would have almost 
certainly never become a DD.



[0] And by "everybody" I mean that one developer that happened to live 
in the same big city as me.


--
Jakub Wilk

Re: Package removal from testing for bug in stable

[Jakub Wilk]

* Eugene Zhukov <eug...@debian.org>, 2016-06-17, 10:31:
The package is marked for autoremoval from testing, however the RC[1] 
bug is reported against version in stable (testing has a newer version, 
without a bug).


How autoremoval is relevant in this case?

[1] Although my question is generic, #826864 triggered this question


According to the bug log, you haven't managed to reproduce the bug. So 
how do you know the newer version is not affected by it?


NB, at first glace it doesn't look like a problem with epubcheck itself, 
but with binfmt (jarwrapper?).


I don't know anything about Java, but relying on binfmt seems awfully 
brittle to me.


--
Jakub Wilk

Re: Verifying dep-5

[Jakub Wilk]

* Johannes Schauer <jo...@debian.org>, 2016-05-28, 10:04:
I was investigating this problem last year and as far as my research 
went, there is no tracing method in existence which reliably traces 
system calls in general, file system access or read/write operations 
while keeping track of the acting pid that is 100% reliable. The 
methods I found either were not transparent (and would thus break test 
suites) or suffered from race conditions where it was possible to 
register an operation but miss the pid the operation was carried out by 
or dropped operations if they occurred with a too-high frequency...


Have you tried systemtap?

Timo Juhani Lindfors wrote PoC that tracks all execs:
http://lindi.iki.fi/lindi/structured-buildlogs/logs/hello-2.6-1_amd64.build
http://lindi.iki.fi/lindi/git/structured-buildlogs.git/

Having such a reliable tracing method would give us the ability to 
reliably infer copyright information


As Paul noticed in another mail, system calls tracing won't necessarily 
help much. 

as well as generating structured build logs (knowing for each line in 
the build log the process (tree) that created it).


Consider the following pipeline:

$ (LC_ALL=C date | tail -c2; echo 6) | shuf | head -n1 | tee log
6

Which process created the log line? The technically correct answer is 
"tee"; but this answer is completely impractical.


--
Jakub Wilk

Re: Computing resources for DHG work

[Jakub Wilk]

* Sean Whitton <spwhit...@spwhitton.name>, 2016-05-29, 21:43:

The disc space required would be the total of:

- all the source packages & orig tarballs that have the haskell group 
specified as the Maintainer:

- plus all the binary packages built from those
- plus a base sid debootstrap chroot (around 1.6GB)


A chroot with build-essentials + apt + fakeroot is less than 600 MB.

I don't know how to find out the total size of those source and binary 
packages in advance of downloading all the tarballs and building them 
all (the DHG repo contains only the debian/ subdir); I would be 
grateful if someone pointed me at a way of extracting that information 
from the archive.


$ wget -q -O- 
http://httpredir.debian.org/debian/dists/unstable/main/source/Sources.xz | xz -dc 
| grep-dctrl -F Maintainer '<pkg-haskell-' -s Files | cut -d ' ' -f3 | numsum
136140166

$ wget -q -O- 
http://httpredir.debian.org/debian/dists/unstable/main/binary-amd64/Packages.xz | 
xz -dc | grep-dctrl -F Maintainer '<pkg-haskell-' -n -s Size | numsum
677197804

--
Jakub Wilk

Re: Bug#824057: ITP: bitkeeper -- source code management system

[Jakub Wilk]

Hi Daniel!

* Daniel Stender <sten...@debian.org>, 2016-05-11, 20:08:
Distributed source control management/revision control system. Known as 
being used for the Linux kernel development before Git was created. The 
now have put the code under the Apache-2.0 license. Maybe some would 
like to use this, so it would do no harm to have it as a Debian 
package.


This sounds as if you're not a Bitkeeper user yourself. I strongly 
recommend against packaging software you don't personally use. This 
never goes well. (I say this as someone who did this mistake in the 
past, multiple times.)


--
Jakub Wilk

Re: schroot broken in testing?

[Jakub Wilk]

* Brian May <br...@linuxpenguins.xyz>, 2016-05-10, 21:06:

schroot has suddenly decided to throw errors whenever I use it:

prune# schroot --chroot jessie-amd64-sbuild --user=root
E: 20copyfiles: cp: cannot create regular file 
'/var/run/schroot/mount/jessie-amd64-sbuild-569a4fef-b267-4e4b-bb6c-da14e167ddee/etc/resolv.conf':
 Operation not permitted
E: jessie-amd64-sbuild-569a4fef-b267-4e4b-bb6c-da14e167ddee: Chroot setup 
failed: stage=setup-start

prune# schroot --chroot sid-amd64-sbuild --user=root
E: 20copyfiles: cp: cannot create regular file 
'/var/run/schroot/mount/sid-amd64-sbuild-b87ff7e8-a09e-47ee-be8d-8a407056d84c/etc/resolv.conf':
 Operation not permitted
E: sid-amd64-sbuild-b87ff7e8-a09e-47ee-be8d-8a407056d84c: Chroot setup failed: 
stage=setup-start

Anybody else seen similar problems?


#821442

--
Jakub Wilk

Re: Bug#823672: ITP: sse-support -- prevent installation on processors without required support

[Jakub Wilk]

* Peter Colberg <pe...@colberg.org>, 2016-05-09, 13:33:

/* SSE2 */
#include 
static int check_sse2() {
   unsigned int eax = 0, ebx = 0, ecx = 0, edx = 0;
   __get_cpuid(1, , , , );
   return edx & bit_SSE2 ? 1 : 0;
}


You can use __builtin_cpu_supports("sse2") instead of manually playing 
with CPUID.


Documentation:
https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/X86-Built-in-Functions.html

--
Jakub Wilk

Re: How to change config script for multiarch?

[Jakub Wilk]

* Helmut Grohne <hel...@subdivi.de>, 2016-05-09, 06:47:
The first misconception I see in this thread is that somehow pkg-config 
is good and foo-config is bad. It's not as simple as that. Have a look 
at libpython3-dev. It ships e.g. x86_64-linux-gnu-python3-config.


This is an unfortunate example, because Python upstream supports 
pkg-config, unlike arch-qualified python*-config. (Why do we need the 
latter then? Go figure.)


So when converting your foo-config scripts to use pkg-config, you can 
go ahead and parse $0. Use that triplet instead of encoding it into 
your script. Then each libfoo-dev instance can place the same (shared) 
foo-config script in a shared location and place individual symbolic 
links with the prefix at it.


But then to actually take advantage of the newfangled 
-foo-config, you'll have to patch foo-config users. So why not 
patch them to use -pkg-config directly?



Here are my foo-config vs Multi-Arch tips:

* Don't read descriptions of old-style-config-script* Lintian tags. They 
are awful.


* It's often possible to make the script architecture-independent with 
little work. See #796770 for example.


* If the above doesn't work (or even if it does!), try persuading 
upstream to ship pkg-config files. And maybe ask them to deprecate 
foo-config. This might let you drop the foo-config in the (very far) 
future.


If none of this works, it's probably not the end of the world if your 
-dev package is not MA:same. Creating -foo-config, especially 
when it's not going to be adopted upstream, is most likely 
counter-productive.


And some general tips:

* Do not introduce Debian-specific interfaces.

* Do not remove upstream-supported interfaces, specially when no 
upstream-supported alternatives exist.


--
Jakub Wilk

Accepted libdebug 0.5.1-1.1 (source) into unstable

[Jakub Wilk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 06 May 2016 21:04:02 +0200
Source: libdebug
Binary: libdebug0 libdebug0-dev
Architecture: source
Version: 0.5.1-1.1
Distribution: unstable
Urgency: low
Maintainer: Peter Pentchev <r...@ringlet.net>
Changed-By: Jakub Wilk <jw...@debian.org>
Description:
 libdebug0  - Memory leak detection system and logging library
 libdebug0-dev - Development files for the debug library
Closes: 822194
Changes:
 libdebug (0.5.1-1.1) unstable; urgency=low
 .
   * Non-maintainer upload.
   * Disable parallel builds (closes: #822194).
Checksums-Sha1:
 a608c3c3a7d3e8afe89ae9c252f92e5def519c6e 1901 libdebug_0.5.1-1.1.dsc
 b0f788dbfdc77f1facd8f97610cc5f5d55621993 19288 libdebug_0.5.1-1.1.debian.tar.xz
Checksums-Sha256:
 c97d9101fc3f0cd6e82146249a93dc8d92a5c5ee28d8855399b49222a7de9815 1901 
libdebug_0.5.1-1.1.dsc
 16a9e222158a082fdccdb5557ad1c5f85c08d544ae29e156da297f76671b9051 19288 
libdebug_0.5.1-1.1.debian.tar.xz
Files:
 dbda9f27f39e993f351ec46b4c4b018d 1901 devel optional libdebug_0.5.1-1.1.dsc
 d427685d52666fe0da37ae526ff1c670 19288 devel optional 
libdebug_0.5.1-1.1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXLO3AAAoJEC1Os6YBVHX1ImUQAMAgEb0vXbboKPc+cQd330cx
+aQ4p4pNpdIpnw9ugweJDwPsHZMzwyKQdi//dw4q4sECs37Cv97cRG8rd+f66G9y
6boOZ+zep7RrsZ2EV23zupBKov3jFjNw90ibwTj1kjOLnIQfl5eVTHp243w+TI/H
dC8/idFtbdlH8YbZiZuu8QNvszciwCef4uK83EhKPaX1Jju570JbLY7lv/gvezNs
omLtUlO7tuTN0ABMx38MYNvypaZasHuJdpvJZb0eoAVRs2a5uZPjMx/7s49bQtzg
AzWV31SzIyLUmtUDMYVb/Z7SE3ic2ajsoe203vFd95dSCK6yfTfpPnvRUcLbXHSY
tfUXjSIiH5U0oJlwqqfxVcBYz5x8tkyhVntnZRocsvO7hxQa3ZnkJ07wVi2YRNeY
Wp8zLEPW2Ib/tlqktYJ9untoQoeGCRDUF5FPua9F3b1XjaxVTWvSTVBGJGLoXkUm
VxgnDoTk1vS7wLoElH22KUGPkao9KNs+4++iBWnuXSK5whR0+axV1wkjOh6ST+FP
8jWOE9KoMtD0fuGsYaP/BnUdyaPw08W2ZI5wKZozuuQIXrCJQpK9G5jsQcdw44no
aNpb0niYXHyffujthdObRcUzKeMra8SMRWtrOkuz2fDyQgabshlFSbCtuH5uFzX0
SMQ62ABX2fPvPx9B78DR
=4riF
-END PGP SIGNATURE-

Re: Packaging of static libraries

[Jakub Wilk]

* Jakub Wilk <jw...@debian.org>, 2016-04-14, 18:06:
It would be helpful if we could check if a dynamic binary is linked to 
a static library from another package; but I'm not aware of any 
reliable method to implement such check.


Maybe we could exploit the fact that static libraries are normally 
stripped, unlike the freshly built code. So if there's large amount of 
code that doesn't have corresponding debugging information in the 
-dbgsym package, it might be because the binary is linked to a static 
library.


--
Jakub Wilk

Re: Bug#822221: ITP: flipcoin -- flip an adjustable coin for random exit status

[Jakub Wilk]

* Anthony DeRobertis , 2016-04-22, 09:09:

memset(, 0xff, sizeof(maxInt));

"maxInt = -1" is would be a more obvious way to write it, IMHO.

Both pale in comparison to UINT32_MAX, also found in .


Meh. The advantage of the existing code is that it doesn't repeat the 
size of valInt/maxInt anywhere. If you were going to give op on this 
nice property, you might as well get rid of maxInt completely, and 
instead of:


((double) maxInt)+1.0

write:

0x1P32

Re: Bug#822221: ITP: flipcoin -- flip an adjustable coin for random exit status

[Jakub Wilk]

Hi Rudi!

[When filing a bug, please use X-Debbugs-CC instead of plain CC, so that 
the copied person (or list) receives the message with bug number from 
the BTS.]


* Rudi Cilibrasi <cilib...@alumni.caltech.edu>, 2016-04-21, 23:11:

* Package name: flipcoin
 Version : 1.0.0
 Upstream Author : Rudi Cilibrasi <cilib...@alumni.caltech.edu>
* URL : https://github.com/rudi-cilibrasi/flipcoin


Um, this page says "0 releases". Has 1.0.0 actually been released?

I'm an enthusiast of small programs that do one thing well. But I'd 
expect a program which is that short to be perfectly polished, and this 
one is not. Here's my review of this code:



 if (argc > 1)
   probability = atof(argv[1]);


No error handling... I'd expect to see an error message when the 
probability cannot be parsed, or it is out of range would be helpful, or 
there are too many arguments.



 memset(, 0xff, sizeof(maxInt));


"maxInt = -1" is would be a more obvious way to write it, IMHO.


 fp = fopen("/dev/urandom", "rb");
 if (fp == NULL) {
   fprintf(stderr, "Error: Cannot open /dev/urandom.\n");


The error message doesn't say what the error was, or what program 
caused this error.



   exit(2);


This exit code should be documented in the manpage.


 if (fread(, 1, sizeof(valInt), fp) != sizeof(valInt)) {
   fprintf(stderr, "Error: Cannot read from /dev/urandom.\n");
   exit(2);


Same problems are above.


 return ((probability * ((double) maxInt)+1.0) < valInt);


This is off-by-one, making the return value slightly biased towards 0.

Both COPYING and LICENSE exist and they are identical. Surely one would 
be enough? :-)


There is no test suite...

All in all, I don't think this is mature enough to be uploaded to Debian 
at this time.


--
Jakub Wilk

Re: Packaging of static libraries

[Jakub Wilk]

* Milan Kupcevic <mi...@debian.org>, 2016-04-10, 20:34:
We should change policy and packaging tools such that static 
linking are not enabled by default and only enabled when there is a 
good reason to do so; when requested by users or when there is some 
other

No, we should not.

+1

A lintian check should suffice.

Lintian check for what?



In the context of discussion and Paul's proposal[0][1] lintian check 
for statically linked binaries in Debian packages should suffice. If 
the one we've got[2] is deficient then we should look into it and 
figure out how to fix it.



[...]


[0] https://lists.debian.org/debian-devel/2016/04/msg00210.html
[1] https://wiki.debian.org/StaticLinking
[2] https://lintian.debian.org/tags/statically-linked-binary.html


I wouldn't call the check deficient, but I don't think it does what 
you'd want it to do.


statically-linked-binary is emitted only when the binary is not linked 
to any shared libraries (not even libc).


It would be helpful if we could check if an dynamic binary is linked to 
a static library from another package; but I'm not aware of any reliable 
method to implement such check.


--
Jakub Wilk

Re: Debian policy recommended snippet prevents building packages from external Makefile

[Jakub Wilk]

* Emmanuel Kasper <e.kas...@proxmox.com>, 2016-04-14, 13:29:

in the Debian policy 4.9.1 we recommend to add build flags as such:

MAKEFLAGS += -j$(NUMJOBS)

and I guess most packages, like tar,  will then call

$(MAKE) $(MAKEFLAGS)


You don't need to pass $(MAKEFLAGS) here.

And, as you noticed, you shouldn't, because it's not always suitable as 
arguments for make.


--
Jakub Wilk

Re: Opt out style recommends

[Jakub Wilk]

* Ben Hutchings <b...@decadent.org.uk>, 2016-04-11, 02:22:
Would it be useful to have a linker option to omit a NEEDED entry for a 
particular library?  The application could then call 
dlopen("libfoo.so.42", RTLD_NOW|RTLD_GLOBAL) before it starts using the 
library, typically right before calling foo_init(), but it wouldn't 
need to use dlsym().  However this would absolutely depend on lazy 
binding, i.e. the application would break if LD_BIND_NOW was set.


It's kinda possible already: just remove -lfoo from the linker command 
line (and add -Wl,--unresolved-symbols=ignore-all if you're building an 
executable). The downside is that the unresolved symbols will be 
unversioned, and that you have to hardcode soname in the code... which 
means it'll all explode sooner or later.


--
Jakub Wilk

Re: Packaging of static libraries

[Jakub Wilk]

* Milan Kupcevic <mi...@debian.org>, 2016-04-10, 16:51:
We should change policy and packaging tools such that static linking 
are not enabled by default and only enabled when there is a good 
reason to do so; when requested by users or when there is some other

No, we should not.


+1

A lintian check should suffice.


Lintian check for what?

--
Jakub Wilk

Re: Priorities overrides? Extra?

[Jakub Wilk]

* Ole Streicher <oleb...@debian.org>, 2016-04-10, 14:22:

When I look into the "overrides" file for debian stretch:

http://ftp.debian.org/debian/indices/override.stretch.main.gz

I find there more than 48.000 overrides; which means that almost *all* 
packages are overridden.


Exactly _all_ binary packages are in the override file.

That doesn't mean that that every single package had their priority or 
section actually changed.


--
Jakub Wilk

Re: -flto to become more of a routine - any change in opinion since 2011?

[Jakub Wilk]

* Steffen Möller <steffen_moel...@gmx.de>, 2016-03-29, 16:27:
I admit to be a fan of link time optimisation and would like to see 
this challenge promoted towards more of a routine challenge to 
establish for our packages.


gcc-5 manpage says: "Link-time optimization does not work well with 
generation of debugging information. Combining -flto with -g is 
currently experimental and expected to produce unexpected results."


Um... Automatic debug packages or LTO, choose one?

--
Jakub Wilk

Accepted openinbrowser 1.17-1 (source) into unstable

[Jakub Wilk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 23 Mar 2016 22:31:35 +0100
Source: openinbrowser
Binary: xul-ext-openinbrowser
Architecture: source
Version: 1.17-1
Distribution: unstable
Urgency: low
Maintainer: Jakub Wilk <jw...@debian.org>
Changed-By: Jakub Wilk <jw...@debian.org>
Description:
 xul-ext-openinbrowser - open files directly in the browser
Changes:
 openinbrowser (1.17-1) unstable; urgency=low
 .
   * New upstream release.
 + Remove dependency on FUEL (Firefox User Extension Library),
   which was removed in Firefox 47.
   * Bump standards version to 3.9.7 (no changes needed).
Checksums-Sha1:
 b7b4dcbbc9addc60bf1284cd78aeaad99291ecbd 1792 openinbrowser_1.17-1.dsc
 12bbd449824f67b45af410d1e87372c6fdba79de 15370 openinbrowser_1.17.orig.tar.gz
 fc7ef789da88ac0a71fb4eedbf22ea4a5a1fb047 11992 
openinbrowser_1.17-1.debian.tar.gz
Checksums-Sha256:
 2d2c754b41c4bf65a10c902991759e5fec7dbcab294c42c38befe5f347794eeb 1792 
openinbrowser_1.17-1.dsc
 43139901786f459367c774ca18ec08dd7b805628d3d0588a003e82f1145520a2 15370 
openinbrowser_1.17.orig.tar.gz
 33363e6f84de04350284f385d1e0a64c3e765ae6a76f077bbd6b07481569c266 11992 
openinbrowser_1.17-1.debian.tar.gz
Files:
 30ed4cd2d0882796cccdbed06c097b46 1792 web optional openinbrowser_1.17-1.dsc
 86b892f1020ab1bec3a8a8319c3ebb7f 15370 web optional 
openinbrowser_1.17.orig.tar.gz
 c84bc14baee9597561ca02daf1777a61 11992 web optional 
openinbrowser_1.17-1.debian.tar.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJW8wzcAAoJEC1Os6YBVHX10M8P/R9sE+NZCvdTXrRs+ZAxAIBl
O52AgStDCXUxICb6WNHtaVfNeEclo81zPy+fTpnoK4z6s+4NrvasnOTr+w1bUF1Z
nmTCzV8nGj/Isdw0h1yc2U4d99CvHl7BLAY2ZD83YzUclsioOuhEpMU2svk5KbK6
Tqdw09+G84nYet7IQKbzNqvIFH8Chb3BoKFwfEHWHpYVmMkdugZGdLMtPcH8OMPN
HjG7DDqAOrp4bPuTUK1DFrqB1JO/WQ3iQ57HoQmVZ7RH7WnAbvf617YeNkKSY75j
aULD7Kk5dNFK9THjGsVJd/ij9YmK4HJemgP8v3Y9se88bzIhf8oZPlLfZRekigk3
PMLt2ZZVo0G4sPgEKsYU93Pjk53/CJHCi6v8D5doRPcnYiCNt8gKmgmOJviRcPPm
PCJDBmvJa8cQTSQV3xmDGu46P0wAAo2Q41FBvMRX9+/9lmssT/y0TeovldwC/BVv
EAnsjCBCHaVPYZf+Iv6fvDlV8D56r1RCKJI9afKFXoJnDxXvI3g7y+4R+3kQzWt1
7NKI7H3akqK0zRVGoEw5XvuG2DAuz3i3GsDthnBTHQK3+upyVhqe9DiddwGyLtNd
LRS8Opa/s9uybJadlrI9Nf6ivLCncn2uNm98FF/YP25a1P9LRM6Ht4xDSqLOxNFy
y5NCGLrXtTJdZG/LlqD3
=ga/W
-END PGP SIGNATURE-

Re: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr

[Jakub Wilk]

* Colin Watson <cjwat...@debian.org>, 2016-03-22, 00:58:
[1]. There's probably some method that puts way less load on the BTS 
server available for DDs.


https://www.debian.org/Bugs/Access documents rsync access for this kind 
of thing.


Or you could mine debian-bugs-dist archives:
master.debian.org:/home/debian/lists/debian-bugs-dist

--
Jakub Wilk

Re: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr

[Jakub Wilk]

Can someone explain why we are bringing Firefox back? Are we going to 
rename it again if^Wwhen Mozilla stops liking us?


Also, why there are two firefox* packages, and what's the difference 
between them? (They have identical descriptions...)


* Josh Triplett <j...@joshtriplett.org>, 2016-03-18, 15:06:
Firefox addon packages (xul-ext-*) typically have a Depends on 
iceweasel, sometimes with alternatives for icedove or other supported 
packages that can use the addon.  With the switch to firefox and 
firefox-esr, iceweasel has become a transitional package depending on 
firefox-esr.  The dependencies of these addon packages prevent 
installing only the firefox package and removing firefox-esr and the 
transitional iceweasel package.


So let's fix Depends of the transitional package. No MBF is needed.

--
Jakub Wilk

HTTPS in DEP-5

[Jakub Wilk]

The machine-readable debian/copyright file specification says that the 
Format field should contain:


http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

These days www.debian.org supports HTTPS+HSTS (thanks, DSA!). Apparently 
this prompted some people to replace "http" with "https" in their Format 
field, contrary to the requirements of the specification.


Worse, some tools (Lintian, mk-origtargz) incorrectly say that the HTTPS 
URL is the one you should use in the Format field. Also, some tools 
(dh-make, Config::Model) produce copyright files with the HTTPS URL 
inside.


Some DEP-5 consumers recognize the HTTPS URL (Lintian, mk-origtargz, 
Config::Model, python-debian, license-reconcile), but others don't 
(adequate, umegaya).


So, what we're going to do about it? I see the following options:

A) Make Lintian complain about the HTTPS URL; fix 
HTTPS-advertising and HTTPS-producing tools, and >400 copyright files.


B) Fix the spec to allow the HTTPS URL; fix the HTTP-only consumers.

C) Admit that file formats are too hard and go shopping.

--
Jakub Wilk

Re: Bug#815675: ITP: ftpbackup -- Script to backups your data from a Debian system to a ftp space

[Jakub Wilk]

* Brian May <b...@debian.org>, 2016-02-25, 08:14:

I haven't seen the code myself, however one of the comments was:

 "just having whitespace in the destination directory will lead to a
 crash, set -e is not used, and errors are redirected to /dev/null"

This sounds to me like a recipe for security problems.


I wouldn't worry about whitespace in destination directory. If the 
attacker can control were backups go, we have a bigger problem...


But the bug density of this code is astounding:


ARCHIVE=$BACKUPHOME/$SERVER-backup-`date +%d-%m-%Y`.tar.gz


Eww, little-endian dates.
https://xkcd.com/1179/


# create BACKUPHOME if not exists
mkdir -p $BACKUPHOME


No umask set anywhere in this script, so in default setup the directory 
(and later, the backup files) will be created readable to anyone.



dpkg --get-selections| awk -F' ' '{print $1}' > $PKGLIST
RETVAL=$?
if [[ $RETVAL != 0 ]]; then
   echo "Issue while performing dpkg --get-selections of $SERVER" | mail -s 
"Issue while performing dpkg get selections of $SERVER" $ADMINEMAIL


Contrary to what the error message suggests, this catches only errors 
from awk, not from dpkg.



tar --preserve-permissions -z -c -f $ARCHIVE  \
   --exclude=/var/lib/mysql/data \
   --exclude=$BACKUPHOME/$SERVER-backup* \
   --exclude=/var/log \
   --exclude=/var/cache/apt/archives \
   $EXCLUDES \
   /etc /var /home /opt /usr/local/bin  > /dev/null 2>&1


What about /srv? Errors are hidden and ignored.


# remove old archive on the FTP
lftp -e "set ftp:ssl-allow no; 


Not only this program lets the backups be sent over unencrypted channel, 
but it even disables opportunistic TLS.



rm -f $SERVER-backup-`date -d "-$RETENTION day" +%d-%m-%Y`.tar.bz2;exit" -u 
$FTPUSER,$FTPPASS $FTPSERVER > /dev/null 2>&1


This removal feature seems to work correctly only if you run backups 
every day, and never close to midnight.


Wait, no, it doesn't work at all: the script creates .tar.gz, but then 
it tries to delete .tar.bz2.


[Gratitude for the review would be best expressed by requesting removal 
of this package from the archive.]


--
Jakub Wilk

Re: Bug#815675: ITP: ftpbackup -- Script to backups your data from a Debian system to a ftp space

[Jakub Wilk]

* Jonathan Dowland <j...@debian.org>, 2016-02-24, 13:52:
- The script makes the job for me. It is simple, dead simple and suits 
a usecase , my use case, and, moreover, it is a really early release. 
Buggy? It's not perfect, It does not pretend to. But it will improve, 
as any other free software project.


I can see it being useful, to you, for your script to be packaged in 
Debian. What I can't see is it being useful for Debian.


I can't see it either.

To avoid unpleasant situations like this, I recommend to never combine 
roles of upstream and Debian maintainer.


If you wrote something cool, instead of uploading it to ftp-master, 
write a blog post about it. If it's really as awesome as you think it 
is, somebody else will package it for Debian.


--
Jakub Wilk

Re: upstream_version not starting with a digit (was: Re: How to change config script for multiarch?)

[Jakub Wilk]

* Johannes Schauer <jo...@debian.org>, 2016-02-12, 13:41:

dpkg-buildpackage: warning: debian/changelog(l1): version '0:jessie' is 
invalid: version number does not start with digit
LINE: name (0:jessie) unstable; urgency=medium

According to the following regex over my Sources there seems to be no 
source package with an upstream_version part that does not start with a 
digit:


sed -ne 's/^Version: \([0-9]\+:\)\?[^0-9]//p'

So maybe policy should be adjusted to reflect reality?


Yes. #620566 used to be a policy bug about it, but then someone 
unhelpfully reassigned it to dpkg...


--
Jakub Wilk

Re: How to change config script for multiarch?

[Jakub Wilk]

* Johannes Schauer <jo...@debian.org>, 2016-02-10, 11:09:
I am a maintainer of chasen package. It contains chasen-config, it 
work as pkg-config like but it's a single script.


Latest lintain reports:
E: libchasen-dev: old-style-config-script-multiarch-path usr/bin/chasen-config 
full text contains architecture specific dir x86_64-linux-gnu

But I want to keep libchasen-dev as Multi-Arch: same. Would you tell 
me finding the correct way to change the script?

[...]
The old-style-config-script tag which src:chasen suffers from as well 
and which was also linked to by Bastien contains more valuable 
information. The important message is: please use pkg-config and not 
some package-specific configuration mechanism (as also already pointed 
out by Vincent). Otherwise, you (and/or upstream) will suffer from an 
unnecessary maintenance burden in case you ever want to (or in case we 
need to) cross-build that source package. For now though it should be 
sufficient to move the file into an architecture specific path.


Um, no. Replacing an upstream-supported API, which has existing users 
even in the Debian archive, with a Debian-specific non-upstreamable one 
sounds like a very bad plan to me.


--
Jakub Wilk

Re: How to change config script for multiarch?

[Jakub Wilk]

* NOKUBI Takatsugu <k...@daionet.gr.jp>, 2016-02-12, 08:27:

Jakub Wilk wrote:
Are you trying to move the script to libchasen-dev? Why? There are 
Debian maintainer scripts that use chasen-config. Are they going to 
depend on the -dev package?


Yes, now I will move the script into libchasen-dev because it seems 
make sense, chasen-config is not related with chasen dictionaries.


I don't know much about this package, but codesearch.d.n tells me that 
all users of chasen-config call it with the --mkchadic option, which 
causes the script to print /usr/lib//chasen/, which is a 
directory shipped by chasen-config. So it's not completely unrelated...


And, as it turns out, the implementation of --mkchadic is the only part 
of the config script that uses the multi-arch triplet in a way that 
can't be trivially patched-out. (The only other place where the triplet 
is used is --libs, where the script prints "-L${prefix}/lib/"; 
but this -L is a no-op that can be removed.)


--
Jakub Wilk

Re: How to change config script for multiarch?

[Jakub Wilk]

* NOKUBI Takatsugu <k...@daionet.gr.jp>, 2016-02-10, 16:12:
I am a maintainer of chasen package. It contains chasen-config, it work 
as pkg-config like but it's a single script.


Latest lintain reports:
E: libchasen-dev: old-style-config-script-multiarch-path usr/bin/chasen-config 
full text contains architecture specific dir x86_64-linux-gnu


There is no chasen-config in the latest version of libchasen-dev 
(2.4.5-21).


chasen-config is currently shipped in chasen-dictutils, for which 
Lintian incorrectly emits this tag. This will be fixed in the next 
Lintian release.


Are you trying to move the script to libchasen-dev? Why? There are 
Debian maintainer scripts that use chasen-config. Are they going to 
depend on the -dev package?


But I want to keep libchasen-dev as Multi-Arch: same. Would you tell me 
finding the correct way to change the script?


It's hard to give a concrete answer without seeing the package you're 
working with; or at least without explanation how exactly it differs 
from the package in the archive.


--
Jakub Wilk

Re: bugs in bootstrap.debian.net (was: Re: The state of cross building)

[Jakub Wilk]

* Helmut Grohne <hel...@subdivi.de>, 2016-02-03, 06:17:
I see that there is now a lintian check for this issue whcih is great, 
and gives us some idea of how big it is:

https://lintian.debian.org/tags/old-style-config-script-multiarch-path.html

So that lists 240 packages which are MA:same and also contain an 
arch-specific foo-config script.


The assumption that the tag would only hit MA:same packages is wrong. 
It hits e.g. libgpg-error-dev, which is correctly not marked MA:same. 
In defense, this tag is very young and correctly marked with with low 
confidence.


The intention was to check only MA:same and MA:foreign packages (and 
arch:all packages, but that's a separate tag), but because of a bug 
MA-less packages are checked too. This will be fixed in the next Lintian 
release.


--
Jakub Wilk

Re: bugs in bootstrap.debian.net (was: Re: The state of cross building)

[Jakub Wilk]

* Johannes Schauer <jo...@debian.org>, 2016-01-31, 15:27:

libmagickcore-dev is multiarch:foreign


This is surely a bug.

libmagickcore-dev is a transitional package for libmagickcore-6.q16-dev, 
which is MA:same, so its interfaces are very much architecture 
dependent.


--
Jakub Wilk

Re: mkdocs locale error building djangorestframework

[Jakub Wilk]

* Julien Cristau <jcris...@debian.org>, 2016-01-28, 14:01:

import subprocess
rv = subprocess.Popen(['locale', '-a'], stdout=subprocess.PIPE,

...   stderr=subprocess.PIPE).communicate()[0]

type(rv)




For Python 3, try adding `universal_newlines=True` to any subprocess 
call. You'll get back a str.



Or a UnicodeDecodeError.


Avoid French and Norwegian locales and you're be good. :-P
Or upgrade to glibc 0.22, which guarantees that "locale -a" output is 
ASCII-only:

https://sourceware.org/bugzilla/show_bug.cgi?id=18412

--
Jakub Wilk

Re: Better Lintian checks

[Jakub Wilk]

* Sebastiaan Couwenberg <sebas...@xs4all.nl>, 2016-01-26, 07:45:

The use of Multi-Arch: no was suggested by

https://lintian.debian.org/tags/old-style-config-script-multiarch-path.html


The wording is unfortunate.

You should not add "Multi-Arch: no" to the control file, but instead 
remove the field, because "no" is the default.


And most of the time changing multi-archness isn't the correct course of 
action anyway...



The reject message


Quoting the reject message would have been helpful...
I guess you're referring to this:
https://anonscm.debian.org/cgit/mirror/dak.git/tree/daklib/checks.py?id=c51e71bbd9c2#n392

refers to #768353 which was fixed in November 2014, 
but the fix is most likely not available in stable yet,


The version graph says it's fixed in "dose3/3.3~beta1-3 (stable)".

--
Jakub Wilk

Re: Better Lintian checks

[Jakub Wilk]

* Bas Couwenberg <sebas...@xs4all.nl>, 2016-01-26, 12:17:

The use of Multi-Arch: no was suggested by

https://lintian.debian.org/tags/old-style-config-script-multiarch-path.html


The wording is unfortunate.

You should not add "Multi-Arch: no" to the control file, but instead 
remove the field, because "no" is the default.


The gdal package didn't have any Multi-Arch control fields.


This will be fixed in the next Lintian release:
https://anonscm.debian.org/cgit/lintian/lintian.git/commit/?id=20ad1f7fbe12

In the mean time, please add an override for the tag.

--
Jakub Wilk

Re: Packages with /outdated/ packaging style

[Jakub Wilk]

* Andreas Tille <andr...@an3as.eu>, 2016-01-19, 20:04:
Just for the record: I'm currently touching all those packages 
maintained by Debian Med and not uploaded for >3 years.  Some last 
remainings of dh5 were removed and some other issues solved.  I admit 
all of these "long time not uploaded" packages had some issues that 
rectify a new upload.  IMHO also debian/compat < 9 is another good 
reason since automatic build time testing is not done if existing.


I don't know what you mean by dh5, but I'm pretty sure there was no 
change regarding "automatic build time testing" in compat 9.


--
Jakub Wilk

Accepted adequate 0.15.1 (source) into unstable

[Jakub Wilk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 12 Jan 2016 15:34:17 +0100
Source: adequate
Binary: adequate
Architecture: source
Version: 0.15.1
Distribution: unstable
Urgency: low
Maintainer: Jakub Wilk <jw...@debian.org>
Changed-By: Jakub Wilk <jw...@debian.org>
Description:
 adequate   - Debian package quality testing tool
Changes:
 adequate (0.15.1) unstable; urgency=low
 .
   * Fix false positive program-name-collision in less.
   * Use date of last modification in the manual page footer.
 This should help to make the package builds reproducible.
   * Fix typo in a tag description.
   * Add license information for libpoppler.so.57.
Checksums-Sha1:
 e8483d941d00f6f5add752e82d684b86312bf9ff 1603 adequate_0.15.1.dsc
 bc45ea0f07c7120b9ff7d03e9d6d7fde848fcb1e 32097 adequate_0.15.1.tar.gz
Checksums-Sha256:
 a3dcc544b99a838ecf2a124cb1e9fa35c8667fb18c438594e49dc49bb1715503 1603 
adequate_0.15.1.dsc
 4876c6b394baec450382bdcd9eaeb1319736b252b30f710d7f2f91269bf3e79d 32097 
adequate_0.15.1.tar.gz
Files:
 41a60043a4c86f9575530398a9cde67f 1603 utils optional adequate_0.15.1.dsc
 06fb10f946394ffd023fd33d542f447a 32097 utils optional adequate_0.15.1.tar.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWlRBuAAoJEC1Os6YBVHX1TEcP/jbhMtsSGx+g619YyPKyH+vA
HBXX/be9hCnTVCB3h9shfIWRE3PSNUDtiooUo6zxPuQa7i4VmbX0+BGgAbe6W5ZP
tfCKMCcwxj7oZzpf9Z1Qny4KI0CJLlbWTCHm/QlVQWAoL5VGBT5lY4Qy4W6nF4kl
/v0P9l/WGbfjIst7NYcAZ8kg/d0DuLnVJmgBEOlQOqO4vIHS4H/RIRuMPYHKGH9p
Oy3KOhW+XbBJwHPRpi308BPisOusz36JLJjIAumTCvCrG+NthJVJp/TheYMi3fgP
fRsSyHaoCZov6EFUITt6pB8QaQW0/SWN1NTfVaBbjBx0LGR+f6mTetjazp95ab3B
R2UFY6wMeuORWbPAqB+RnwHOCb7bGBhqfMVb4E3XwbwhY1kEsj+vN6/Hn83hKdNt
zy5kH7KaDOx20Q6dcRn2U9pEdVQs3WHUn/NYxE3ZywKPJbjbj57wOlFtkfNvR0o9
al78JmOVshToIY31AglO1PWazTL7Li8mqOwV0zNBqkDPWx5FXiRo3bs2y8THIET3
vHkyVWpJ9hiHgPtkPNg5j7gWIZNiW0H4MMM3vcF85M3t77nucbA3vHePKkJ2jJWP
QWKMzPQqZSTuE1EdwLZ8ftGM8UEuCgcLktx9RAMNaJ/HnOG59RYxmeNmUbiIcBuE
IC4afkgp1rBoaVfmd4jT
=/t5i
-END PGP SIGNATURE-

Re: support for merged /usr in Debian

[Jakub Wilk]

* Paul Wise <p...@debian.org>, 2016-01-05, 17:49:
And yet, it works, and it means that we don't have to try to harass a 
thousand package maintainers into doing essentially untestable 
busy-work to try to move things around between /usr, /bin, and /lib to 
support a tiny handful of systems for which other approaches are 
available.


The bin-or-sbin-binary-requires-usr-lib-library tag in adequate tests 
this. piuparts runs adequate for every single package in Debian.


https://piuparts.debian.org/sid/bin_or_sbin_binary_requires_usr_lib_library_inadequate_issue.html

--
Jakub Wilk

Re: MBF Announcement: Transition libpng12 -> libpng16

[Jakub Wilk]

* Tobias Frost <t...@debian.org>, 2016-01-04, 12:02:
Logs from the rebuild can be found here: http://libpng.sviech.de, as 
well as a scratchpad with a short analysis: 

https://titanpad.com/libpng16-transistion


Plain-text version for people who don't enjoy running non-free JS code:
https://titanpad.com/ep/pad/export/libpng16-transistion/latest


Currently we are preparing the transistion of libpng1.2 to libpng1.6.


s/transistion/transition/ (here and in other places)


been done. The result with buildlogs can be found here: https://libpng.
sviech.de/


URLs work better when they're not line-wrapped. :)


The Titanpad at https://titanpad.com/libpng16-transistion might gives y
ou clues about what went wrong as well as contains some


s/gives/give/
s/y\nou/you/

--
Jakub Wilk

Re: Orhpaned packages: imms, lwatch, rrdcollect

[Jakub Wilk]

* Artur R. Czechowski <artu...@hell.pl>, 2015-12-28, 16:17:

- rrdcollect http://bugs.debian.org/809234


ITYM #809235

--
Jakub Wilk

Re: Bug#809014: ITP: chewing-editor -- libchewing user phrase editor

[Jakub Wilk]

* ChangZhuo Chen (陳昌倬) <czc...@debian.org>, 2015-12-27, 13:38:

chewing-editor is a cross platform user dictionary edtiro for chewing


Typo: edtiro -> editor

--
Jakub Wilk

Re: Bug#808767: ITP: apt-transport-gs -- APT transport for repositories privately held on GCS

[Jakub Wilk]

* Marcin Kulisz (kuLa) <deb...@kulisz.net>, 2015-12-22, 16:07:

* Package name: apt-transport-gs


s/gs/gcs/ ?

--
Jakub Wilk

Re: Can I suppress automatic creation of -dbgsym packages?

[Jakub Wilk]

* Paul Wise <p...@debian.org>, 2015-12-22, 18:19:

On Tue, Dec 22, 2015 at 6:13 PM, Andreas Tille wrote:

I admit I would really like to safe bandwidth - I seem to have missed 
the source-only upload option.  Could you provide a pointer.  This 
would be even cooler than the dbgsym feature. ;-)


They were on d-d-a last year (arch any) and this year (arch all):

https://lists.debian.org/debian-devel-announce/2014/08/msg2.html
https://lists.debian.org/debian-devel-announce/2015/08/msg7.html


Reminder: Every person who was caught not reading d-d-a carefully is 
obliged to fix 42 RC bugs.


--
Jakub Wilk

Re: Bug#807868: ITP: zjump -- Jump to frequent directories matching regex

[Jakub Wilk]

* Thomas Ross <thomasr...@thomasross.io>, 2015-12-13, 16:57:
The package should actually be called 'Z', but according to reportbug 
that is not a valid package name.


reportbug is right. As per Policy §5.6.1, package names “must be at 
least two characters long”.



Are there any suggestions for this?


My suggestion is to ask upstream about their preference in alternative 
names for "z".


--
Jakub Wilk

Re: Bug#807868: ITP: zjump -- Jump to frequent directories matching regex

[Jakub Wilk]

* Osamu Aoki <os...@debian.org>, 2015-12-14, 21:36:
The package should actually be called 'Z', but according to reportbug 
hat is not a valid package name.


reportbug is right. As per Policy §5.6.1, package names “must be at 
least two characters long”.



Are there any suggestions for this?


My suggestion is to ask upstream about their preference in alternative 
names for "z".


Yes.  That's the best thing to do.

Or at least, install its binary and manpage in some other name such as 
rupa-z or zjump.  And add suggestion to make a short alias such as "z" 
which does not conflict on the machine in its manpage and README.


I'm confused. There is no file conflict here, so I see no reason to 
rename the program or its manpage.


We do have to rename the package, but only because the use upstream uses 
is too short.


--
Jakub Wilk

Re: Bug#807956: ITP: doit -- unofficial DigitalOcean Interactive Tool

[Jakub Wilk]

* Daniel Stender <deb...@danielstender.com>, 2015-12-14, 18:42:

* Package name: doit
 Version : 0.6.0
 Upstream Author : Bryan Liles <i...@smartic.us>
* URL : https://github.com/bryanl/doit


Unfortunately /usr/bin/doit already exists, provided by python-doit.

--
Jakub Wilk

Re: tracker.debian.org replaces packages.qa.debian.org for email subscriptions

[Jakub Wilk]

* Raphael Hertzog <hert...@debian.org>, 2015-12-09, 14:43:
How about adding a List-Id header (RFC 2919) there?  MUAs may have 
better user interfaces for splitting on List-Id's than other headers. 
Just an idea.


And we would use package name + service name as identifier?

This would then give this for dpkg:

 List-Id: 

I can add this if it's actually useful. Anyone seconding Simon's request?


Seconded.

--
Jakub Wilk

Re: Bug#807019: tracking bin-num - broken unison due to binnmu upload

[Jakub Wilk]

* Stéphane Glondu <glo...@debian.org>, 2015-12-07, 16:23:

* is there a way to track down who uploaded -3+b1?

For "who", I don't know.


BinNMU are usually scheduled by the Release Team.
This package was part of the ncurses transition:
https://release.debian.org/transitions/html/ncurses.html

But for "why", cf 
/usr/share/doc/unison2.40.102/changelog.Debian.amd64.gz:

unison2.40.102 (2.40.102-3+b1) sid; urgency=low, binary-only=yes

 * Binary-only non-maintainer upload for amd64; no source changes.
 * Rebuild against ncurses 6.0.

-- amd64 / i386 Build Daemon (babin) <buildd-ba...@buildd.debian.org>  Fri, 31 
Jul 2015 09:50:21 +0200


...which is strange, because unison doesn't use ncurses AFAICT.


Not on amd64, but it does link to ncurses on some other architectures. 
This is probably unintentional. For example, I see this in the mips 
build log[0]:


dpkg-shlibdeps: warning: package could avoid a useless dependency if 
debian/unison2.32.52/usr/bin/unison-2.32.52 was not linked against 
libncurses.so.5 (it uses none of the library's symbols)

Also, the date is misleading; it corresponds to the last sourceful 
upload, not the binNMU.


Looks like a fallout after #620112.
This change in sbuild should be reverted. It didn't fix binNMU 
co-installability, and made binMNU changelog entries less helpful.



[0] 
https://buildd.debian.org/status/fetch.php?pkg=unison2.32.52=mips=2.32.52-7%2Bb1=1449193180

--
Jakub Wilk

Re: Upcoming version of apt-file - using apt-acquire and incompatibilities

[Jakub Wilk]

* The Wanderer <wande...@fastmail.fm>, 2015-12-06, 08:50:
Er... the entire reason I started running 'apt-file update' in the 
first place is because running 'apt-get update' was not, or did not 
appear to be, updating the index which was used by apt-file.


Quick sanity check: do you have apt-file (>= 3) installed?
Because this is the package that ships the configuration file for 
APT that causes apt(-get) to download Contents-*.


--
Jakub Wilk

Re: Upcoming version of apt-file - using apt-acquire and incompatibilities

[Jakub Wilk]

* David Kalnischkies <da...@kalnischkies.de>, 2015-12-06, 13:01:
APT 1.1 is pretty clever in figuring out if a file was changed and for 
the 'giant' Contents files it actually benefitial to run the update 
more often as that means it can use the small PDiff files (a few KB 
each) to patch up a previous version of the file instead of downloading 
the entire file (~30 MB) again (as it would happen after ~2 weeks 
without an update)…


This works perfectly for binary packages' Contents, but (at least on my 
machine) APT downloads whole Contents-source every time.


There's clearly a bug somewhere (APT? dak?), but I don't have time to 
debug it further. I very rarely need Contents-source anyway, so I just 
disabled it in /etc/apt/apt.conf.d/50apt-file.conf.


--
Jakub Wilk