Re: Bug#995189: RFH: isc-dhcp

[Philipp Hahn]

Hello Santiago,

Am 08.03.23 um 11:17 schrieb Santiago Ruano Rincón:

El 08/03/23 a las 10:45, Philipp Hahn escribió:

Am 07.03.23 um 20:26 schrieb Ansgar:

On Tue, 2023-03-07 at 11:55 +0100, Marco d'Itri wrote:

On Mar 07, Philipp Hahn  wrote:

Is it a good idea to keep it alive for another 2+ years in
Debian-12-Bookworm or should it be removed now?
https://packages.debian.org/source/bookworm/isc-dhcp


I do not think that it should be removed at this point, since there is
a need for the complex features that isc-dhcpd can provide and there are
is no obvious replacement: Kea is super complex (and I do not know if it
has all the features) and everything else is too much simple.


Only the client and relay are no longer maintained upstream. The server
is still maintained and there is no need to drop it from Debian.


Are you sure the *server* is still maintained? Sadly my quote from
<https://www.isc.org/dhcp/> got dropped, so here again:


 From README:

 RELEASE STATUS

Version 4.4.3-P1 is a maintenance release of the DHCP client, relay and
server. It is the final release for the client and relay components,
which have reached end-of-life and will no longer be maintained.


That does not help: they did a maintenance release in the past. So 
*past* issues were addressed. Excellent!

But what happens in the future? Will we get *future* updates:
- client: No, as officially EoL
- relay: No, as officially EoL
- server: through "providing professional support services"


ISC has announced the end of life for ISC DHCP as of the end of 2022. ISC will 
continue providing professional support services for existing subscribers, but 
does not intend to issue any further maintenance releases.


You can still read an equivalent sentence from the dhcp upstream url:

"DHCP is available for free download under the terms of the MPL 2.0
license. The client and relay portions of ISC DHCP are no longer
maintained."


Again does not help: I can even still download older releases with 
unfixed issues.
But I want to know if I should still base my environment/work on 
ISC-DHCP-server in the future, that is: Will it be maintained in the 
future and will we get patches for security issues?


Do you "Debian ISC DHCP Maintainers " have 
enough expertise and willingness to maintain it for another 2+ years 
("without" support from upstream ISC)?


Philipp

Re: Bug#995189: RFH: isc-dhcp

[Philipp Hahn]

Hello Ansgar,

Am 07.03.23 um 20:26 schrieb Ansgar:

On Tue, 2023-03-07 at 11:55 +0100, Marco d'Itri wrote:

On Mar 07, Philipp Hahn  wrote:

Is it a good idea to keep it alive for another 2+ years in
Debian-12-Bookworm or should it be removed now?
https://packages.debian.org/source/bookworm/isc-dhcp

>>

I do not think that it should be removed at this point, since there is
a need for the complex features that isc-dhcpd can provide and there are
is no obvious replacement: Kea is super complex (and I do not know if it
has all the features) and everything else is too much simple.


Only the client and relay are no longer maintained upstream. The server
is still maintained and there is no need to drop it from Debian.


Are you sure the *server* is still maintained? Sadly my quote from 
<https://www.isc.org/dhcp/> got dropped, so here again:



ISC has announced the end of life for ISC DHCP as of the end of 2022. ISC will 
continue providing professional support services for existing subscribers, but 
does not intend to issue any further maintenance releases.


Previously ISC announced EoL *only for client and relay*, but — at least 
for my reading of the above statement ­— they no longer do and *ended 
all of DHCP*. Or do we (Debian) have access to that "professional 
support services" to get future patches we can apply?


Do we do our users a service by keeping that dead horse alive for 
another 2+ years? While being quite stable it had a steady stream of 
security issues: 
<https://security-tracker.debian.org/tracker/source-package/isc-dhcp>


Philipp

Re: Bug#995189: RFH: isc-dhcp

[Philipp Hahn]

Hello,

Am 26.01.22 um 16:47 schrieb Bernhard Schmidt:

About the client and server, if I am not wrong, about 3 years ago ISC
dhcp was the only implementation able to configure DHCPv6 clients by
their MAC addresses (thing that I needed at work). It is a pity that ISC
is giving less love to it. That said, the EOL date is still TBA
(https://www.isc.org/dhcp/)


The EOL timeline has now been announced.

https://www.isc.org/blogs/dhcp-client-relay-eom/


ISC-DHCP is end-of-life since end-of-2022, both client, relay and server:


ISC has announced the end of life for ISC DHCP as of the end of 2022. ISC will 
continue providing professional support services for existing subscribers, but 
does not intend to issue any further maintenance releases.


Is it a good idea to keep it alive for another 2+ years in 
Debian-12-Bookworm or should it be removed now?

https://packages.debian.org/source/bookworm/isc-dhcp

Philipp

Re: Kernel building question (Is -j8 safe and correct?)

[Philipp Hahn]

Hello Anionio,

Am 12.06.21 um 03:34 schrieb Antonio Russo:

I'm trying to build a Debian bullseye kernel (with KASAN enabled, but that's 
irrelevant).
I'm following [1], and the critical command

$ fakeroot make -f debian/rules.gen binary-arch_i386_none_real

does not suggest using -j8 (or -jnumber_of_cores).

1. Is it safe to add -j8 ?


