Re: Bug#995189: RFH: isc-dhcp

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

Re: Bug#995189: RFH: isc-dhcp

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

Re: Bug#995189: RFH: isc-dhcp

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.

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

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

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

"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 st

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

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

Re: debdocker - A Debian docker-based personal builder

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

Accepted uftp 4.9.9-1 (source amd64) into unstable

-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

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

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

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

rg) 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 E

library package with conffile and SONAME?

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.

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

ilt 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

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

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

FTBFS with parallel make

essage --- 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 targe

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

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.

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

ackages? (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.

Database of all (historic) package versions - dak?

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

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

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 =

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

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