That depends on many factors, most importantly how many CPU cores your 
build host has and how many of them you want to use:
- if this is a single-user system and you're the only user and you don't 
want to do much in parallel: yes
- using all CPU cores on a multi-user system might get you complaints 
from the other users.
- watching videos while waiting for the compile to finish might be 
problematic.



2. Will this indeed give me the speed up I want and expect on my multi-core 
processor?


Probably yes, but see above. It also depends on how much RAM you have 
and how fast your disk/SSD is.



3. If both of the above are true, why isn't something like that suggested on 
[1]?


Debian does not know your specifics and thus does not use parallel build 
by default. You must give permissions first:


> export DEB_BUILD_OPTIONS="parallel=$(nproc)"

See 
.


For example the VMs and hosts of Debians build system are dedicated to 
building packages. They are controlled by the Debian admins and parallel 
building is enabled there by default - if applicable.
If you have to build many packages it might be more effective to build 
multiple source packages in parallel, as there are still packages which 
can only use one CPU. Mixing both strategies is also an option, but 
heavily depends on your usage scenario.


Philipp

Checksum-Sha{256,1} vs Files missing in DSC / Sources

[Philipp Hahn]

Hello,

While working on <https://bugs.debian.org/931729> in "apt-mirror" I
noticed a strange thing:

According to Debian Policy 4.5.0.3
<https://www.debian.org/doc/debian-policy/ch-controlfields.html#debian-source-control-files-dsc>
and <https://manpages.debian.org/testing/dpkg-dev/dsc.5.en.html>
"Files:" is still "mandatory, but reality looks different:

> $ curl -s 
> http://ftp.de.debian.org/debian/dists/buster-updates/main/source/Sources.xz | 
> xz -d | grep-dctrl -S tzdata
> Package: tzdata
> Binary: tzdata
> Version: 2019c-0+deb10u1
> Maintainer: GNU Libc Maintainers 
> Uploaders: Clint Adams , Aurelien Jarno 
> , Adam Conrad 
> Build-Depends: debhelper (>= 9)
> Build-Depends-Indep: po-debconf, rdfind, symlinks
> Architecture: all
> Standards-Version: 4.2.1
> Format: 3.0 (quilt)
> Vcs-Browser: https://salsa.debian.org/glibc-team/tzdata
> Vcs-Git: https://salsa.debian.org/glibc-team/tzdata.git
> Checksums-Sha256:
>  983c27d24d78c52d8f213b1b5800aaa90a171a4f805451b0845752f97c6f924b 2264 
> tzdata_2019c-0+deb10u1.dsc
>  79c7806dab09072308da0e3d22c37d3b245015a591891ea147d3b133b60ffc7c 392087 
> tzdata_2019c.orig.tar.gz
>  cd31deaeee229d45e4f4b973441189e7619ef81679359e9c8b47b2a87aaf6a07 833 
> tzdata_2019c.orig.tar.gz.asc
>  fa8071037767a7dfa054c26621c5079809ee038eddb32a58814faf3541d52d5a 104932 
> tzdata_2019c-0+deb10u1.debian.tar.xz
> Homepage: https://www.iana.org/time-zones
> Package-List: 
>  tzdata deb localization required arch=all
> Directory: pool/main/t/tzdata
> Priority: source
> Section: localization

(this is only one example; there are more entries where "Files:" is missing)

I remember a discussion to drop "Files:" in favor of "Checksum-Sha*",
but I'm unable to find the discussion and the conclusion again.

1. As "Files" is still mandatory can a mirror script assume the entry to
exist? (I already have a patch to try the Sha{1,256,512}, too)

2. If "Files" is still mandatory, why is it missing in the above entry?
Is there a bug in our build and/or mirror system?

Philipp
-- 
Philipp Hahn
Open Source Software Engineer

Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen

 +49-421-22232-57
 +49-421-22232-99

✉️ h...@univention.de
 https://www.univention.de/

Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876

From 2988f8d91dfbd97667be4224004deea85f888e66 Mon Sep 17 00:00:00 2001
Message-Id: 
<2988f8d91dfbd97667be4224004deea85f888e66.1601439012.git.h...@univention.de>
In-Reply-To: 

References: 

From: Philipp Hahn 
Date: Tue, 29 Sep 2020 12:40:43 +0200
Subject: Support SHA{1,256,512} for Sources too (closes #931729)

The real problem here is that process_index() assumes that "Files:" still used.
According to Debian Policy 4.5.0.3
<https://www.debian.org/doc/debian-policy/ch-controlfields.html#debian-source-control-files-dsc>
and <https://manpages.debian.org/testing/dpkg-dev/dsc.5.en.html> "Files:" is
still "mandatory, but reality looks different:

> $ curl -s 
> http://ftp.de.debian.org/debian/dists/buster-updates/main/source/Sources.xz | 
> xz -d | grep-dctrl -S tzdata
> Package: tzdata
...
> Version: 2019c-0+deb10u1
...
> Standards-Version: 4.2.1
...
> Checksums-Sha256:
>  983c27d24d78c52d8f213b1b5800aaa90a171a4f805451b0845752f97c6f924b 2264 
> tzdata_2019c-0+deb10u1.dsc
>  79c7806dab09072308da0e3d22c37d3b245015a591891ea147d3b133b60ffc7c 392087 
> tzdata_2019c.orig.tar.gz
>  cd31deaeee229d45e4f4b973441189e7619ef81679359e9c8b47b2a87aaf6a07 833 
> tzdata_2019c.orig.tar.gz.asc
>  fa8071037767a7dfa054c26621c5079809ee038eddb32a58814faf3541d52d5a 104932 
> tzdata_2019c-0+deb10u1.debian.tar.xz
...

As this example lacks the "Files:" entry, it is not mirrored by "apt-mirror".

The real fix is to try "Checksums-Sha256", "Checksum-Sha1" and "Files:" in that
order and use the first existing one.
---
 apt-mirror | 76 ++
 1 file changed, 48 insertions(+), 28 deletions(-)

diff --git a/apt-mirror b/apt-mirror
index 16c2118..5d81fcf 100755
--- a/apt-mirror
+++ b/apt-mirror
@@ -720,11 +720,21 @@ foreach ( keys %urls_to_download )
 
 %urls_to_download = ();
 
-open FILES_ALL, ">" . get_variable("var_path") . "/ALL" or die("apt-mirror: 
can't write to intermediate file (ALL)");
-open FILES_NEW, ">" . get_variable("var_path") . "/NEW" or die("apt-mirror: 
can't write to intermediate file (NEW)");
-open FILES_MD5, ">" . get_variable("var_path") . "/MD5" or die("apt-mirror: 
can't write to intermediate file (MD5)");
-open FILES_SHA1, ">" . ge

Preferred form of modification for binary data used in unit testing?

[Philipp Hahn]

Hi,

if a *previous* version of a software generated a *buggy* binary
database, that bug got fixed in a *newer* version and also some
*recovery* mechanism was added to allow reading that broken format
*once*, but there is no code the write the *broken* file again. For
*unit testing* the upstream developers added an *example* of such a
broken database to their test data.
What's the preferred form of modification for that data set?

* Should I include a copy of the *broken code* to generate that data?
* Declare that there in no preferred form for modification, as a
"open-save"-cycle with the current code will not re-create the bit
idencial file again.
* Remove the test data because it is not DFSG conformant and hope the
Debian build will never break the recovery code.
* Include instructions on how to re-build the broken version and give
instructions on how to maybe rebuild a similar broken file.

Philipp

PS: This question is motivated while working on a private build of
> E: keepassxc source: source-is-missing tests/data/keepassxc.opvault/default

Re: debdocker - A Debian docker-based personal builder

[Philipp Hahn]

Hello,

Am 27.06.20 um 12:08 schrieb Samo Pogačnik:
> I am preparing a packaging support tool similar to pbuilder, except that it 
> uses
> docker containers instead of chroot environments. The project is available 
> here:
> https://salsa.debian.org/spog/debdocker

There already is .

There also was this mail thread ~2018:


I think there also was a discussion to include Docker support into
sbuild, which would allow autopkgtest to use that interface.

 also list several other tools


So please clarify why we need yet another tool and what are the benefits
of your tool compared to the other ones already existing. Not only for
us Debian Developers, but also in the package description for all other
users looking for the right solution for their problem. Thanks.

Philipp

Accepted uftp 4.9.9-1 (source amd64) into unstable

[Philipp Hahn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 23 Feb 2019 08:24:52 +0100
Source: uftp
Binary: uftp uftp-dbgsym
Architecture: source amd64
Version: 4.9.9-1
Distribution: unstable
Urgency: low
Maintainer: Philipp Matthias Hahn 
Changed-By: Philipp Hahn 
Description:
 uftp   - Encrypted multicast file transfer program
Changes:
 uftp (4.9.9-1) unstable; urgency=low
 .
   * New upstream version 4,9,9
   * debian/control: Update standards version 4.3.0
Checksums-Sha1:
 6fece103af7f615ddc1ad769c903fa8fb2663f3f 1410 uftp_4.9.9-1.dsc
 d35f8a440f76037c0a0c7536a4a8a54b94b9e7b4 244995 uftp_4.9.9.orig.tar.gz
 3f6d3d9aead0649e82f572f875ca2cc5f786806e 10432 uftp_4.9.9-1.debian.tar.xz
 38fd4ebb758a2e866a8e580be70161d59dba2310 471568 uftp-dbgsym_4.9.9-1_amd64.deb
 f34bfdf1fe4a79e12b6e966c29361ecc3c55fbf8 5124 uftp_4.9.9-1_amd64.buildinfo
 f8c5dc1776de3d70c561270029c5486f1df59668 195860 uftp_4.9.9-1_amd64.deb
Checksums-Sha256:
 5cd2aecd5b4413689e8611813dd2b190cc8143c42cde048665797b5c89e593b8 1410 
uftp_4.9.9-1.dsc
 c04bc75a88fc3d57504269f260be4d0b1bc440508b5a5ca587df6c16b771aa48 244995 
uftp_4.9.9.orig.tar.gz
 b22f529a7d60ae5249ee2b8805927ab95e7b325cd9395cef036351b84d46c8c6 10432 
uftp_4.9.9-1.debian.tar.xz
 eacf5143c7628a5f954b1988fb905b7fdafc8b464acda534aa171ff6fa5f822b 471568 
uftp-dbgsym_4.9.9-1_amd64.deb
 13b002d6194ce48ba102616d1d9258f5287ddc3c9d146506eb4db06cd02269d7 5124 
uftp_4.9.9-1_amd64.buildinfo
 2789cfc303d8a24fc157ab84db8d848a032248198c5fbe28ac097e926bfcfe1d 195860 
uftp_4.9.9-1_amd64.deb
Files:
 5583fc3a63ae6308a75aca8f51769982 1410 net optional uftp_4.9.9-1.dsc
 154e2c82a33fd4999040f8836e2dca2c 244995 net optional uftp_4.9.9.orig.tar.gz
 d0a0da6474528ff2b8f7ac7526bd2590 10432 net optional uftp_4.9.9-1.debian.tar.xz
 58cb9efb724ba7b1abd34ab698e8d201 471568 debug optional 
uftp-dbgsym_4.9.9-1_amd64.deb
 5ba93656fb765536a0d665017e5332fe 5124 net optional uftp_4.9.9-1_amd64.buildinfo
 6b79b2e290cd9a403f7a0bf9fa72bfe2 195860 net optional uftp_4.9.9-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQFGBAEBCAAwFiEEOWzwba1g1HA0AqaYNC0GU9GsrNsFAlxw+kISHHBtaGFobkBk
ZWJpYW4ub3JnAAoJEDQtBlPRrKzb6ckH/i5NpXqKzK2onTDIs2PR4l03Rhz2SZAZ
Gvk8Ujwu2xXnNJ7Xj+lCBJqsAJWrAP8tqYsXr6oKEo0AoDQoxz9WHjk2L6O8NKFs
MclHN/nB+gVJWf1+eGkVYLdcBmqKyoTmfP8aH5MBymUB4XBXHtLabeiB5Vp1rldC
iLhSU3npt6jT5aUa10arFVDwl4ZTNPvhT4Ijg0yyaw/MoqnRrGDf0PO/Xr+In566
e1SNf2bmZLL8kCnP68IOIfXzmuUgRPd7BFOpsCZlVuER3lmc8KyrR3mhzoQ35nI4
WR2Oi41V9gE5TSk/0dFBaqmbOshoqHG7+lBVDB5C1OxuP7WJyA3fPFc=
=0TF6
-END PGP SIGNATURE-

Re: "debian.pool.ntp.org" for Debian derivatives?

[Philipp Hahn]

Hello Ian et al.,

Am 18.10.18 um 12:40 schrieb Ian Jackson:
> Philipp Hahn writes (""debian.pool.ntp.org" for Debian derivatives?"):
>> Are we (as a Debian derivate) allowed to hard-code and use the
>> "debian.pool.ntp.org" or must we apply for our own pool?
> 
> The NTP pool folks would like you to use your own pool.  So would
> Debian, I'm pretty sure.

Q: So must all Debian derivatives patch NTP and re-compile¹ it as
Debians pool is hard-coded:

> $ apt download ntp
> $ ar p ntp_1%3a4.2.8p10+dfsg-3+deb9u2_amd64.deb | tar xfO data.tar.xz 
> ./etc/ntp.conf | grep ^pool
> pool 0.debian.pool.ntp.org iburst
> pool 1.debian.pool.ntp.org iburst
> pool 2.debian.pool.ntp.org iburst
> pool 3.debian.pool.ntp.org iburst

or only the commercial derivatives?


>> PS: Paying that extra money to ntp.org would certainly not kill use, but
>> adding that money instead to our currently already existing support of
>> Debian-LTS / DebConf sponsoring / ... would probably benefit a lot more
>> Debian (downstream) users and developers.

First of all: We don't what to cheat them or Debian, but the question is
interesting enough as it can have legal questions for all derivatives.

> I wasn't aware that they charged commercial entities in this kind of
> situation but that seems reasonable to me.  IDK how much the charge
> is.  You are getting a service from pool.ntp.org, and as a commercial
> entity you should pay your suppliers.

The question remains, if "Debian" can be our supplier and allow us (and
any other derivatives) to use their pool?

> If the charge is too much, you could always run your own ntp server.

Any sane setup needs at least 4 servers. That is why there is that pool
project so not everyone has to run their own farm of NTP servers around
the world themselves.

> If you continue to use the Debian pool to avoid paying them, then you
> are using their facilities without permission.
...
> TBH I doubt they would get you prosecuted or sue you - because they're
> not that kind of people and wouldn't want to harm the free software
> community = but I hope you will agree that you should act legally!

Normally I tell our customers to ask their Internet providers for their
preferred NTP servers, as they usually run their own farm, which are
then close to their customers (network wise). Many routers have a
built-in NTP server anyway. This normally improves the accuracy and
reduces network traffic as with the pool you can get servers from the
other end of the world. Lucky you if you get that information from your
provider via DHCP (option nntp-server).

Even if your provider does not run its own farm, you can still
re-configure your servers to use at least the pool for your continent or
country, which hopefully are closer by network vise, too.

As an end-user you are not bound by that pool.ntp.org rule and can
configure whatever server you like.

But not as a software or Operating System vendors: I MUST NOT use
'pool.ntp.org'.

So my question is more like "is it okay to not change Debians default
NTP server selection", so the initial setup and those lazy enough to not
change the default get a sane time?

Philipp


¹: not a big deal for us, but we try to stay as closely to Debian as we can.

"debian.pool.ntp.org" for Debian derivatives?

[Philipp Hahn]

Hello,

our business model is to we sell support for our own Debian based
distribution "Univention Corporate Server":
<https://wiki.debian.org/Derivatives/Census/UniventionCorporateServer>

I recently had a discussion about NTP and their pool concept per vendor:
<http://www.pool.ntp.org/en/vendors.html>, but one question remains:

Are we (as a Debian derivate) allowed to hard-code and use the
"debian.pool.ntp.org" or must we apply for our own pool?

This might be interesting for other derivatives as well.

Thanks for any answer
Philipp (AKA pmh...@debian.org)

PS: Paying that extra money to ntp.org would certainly not kill use, but
adding that money instead to our currently already existing support of
Debian-LTS / DebConf sponsoring / ... would probably benefit a lot more
Debian (downstream) users and developers.
-- 
Philipp Hahn
Open Source Software Engineer

Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen
Tel.: +49 421 22232-0
Fax : +49 421 22232-99
h...@univention.de

http://www.univention.de/
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876

library package with conffile and SONAME?

[Philipp Hahn]

Hello,

some library packages like "libtirpc1" (just my example here) contain a
conffile like "/etc/netconfig". Naturally they must conflict with their
successor "libtirpc3" as they contain the same file name. Currently it
does not: 

1. Either I could add the "Conflicts: libtirpc1" but that would render
the rename of the package following the SONAME change useless as they
will never be co-installed anyway then.

2. Or I could add a "Replaces: libtirpc1 (<< 0.2.5-1.2)" to silence dpkg
and allow libtirpc3 to overwrite that with which still has the same
format and content. This has the drawback that anyone later on
installing 1 after 3 will get the error from dpkg as 1 is not allowed to
replace the file from 3.

3. And/or I can create an additional package "libtirpc-common" to just
contain that single conffile and make "libtirpc[13]" both depend on it.
This last option is AFAIK frowned upon as it creates yet another package
for a single file.

So whats the current best practice?

Philipp

"apt-get source snappy" pulls Extra-Source-Only 1.1.4-1 in Debian-Stretch?

[Philipp Hahn]

Hello APT developers,

today I encountered the strange situation, that Debian-Stretch
officially has 1.1.3-3, but if I do a "apt-get source snappy" I get 1.1.4-1:

> $ LANG=C apt-get -d --print-uris source snappy
> Reading package lists... Done
> Need to get 1498 kB of source archives.
> 'http://deb.debian.org/debian/pool/main/s/snappy/snappy_1.1.4-1.dsc' 
> snappy_1.1.4-1.dsc 1817 
> SHA256:a81ea405fe5710d0ee31e62d7007ce6fd4a5e9d2dcfd5767b1c8131b3459349f
> 'http://deb.debian.org/debian/pool/main/s/snappy/snappy_1.1.4.orig.tar.gz' 
> snappy_1.1.4.orig.tar.gz 1491767 
> SHA256:134bfe122fd25599bb807bb8130e7ba6d9bdb851e0b16efcb83ac4f5d0b70057
> 'http://deb.debian.org/debian/pool/main/s/snappy/snappy_1.1.4-1.debian.tar.xz'
>  snappy_1.1.4-1.debian.tar.xz 4400 
> SHA256:9be718653559b45d5bd6eab32d4f18e7b5a1dbff57463cd94ba3f51eb11b0a20

Comparing that with <https://tracker.debian.org/pkg/snappy> and
<https://packages.debian.org/search?searchon=sourcenames=snappy>
shows "1.1.3-3" for Debian-Stretch.

> $ curl -s 
> http://ftp.de.debian.org/debian/dists/stretch/main/source/Sources.xz | xz -d 
> | grep-dctrl -s Package,Version,Extra-Source-Only -PX snappy
> Package: snappy
> Version: 1.1.3-3
> 
> Package: snappy
> Version: 1.1.4-1
> Extra-Source-Only: yes

So how can I tell "apt-get source" to pull the "right" version, e.g. the
version "libsnappy1v5" was built from?

> $ LANG=C apt-cache policy libsnappy1v5
> libsnappy1v5:
>   Installed: 1.1.3-3
>   Candidate: 1.1.3-3
>   Version table:
>  *** 1.1.3-3 500
> 500 http://deb.debian.org/debian stretch/main amd64 Packages
> 100 /var/lib/dpkg/status

This looks like a bug in APT and did I miss something?

Philipp
-- 
Philipp Hahn
Open Source Software Engineer

Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen
Tel.: +49 421 22232-0
Fax : +49 421 22232-99
h...@univention.de

http://www.univention.de/
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876

Re: Compiler with Spectre mitigation retpoline/-mindirect-branch=thunk

[Philipp Hahn]

Hello,

Am 30.01.2018 um 08:43 schrieb Robin Geuze:
> I was wondering, are the debian maintainers planning on backporting the
> -mindirect-branch=thunk support introduced in GCC 7.3 and 8.1 to the
> compilers available on Jessie and Stretch? While this is not necessarily
> a security fix for the compiler it does provide that fix to at least
> kernels compiled using it.

I did it for gcc-4.9, which basically boils down to:

> git clone -o hjl -b hjl/indirect/gcc-4_9-branch/master --depth 8 
> https://github.com/hjl-tools/gcc.git
> git format-patch -7 -o debian/patches/ --src-prefix=a/src/ 
> --dst-prefix=b/src/ -N --no-add-header --suffix=.diff
> filterdiff -p2 -x gcc/doc/invoke.texi -x gcc/doc/extend.texi 
> debian/patches/*.diff
> ls -1 debian/patches/ | sed 's/\.diff//;s/^/debian_patches += /' 
> >>debian/rules.patch

The filterdiff is needed to filter out the GFDL documentation hunks.

Using parallel build (-jX) fails for us, so it takes ~13h to compile
that gcc. I was told to use '-J' instead, but that is not supported by
dpkg-buildpackage in Debian-Stretch :-(

After that just re-compile your Linux kernel.

It hoefully will have
> /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic 
> retpoline
on Intel.


That worked for us here at Univention.

Philipp

PS: Here are the 7 relevant GIT commpits for gcc-4.9 from H.J. Lu's GIT
repository for reference:
> 1fb3a1828fa x86: Disallow -mindirect-branch=/-mfunction-return= with 
> -mcmodel=large
> 7ab5b649f72 x86: Add 'V' register operand modifier
> 5550079949a x86: Add -mindirect-branch-register
> 35590ed7bee x86: Add -mfunction-return=
> e699df5d96f x86: Add -mindirect-branch=
> 2015a09e332 i386: Use reference of struct ix86_frame to avoid copy
> e623d21608e i386: Move struct ix86_frame to machine_function

FTBFS with parallel make

[Philipp Hahn]

Hello fellows,

we (Univention GmbH) rebuild packages (from Debian-Jessie or newer)
using "-j8". Several builds failed, but work when I use "-j1":

* gcc-4.7
> mv: cannot stat 'stamps/07-install-stamp': No such file or directory
> debian/rules.d/binary-libgcc.mk:362: recipe for target 
> 'stamps/08-binary-stamp-libgcc-dev' failed
> make[1]: *** [stamps/08-binary-stamp-libgcc-dev] Error 1
> make[1]: *** Waiting for unfinished jobs
> mv: cannot stat 'stamps/07-install-stamp': No such file or directory

* perl-5.20.2-3+deb8u9
* systemd-215-17+deb8u7
* exim-4.84.2-2+deb8u4
> cp: cannot stat './EDITME.eximon.oOCpeNf': No such file or directory
> debian/rules:116: recipe for target 'b-exim4-daemon-heavy/Makefile' failed
> make: *** [b-exim4-daemon-heavy/Makefile] Error 123

* freeradius-2.2.5+dfsg-0.2+deb8u1
* mysql-5.5.58-0+deb8u1: Bug#857059
* libpaper: Bug#857058
* isc-dhcp: Bug#651922
* e2fsprogs: (attachment)

IMHO with todays multi-core CPUs -jX is a must:
- If I rebuild the full distribution, building multiple packages each
with -j1 is okay.
- But if I need a single package not being able to use -jX is a NO-GO:
For Spectre I re-build gcc-4.9 and it took 13h15m with -j1, because -j8
failed with the above error.

What do you thing: If parallel build a worthy goal?

With all the reproducible build stuff going on, I think it would be nice
if someone™ can also donate CPU time to check that -j`nproc` works.

Philipp
--- Begin Message ---
Hello Theodore,

Am 10.02.2017 um 22:02 schrieb Theodore Ts'o:
> On Thu, Feb 09, 2017 at 05:03:30PM +0100, Philipp Hahn wrote:
>>  install-std: DH_OPTIONS=
>> -install-std: build
>> +install-std: build cleanup
> 
> I don't think this works.  The clean target *must* be done before the
> build target.  In fact, it must be completed before the build target
> starts --- and the way the depedencies are specified above, dh_prep's
> deletion of the build directory would be racing with the build
> target's trying to populate them.
> 
> No?

I think "No" ;-)
Notice the difference between "clean" and "clean*up*":

> $ sed -ne '/^clean/,/^$/p' debian/rules
> clean:
> dh_testdir
> rm -rf ${STAMPSDIR}
> [ ! -f ${stdbuilddir}/Makefile ] || $(MAKE) -C ${stdbuilddir} V=1 
> distclean
> [ ! -f ${bfbuilddir}/Makefile ] || $(MAKE) -C ${bfbuilddir} V=1 
> distclean
> [ ! -f ${staticbuilddir}/Makefile ] || $(MAKE) -C ${staticbuilddir} 
> V=1 distclean
> rm -rf ${stdbuilddir} ${bfbuilddir} ${staticbuilddir} ${mipsbuilddir} 
> ${mipsbuilddir64}
> rm -f debian/*.substvars
> dh_clean
> 
> cleanup:
> dh_testdir
> dh_testroot
> dh_prep

When "dh_prep" is called, it only removed the files belonging to Debian
packages, e.g. the debhelper fragments, package specific directories,
substvars and tmp/. - all the things that must be removed before
"binary" builds the Debian packages:

> $ ls -1 debian > ../before
> $ dh_prep
> $ ls -1 debian > ../after
> $ diff ../before ../after |grep ^\<
> < comerr-dev
> < comerr-dev.substvars
> < e2fsck-static
> < e2fsck-static.substvars
> < e2fslibs
> < e2fslibs-dbg
> < e2fslibs-dbg.substvars
> < e2fslibs-dev
> < e2fslibs-dev.substvars
> < e2fslibs.postinst.debhelper
> < e2fslibs.postrm.debhelper
> < e2fslibs.substvars
> < e2fsprogs
> < e2fsprogs-dbg
> < e2fsprogs-dbg.substvars
> < e2fsprogs-udeb
> < e2fsprogs-udeb.substvars
> < e2fsprogs.substvars
> < libcomerr2
> < libcomerr2-dbg
> < libcomerr2-dbg.substvars
> < libcomerr2.postinst.debhelper
> < libcomerr2.postrm.debhelper
> < libcomerr2.substvars
> < libss2
> < libss2-dbg
> < libss2-dbg.substvars
> < libss2.postinst.debhelper
> < libss2.postrm.debhelper
> < libss2.substvars
> < ss-dev
> < ss-dev.substvars
> < tmp

So "cleanup" must be called fore "binary" or "binary-arch" or
"binary-indep".
FYI: First calling "make binary-arch" and then "make binary-indep" is
not equivalent to "make binary", as the state would be purged in between
then.

I've tested the build multiple times on a 4 CPU KVM: without the patch
most builds fail with the quoted error or with some other race-condition
error; since the patch every built (~6) went fine.

Philipp "pmh...@debian.org" Hahn
--- End Message ---

Re: glibc-2.24-11+deb9u2 from s-p-u already in debian/dists/stretch/main/source/Sources.xz?

[Philipp Hahn]

Hello Emilio,

Am 21.12.2017 um 12:34 schrieb Emilio Pozuelo Monfort:
> It's listed as
> 
> Extra-Source-Only: yes
> 
> So yes, it's normal for it to be there, as another package has Built-Using on
> that glibc version, so we need to ship the source.

Thanks Emilio, that was the missing link.

Philipp

glibc-2.24-11+deb9u2 from s-p-u already in debian/dists/stretch/main/source/Sources.xz?

[Philipp Hahn]

Hi,

I have written a tool myself to parse Debian's Packages and Sources
files to mirror all files belonging to one version for post-processing.
Today I stumbled over "glibc-2.24-11+deb9u2":
- it is *not* listed on
<https://packages.debian.org/search?keywords=glibc=sourcenames=all=all>
- it is listed on <https://tracker.debian.org/pkg/glibc> for s-p-u
- it is included in debian/dists/stretch/main/source/Sources.xz
- it is *not* included in debian/dists/stretch/main/binary-amd64/Packages.xz

Is it normal for Sources to list source packages, which are not yet in
Packages? (Probably yes, if there exists at least one architecture
containing binary packages build from that source version)

Thanks.
Philipp
-- 
Philipp Hahn
Open Source Software Engineer

Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen
Tel.: +49 421 22232-0
Fax : +49 421 22232-99
h...@univention.de

http://www.univention.de/
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876

Database of all (historic) package versions - dak?

[Philipp Hahn]

Hello,

do we (or someone else) have a database of all (source-)packages and
their versions ever released in a Debian suite?
I'm interested in all point releases and also historic suites.

For example

shows
> Quellcode-Paket php5
> wheezy (web): 5.4.45-0+deb7u8 [security] 
> jessie (php): 5.6.30+dfsg-0+deb8u1 [security] 

but I would like to know which exact version was is 7.0, 7.1, .., 7.7
and 8.0, too.

I guess  would work, but I'm denied
login permission on "mirror.ftp-master.debian.org".

Philipp

How to distinguish .udeb files from regular .deb files?

[Philipp Hahn]

Hello,

I accidentally called "dpkg-name" on some *.udeb files and they got
renamed to .deb.

Looking inside dpkg-name, it tries to evaluate "Package-Type" [1], but
that is not contained in the control file of the binary package, so
always evaluates to "deb":
> 123 my $type = $fields->{'Package-Type'} || 'deb';
>   

Is there some other (preferred) way to identify .udeb packages?

1. "Section: debian-installer"?

2. Some pages use the suffix "-udeb" or "-di" in their package names.

3. If the control file contains a "isinstallable" script.
> dpkg -I 'potential.udeb' | grep -q isinstallable

4. If the control files has a "Installer-Menu-Item" field:
> grep -I 'potential.udeb' | grep -q Installer-Menu-Item

Other ideas?
Or is there a definitive answer hidden somewhere?

Thanks in advance.

Philipp

[1]

RFH: Breaks (<< $version) for moving conffiles vs. dpkg updating package version too early?

[Philipp Hahn]

Hi,

I've re-built a version of libirt, which has:

> Package: libvirt-daemon-system
> Replaces: libvirt-bin (<< 1.2.7-4~)
> Conflicts: libvirt-bin (<< 1.2.6-1~)
...
> Package: libvirt-bin
> Depends: libvirt-daemon-system (>= ${binary:Version}),

The old "libvirt-bin" package (0.9.12-5) contained
"/etc/default/libvirt-guests", which got moved to
"libvirt-daemon-system" for 1.2.7, thus the "Replaces".

During the package upgrade "dpkg" complains about the file still being
owned by "libvirt-bin" and prevents "libvirt-daemon-system" from taking
over the file

> Entpacken von libvirt-daemon-system (aus 
> .../libvirt-daemon-system_1.2.7-11_amd64.deb) ...
> dpkg: Fehler beim Bearbeiten von 
> /var/cache/apt/archives/libvirt-daemon-system_1.2.7-11_amd64.deb (--unpack):
>  Versuch, »/etc/default/libvirt-guests« zu überschreiben, welches auch in 
> Paket libvirt-bin 1.2.7-11 ist

Reading /var/log/dpkg.log I see:
> 2016-03-07 15:39:04 upgrade libvirt-bin:amd64 0.9.12-5 1.2.7-11
> 2016-03-07 15:39:04 status half-configured libvirt-bin:amd64 0.9.12-5
> 2016-03-07 15:39:04 status unpacked libvirt-bin:amd64 0.9.12-5
> 2016-03-07 15:39:04 status half-installed libvirt-bin:amd64 0.9.12-5
> 2016-03-07 15:39:04 status half-installed libvirt-bin:amd64 0.9.12-5
> 2016-03-07 15:39:04 status half-installed libvirt-bin:amd64 0.9.12-5
> 2016-03-07 15:39:04 status unpacked libvirt-bin:amd64 1.2.7-11
> 2016-03-07 15:39:04 status unpacked libvirt-bin:amd64 1.2.7-11
> 2016-03-07 15:39:04 install libvirt-clients:amd64  1.2.7-11
> 2016-03-07 15:39:04 status half-installed libvirt-clients:amd64 1.2.7-11
> 2016-03-07 15:39:04 status half-installed libvirt-clients:amd64 1.2.7-11
> 2016-03-07 15:39:04 status unpacked libvirt-clients:amd64 1.2.7-11
> 2016-03-07 15:39:04 status unpacked libvirt-clients:amd64 1.2.7-11
> 2016-03-07 15:39:10 install libvirt-daemon:amd64  1.2.7-11
> 2016-03-07 15:39:10 status half-installed libvirt-daemon:amd64 1.2.7-11
> 2016-03-07 15:39:10 status half-installed libvirt-daemon:amd64 1.2.7-11
> 2016-03-07 15:39:10 status unpacked libvirt-daemon:amd64 1.2.7-11
> 2016-03-07 15:39:10 status unpacked libvirt-daemon:amd64 1.2.7-11
> 2016-03-07 15:39:10 install libvirt-daemon-system:amd64  1.2.7-11
> 2016-03-07 15:39:10 status half-installed libvirt-daemon-system:amd64 1.2.7-11
> 2016-03-07 15:39:10 status not-installed libvirt-daemon-system:amd64 
> 2016-03-07 15:39:10 upgrade libvirt0:amd64 0.9.12-5 1.2.7-11
> 2016-03-07 15:39:10 status half-configured libvirt0:amd64 0.9.12-5
> 2016-03-07 15:39:10 status unpacked libvirt0:amd64 0.9.12-5
> 2016-03-07 15:39:10 status half-installed libvirt0:amd64 0.9.12-5
> 2016-03-07 15:39:10 status half-installed libvirt0:amd64 0.9.12-5
> 2016-03-07 15:39:10 status unpacked libvirt0:amd64 1.2.7-11
> 2016-03-07 15:39:10 status unpacked libvirt0:amd64 1.2.7-11
> 2016-03-07 15:39:11 configure libvirt0:amd64 1.2.7-11 
> 2016-03-07 15:39:11 status unpacked libvirt0:amd64 1.2.7-11
> 2016-03-07 15:39:11 status half-configured libvirt0:amd64 1.2.7-11
> 2016-03-07 15:39:11 status installed libvirt0:amd64 1.2.7-11
> 2016-03-07 15:39:13 configure libvirt-clients:amd64 1.2.7-11 
> 2016-03-07 15:39:13 status unpacked libvirt-clients:amd64 1.2.7-11
> 2016-03-07 15:39:13 status unpacked libvirt-clients:amd64 1.2.7-11
> 2016-03-07 15:39:13 status unpacked libvirt-clients:amd64 1.2.7-11
> 2016-03-07 15:39:13 status half-configured libvirt-clients:amd64 1.2.7-11
> 2016-03-07 15:39:13 status installed libvirt-clients:amd64 1.2.7-11
> 2016-03-07 15:39:13 configure libvirt-daemon:amd64 1.2.7-11 
> 2016-03-07 15:39:13 status unpacked libvirt-daemon:amd64 1.2.7-11
> 2016-03-07 15:39:13 status half-configured libvirt-daemon:amd64 1.2.7-11
> 2016-03-07 15:39:13 status installed libvirt-daemon:amd64 1.2.7-11
> 2016-03-07 15:40:12 install libvirt-daemon-system:amd64  1.2.7-11
> 2016-03-07 15:40:12 status half-installed libvirt-daemon-system:amd64 1.2.7-11
> 2016-03-07 15:40:12 status not-installed libvirt-daemon-system:amd64 

Looking into "/var/lib/dpkg/status" I see:
> Package: libvirt-bin
> Status: install ok unpacked
> Version: 1.2.7-11
> Config-Version: 0.9.12-5


To me it looks like dpkg already uses the *new* version "1.2.7-11" of
"libvirt-bin" after unpacking, which prevent the "Replaces << 1.2.7-4"
of "libvirt-daemon-system" from being allowed.

Is this a know bug (of dpkg) or did I misunderstand anything?

dpkg1.16.16

Thanks in advance.
Philipp

PS: To my understanding the "Conflicts" should be changed to "Breaks",
but that's another issue.