Re: Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)

On Thu, 2020-02-06 at 09:39:29 +0100, Michael Biebl wrote: > Am 06.02.20 um 09:22 schrieb Adam D. Barratt: > > On 2020-02-06 08:12, Paul Gevers wrote: > > > But, if I am correct, the source could be using a version without epoch > > > and only use the epoch in the binary package (which can be dropp

Re: packages declaring a relation to mailx (virtual package)

On Fri, 2020-02-07 at 11:49:55 +, Philip Hands wrote: > It seems that most (26) packages are explicitly preferring bsd-mailx, > which seems fair enough to me. Ack. > heirloom-mailx is a dummy package that depends on s-nail, where s-nail > does not actually provide mailx, so I suspect that men

Bug#950903: ITP: liburing -- Linux kernel io_uring access library

Package: wnpp Severity: wishlist Owner: Guillem Jover * Package name: liburing Version : 0.4 Upstream Author : Jens Axboe * URL : https://git.kernel.dk/cgit/liburing/ * License : LGPL and MIT/X Programming Lang: C Description : Linux kernel io_uring

Re: Heads up: persistent journal has been enabled in systemd

Hi! On Tue, 2020-02-11 at 08:19:46 +0100, Helmut Grohne wrote: > I am an early adopter (at a time when you had to pass init= to use > systemd) and I also enabled the persistent journal on practically all of > my systems. I find myself liking the filtering that is enabled by > journalctl, but it se

Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib

On Sat, 2020-02-15 at 20:35:58 +0100, Marco d'Itri wrote: > On Feb 15, Sven Joachim wrote: > > True, but there seem to be a relatively high number of systems where an > > old unowned version of some library is lying around under /lib (possibly > > because the dpkg database became corrupted at some

Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib

Hi! On Sat, 2020-02-15 at 18:31:32 +0100, Andreas Metzler wrote: > afaict we are moving to a usrmerge setup, i.e. with /lib just a > symlink to /usr/lib. So shouldn't packages start installing stuff to > /usr/lib instead of /lib? I would like to do that for libgcrypt, since > I would be able to sh

Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib

On Sat, 2020-02-15 at 23:27:08 +0100, Michael Biebl wrote: > Those issues happen on non-usr-merged systems. The one report against dpkg sure. I'm talking about the ones with disappearing pathnames, in case that was part of "similar". But if it was not, then libcrypt is still just broken on usrmerg

Re: How to undo a merged-user installation?

On Tue, 2020-02-18 at 17:58:30 +0100, Svante Signell wrote: > I recently installed Debian/bullseye/sid in a VM from a snapshot. After > running that image I realized the I got a merged-user installation. > > As for now I have: > bin -> usr/bin > lib -> usr/lib > lib32 -> usr/lib32 > lib64 -> usr/l

Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib

On Sun, 2020-02-16 at 11:59:56 +, Simon McVittie wrote: > I would be grateful if people who advocate transitioning individual > packages, and people who consider the approach taken by usrmerge and > debootstrap to be sufficient, could refer to their preferred route in a > way that makes it clea

Re: pager and upgrades

Hi! On Wed, 2020-02-26 at 19:53:09 -0700, Nicholas D Steeves wrote: > Russell Coker writes: > > I just upgraded a Buster system to today's unstable and got the below. I > > think this should be regarded as a bug, but what is it a bug in? dpkg? > > > > Configuration file '/etc/smartd.conf' > >

Bug#952776: RFP: libprometheus-tiny-perl -- tiny module to export monitoring metrics for Prometheus

Package: wnpp Severity: wishlist Tags: patch * Package name: libprometheus-tiny-perl Version : 0.004 Upstream Author : Rob N ★ * URL : https://metacpan.org/release/Prometheus-Tiny * License : Artistic or GPL-1+ Programming Lang: Perl Description : tiny

RFC: Standardizing a new Protected field

Hi! Summary --- The goal of the following proposal is to standardize a field to split part of the Essential packages, and add support for it in the package management stack. There is currently an Important field, that has the correct semantics but has a very confusing name and is only support

RFC: Standardizing source package artifacts build paths

Hi! We currently have many built artifacts being dropped directly under debian/ or under tool specific directories such as debian/.debhelper/. These have at least the following problems: - Make cleaning, an operation that requires executing code from the source package itself. - Require k

Bug#953658: RFP: golang-github-allegro-bigcache -- efficient cache for gigabytes of data written in Go (library)

Package: wnpp Severity: wishlist Tags: patch * Package name: golang-github-allegro-bigcache Version : 2.1.7 Upstream Author : Allegro Tech * URL : https://github.com/allegro/bigcache * License : Apache-2.0 Programming Lang: Go Description : efficient cac

Bug#953659: RFP: golang-github-valyala-fastrand -- fast and scalable pseudorandom generator for Go (library)

Package: wnpp Severity: wishlist Tags: patch * Package name: golang-github-valyala-fastrand Version : 1.0.0 Upstream Author : Aliaksandr Valialkin * URL : https://github.com/valyala/fastrand * License : Expat Programming Lang: Go Description : fast and s

Bug#953661: RFP: golang-github-valyala-gozstd -- go wrapper for zstd (library)

Package: wnpp Severity: wishlist Tags: patch * Package name: golang-github-valyala-gozstd Version : 1.6.4 Upstream Author : Aliaksandr Valialkin * URL : https://github.com/valyala/gozstd * License : Expat Programming Lang: Go Description : go wrapper for

Bug#953662: RFP: golang-github-valyala-histogram -- fast histograms for Go (library)

Package: wnpp Severity: wishlist Tags: patch * Package name: golang-github-valyala-histogram Version : 1.0.1 Upstream Author : Aliaksandr Valialkin * URL : https://github.com/valyala/histogram * License : Expat Programming Lang: Go Description : Fast his

Bug#953660: RFP: golang-github-valyala-fastjson -- fast JSON parser and validator for Go (library)

Package: wnpp Severity: wishlist Tags: patch * Package name: golang-github-valyala-fastjson Version : 1.5.0 Upstream Author : Aliaksandr Valialkin * URL : https://github.com/valyala/fastjson * License : Expat Programming Lang: Go Description : fast JSON

Bug#953664: RFP: golang-github-victoriametrics-fastcache -- fast thread-safe in-memory cache for big number of entries in Go (library)

Package: wnpp Severity: wishlist Tags: patch * Package name: golang-github-victoriametrics-fastcache Version : 1.5.6 Upstream Author : VictoriaMetrics * URL : https://github.com/VictoriaMetrics/fastcache * License : Expat Programming Lang: Go Description

Bug#953663: RFP: golang-github-valyala-quicktemplate -- fast, powerful, yet easy to use template engine for Go (lborary)

Package: wnpp Severity: wishlist Tags: patch * Package name: golang-github-valyala-quicktemplate Version : 1.4.1 Upstream Author : Aliaksandr Valialkin * URL : https://github.com/valyala/quicktemplate * License : Expat Programming Lang: Go Description :

Bug#953665: RFP: golang-github-victoriametrics-metrics -- lightweight alternative to prometheus/client_golang (library)

Package: wnpp Severity: wishlist Tags: patch * Package name: golang-github-victoriametrics-metrics Version : 1.10.1 Upstream Author : VictoriaMetrics * URL : https://github.com/VictoriaMetrics/metrics * License : Expat Programming Lang: Go Description :

Bug#953666: RFP: victoria-metrics -- fast, cost-effective and scalable time series database

Package: wnpp Severity: wishlist Tags: patch * Package name: victoria-metrics Version : 1.34.2 Upstream Author : VictoriaMetrics * URL : https://github.com/VictoriaMetrics/VictoriaMetrics * License : Apache-2.0 Programming Lang: Go Description : fast, co

Bug#954286: RFP: prometheus-redis-exporter -- Prometheus exporter for Redis metrics

Package: wnpp Severity: wishlist Tags: patch * Package name: prometheus-redis-exporter Version : 1.4.0 Upstream Author : Oliver * URL : https://github.com/oliver006/redis_exporter * License : MIT Programming Lang: Go Description : Prometheus exporter for

Re: RFC: Standardizing source package artifacts build paths

On Mon, 2020-03-09 at 09:23:46 -0400, Sam Hartman wrote: > I'm concerned about a leading . at least for: > > * the debian/tmp replacement > * the replacement for the package install directories under debian. > > I think that maintaining those directories such that ls shows them will > be more fri

Re: RFC: Standardizing a new Protected field

Hi! On Mon, 2020-03-09 at 10:23:36 +0100, Guillem Jover wrote: > Summary > --- > > The goal of the following proposal is to standardize a field to split > part of the Essential packages, and add support for it in the package > management stack. There is currently an Importa

Re: trimming changelogs

Hi! On Fri, 2020-03-20 at 00:50:29 +0100, Adam Borowski wrote: > In the rush for cutting away small bits of minbase, it looks like we forgot > a big pile of junk: /usr/share/doc/ As has been mentioned on the thread, this is IMO a non-issue, as these pathnames can be trimmed automatically with dpk

Re: RFC: Standardizing source package artifacts build paths

On Sun, 2020-03-29 at 22:48:04 +0200, Marco d'Itri wrote: > On Mar 29, Guillem Jover wrote: > > While it's true that we might need to use such pathnames in debian/rules > > or debhelper fragment files (which some might consider ugly), IMO that > > has alway

Re: RFC: Standardizing source package artifacts build paths

On Mon, 2020-03-30 at 13:54:27 +0200, Simon Richter wrote: > On 30.03.20 00:52, Guillem Jover wrote: > > And, of course there are always going to be remaining sticking points > > not covered by features I or others have in mind, but IMO their presence > > will still mean

Re: Change in Lintian behavior: more granular exit code statuses

Hi! On Mon, 2020-05-25 at 16:24:23 -0500, Simon Quigley wrote: > A change that I have been working on with Felix Lechner[1] has now been > merged into the master branch of Lintian and should be landing within > the next several weeks. We expect this change to land in Bullseye. > > This change add

Bug#969781: RFP: libtoml-tiny-perl -- minimal, pure perl TOML parser and serializer

Package: wnpp Severity: wishlist Tags: patch * Package name: libtoml-tiny-perl Version : 0.09 Upstream Author : Jeff Ober * URL : https://metacpan.org/release/TOML-Tiny * License : Artistic or GPL-1+ Programming Lang: Perl Description : minimal, pure pe

[MBF] Obsoleting Source-Version substvar

Hi! I'd like to obsolete the ${Source-Version} substvar, which has very misleading semantics, and has been deprecated since dpkg 1.13.19 in 2006-05-04. This currently emits warnings from various dpkg-dev scripts and from lintian.

Re: [MBF] Obsoleting Source-Version substvar

Hi! On Sun, 2016-07-10 at 02:16:21 +0200, Guillem Jover wrote: > I'd like to obsolete the ${Source-Version} substvar, which has very > misleading semantics, and has been deprecated since dpkg 1.13.19 in > 2006-05-04. This currently emits warnings from various dpkg-dev > scripts

Re: [MBF] Obsoleting bzip2 compression in .deb packages

Hi! On Wed, 2016-07-06 at 03:19:40 +0200, Guillem Jover wrote: > I'd like to obsolete bzip2 (and lzma) as .deb compressors when building > binary packages. dpkg-deb currently emits warnings, this would turn them > into errors. For lzma it's fine in Debian as the archive has ne

Re: New default -fdebug-prefix-map build flag for dpkg

Hi! On Thu, 2016-07-21 at 11:06:32 +, Mattia Rizzolo wrote: > On Mon, Jul 18, 2016 at 08:57:01AM +, Mattia Rizzolo wrote: > > As part of the Reproducible Builds effort [0], we would like to enable > > a new default build flag from the reproducible/fixdebugpath feature > > area in order to

Re: Base binary packages using xz instead of gzip

Hi! On Mon, 2014-09-01 at 13:33:35 +0200, Guillem Jover wrote: > It seems there's quite many binary packages in the base system using > xz as compressor instead of gzip, since the switch to xz as default, > which might make debootstrapping from non-Debian systems harder. After

Re: Porter roll call for Debian Stretch

Hi! On Sun, 2016-08-21 at 08:22:09 +0200, Niels Thykier wrote: > Kurt Roeckx: > > On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote: > >> * If we were to enable -fPIE/-pie by default in GCC-6, should that change > >>also apply to this port? [0] > > > > If -fPIE is the default

Re: Porter roll call for Debian Stretch

Hi! On Sun, 2016-08-21 at 10:24:42 +0200, Bálint Réczey wrote: > I'm testing a set of patches [2] for gcc and dpkg which enable bindnow for all > arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu. > > My assumption was that this set of architectures need the least amount of > additio

Re: Computing Build-Depends at build time (and other updates to debian/control)?

Hi! On Sun, 2016-08-21 at 02:03:00 -0700, Josh Triplett wrote: > Some packages could potentially compute most of their Build-Depends the > same way. For example, I'm working on a tool ("debcargo") to package > Rust libraries and applications, which include detailed metadata (via > Cargo) for depe

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

Hi! On Fri, 2016-08-19 at 13:47:15 +0200, Philipp Hahn wrote: > I accidentally called "dpkg-name" on some *.udeb files and they got > renamed to .deb. Yes, and the reasons are a bit ugly, so you might want to skip the following paragraph… This is the consequence of the half-assed integration of

Re: Network access during build

Hi! On Wed, 2016-09-07 at 08:41:19 +0200, Christoph Biedl wrote: > Vincent Bernat wrote... > > > One of the package that I maintain (python-asyncssh) makes a DNS request > > during build and expects it to fail. Since Policy 4.9 forbids network > > access (in a rather confusing wording "may not"),

Re: [RFC] Adding pkg-config to build-essential

Hi! On Sat, 2016-09-17 at 11:26:05 +0200, Michael Biebl wrote: > I wonder if nowadays pkg-config would qualify as Build-Essential. I don't think so. > We have 2400 source packages listing it as explicit Build-Depends and > countless -dev packages pulling in pkg-config. So the list of packages >

Re: Keysafe dynamic UID

Hi! On Sun, 2016-10-23 at 00:14:43 +0200, Vincent Bernat wrote: > ❦ 22 octobre 2016 14:57 -0700, Sean Whitton  : > > I am packaging Keysafe,[1] and the binary package keysafe-server needs > > to create a new system user with a dynamically allocated UID. > > > > I am using the username 'keysafe'.

Re: Keysafe dynamic UID

Hi! On Sun, 2016-10-23 at 12:54:56 +0200, Marc Haber wrote: > On Sun, 23 Oct 2016 00:26:40 +0200, Jakub Wilk wrote: > > Maybe we could fix #429671? > > I know it's been only 9 years old, but still... > We either need a policy change or a TC decision for that. The policy > editor didn't want to do

Re: Keysafe dynamic UID

Hi! On Sun, 2016-10-23 at 15:07:27 +0200, Vincent Bernat wrote: > ❦ 23 octobre 2016 14:38 +0200, Guillem Jover  : > >> It is better to use either _keysafe or Debian-keysafe to avoid collision > >> with existing users (like Kevin Eysafe). > > > > Please avoid the

Re: Keysafe dynamic UID

On Sun, 2016-10-23 at 16:06:30 +0200, Guillem Jover wrote: > I've just sent a patch for adduser to accept _-prefixed system names > (but not for normal users w/o --force-badname). Then if this gets > merged, there will be even more compelling reasons to use that. ;) Sorry, that w

Re: Keysafe dynamic UID

Hi! On Sun, 2016-10-23 at 12:32:30 -0200, Henrique de Moraes Holschuh wrote: > On Sun, 23 Oct 2016, Guillem Jover wrote: > > Right now I'm actually considering going over the archive and sending > > patches to convert Debian-user and debian-user to _user… > Make it activ

Re: "PIE by default" transition is underway -- wiki needs updating

Hi! On Tue, 2016-10-25 at 09:44:44 +0200, Bálint Réczey wrote: > 2016-10-25 5:31 GMT+02:00 Steve M. Robbins : > > I haven't been paying close attention to the "PIE by default" [1] > > discussions, > > so I may have missed the memo, but: it seems the transition is underway? > > GCC have been chan

Re: "PIE by default" transition is underway -- wiki needs updating

Hi! On Wed, 2016-10-26 at 00:37:18 +0200, Andreas Cadhalpun wrote: > On 25.10.2016 13:55, Guillem Jover wrote: > > I don't think the reasoning there is sound (as I've mentioned > > elsewhere), and the policy bug should be closed. > > > > Switching from n

Re: Keysafe dynamic UID

Hi! On Sun, 2016-10-23 at 18:44:47 +0200, Marc Haber wrote: > On Sun, 23 Oct 2016 14:48:44 +0200, Guillem Jover wrote: > > Right now I'm actually considering going over the archive and sending > > patches to convert Debian-user and debian-user to _user… > Don't bot

Re: When should we https our mirrors?

Hi! On Mon, 2016-10-24 at 11:51:00 -0400, Paul Tagliamonte wrote: > On Mon, Oct 24, 2016 at 04:00:39PM +0100, Ian Jackson wrote: > > It is also evident that there are some challenges for deploying TLS on > > a mirror network and/or CDN. I don't think anyone is suggesting > > tearing down our exis

Heads-up: Switching internal dpkg arch representation to quadruplets

Hi! Currently dpkg represents architectures internally as Debian triplets, which have the inverse order as GNU triplets. One problem is that the first element of the triplet encodes the ABI and the libc used, so we have no way to wildcard one or the other, and this is becoming more relevant with n

Re: misleading timestamps in binnmus

Hi! On Tue, 2016-11-08 at 22:41:09 +, Ian Jackson wrote: > I see the python2.7 source package does this: > > LAST_CHANGE := $(shell dpkg-parsechangelog -S Date) > export BUILD_DATE := $(shell LC_ALL=C date -u +'%b %e %Y' -d > '$(LAST_CHANGE)') > export BUILD_TIME := $(shell LC_ALL=C date

Re: [MBF] Obsoleting bzip2 compression in .deb packages

Hi! On Tue, 2016-08-02 at 13:47:49 +0200, Guillem Jover wrote: > On Wed, 2016-07-06 at 03:19:40 +0200, Guillem Jover wrote: > > I'd like to obsolete bzip2 (and lzma) as .deb compressors when building > > binary packages. dpkg-deb currently emits warnings, this would turn them

Re: misleading timestamps in binnmus

Hi! On Wed, 2016-11-09 at 11:16:09 +, Ian Jackson wrote: > Sven Joachim writes ("Re: misleading timestamps in binnmus"): > > I'm afraid I don't really have a good suggestion. Using current date > > would work but obviously break reproducibility, and any other date seems > > arbitrary. > > I

Re: What to do when a maintainer is blocking maintenance for stretch?

Hi! On Wed, 2016-11-09 at 12:12:43 +, Ian Jackson wrote: > Peter Colberg writes ("What to do when a maintainer is blocking maintenance > for stretch?"): > > Improving the package would require significant changes that are not > > appropriate for a minimal NMU. With the maintainer not respondi

Re: Debian Installer Stretch Alpha 8 release

Hi, On Sat, 2016-11-12 at 16:24:32 +0100, Cyril Brulebois wrote: > Important change in this release of the installer > = > > * debootstrap now defaults to merged-/usr, that is with /bin, /sbin, >/lib* being symlinks to their counterpart in /usr

Re: Debian Installer Stretch Alpha 8 release

Control: severity 843073 important On Sat, 2016-11-12 at 18:37:52 +0100, Guillem Jover wrote: > On Sat, 2016-11-12 at 16:24:32 +0100, Cyril Brulebois wrote: > > Important change in this release of the installer > > = > > &

Re: Debian Installer Stretch Alpha 8 release

Control: clone 843073 -1 Control: reassign -1 debootstrap 1.0.85 Control: retitle -1 debootstrap: Please revert merged-/usr by default as it breaks builds Control: severity -1 serious Control: affects -1 dpkg-dev Control: severity 843073 wishlist Control: block 810499 by 843073 Control: severity 8

Re: Debian Installer Stretch Alpha 8 release

Just a brief reply. On Mon, 2016-11-21 at 16:38:07 +0100, Raphael Hertzog wrote: > On Mon, 14 Nov 2016, Michael Biebl wrote: > > Just for the record: I can confirm it fixes the problem in dpkg-shlibdeps. > [...] > > Guillem, it would be great if you can upload a fixed dpkg soon. > > A full week w

Re: Debian Installer Stretch Alpha 8 release

On Mon, 2016-11-21 at 17:09:50 +0100, Guillem Jover wrote: > On Mon, 2016-11-21 at 16:38:07 +0100, Raphael Hertzog wrote: > > I can offer to upload dpkg 1.18.15.1 to sid with just those patches if > > it relieves you from handling an intermediary upload until you > > release

[RFC] Enabling bindnow by default in dpkg-buildflags?

Hi! This was discussed relatively recently, but it was not entirely clear to me what was the conclusion, if there was any(?), about enabling bindnow by default. And although this got enabled by default in gcc-6 6.2.0-7 when PIE also got enabled, it seems it got disabled in 6.2.0-10 when I pointed

Re: Bug#843073: Debian Installer Stretch Alpha 8 release

On Mon, 2016-11-21 at 17:23:19 +0100, Marco d'Itri wrote: > On Nov 21, Guillem Jover wrote: > > Oh, and forgot to mention, this issue has been known for over 8 > > months, and now there's this need to be pushy and rush things, etc. > > I certainly do not appreciate

Re: sbuild vs pbuilder (and dgit)

Hi! On Mon, 2016-11-28 at 17:39:46 +, Ian Jackson wrote: > Scott Leggett writes ("Difference in behaviour between pbuilder and sbuild"): > > I've recently tried using sbuild rather than pbuilder (inspired by a > > blog post[0]), > > > > [0] https://people.debian.org/~stapelberg/2016/11/25/bu

Re: dpkg no longer installs conffiles??

On Tue, 2016-11-29 at 17:58:58 +0100, Svante Signell wrote: > I don't know a suitable forum for this type of question. And please don't > refer > me to the high-traffic ML debian-user, I won't use that one. You don't need to subscribe to be able to post. Using one of the support channels before s

Installing missing conffiles (was Re: dpkg no longer installs conffiles??)

On Tue, 2016-11-29 at 19:18:41 +0100, Simon Richter wrote: > To force reinstallation of configuration files, invoke dpkg with the > "--force-confmiss" option when installing. This will only restore > missing configuration files, but not overwrite changed ones. If some > configuration files were dam

Re: Installing missing conffiles (was Re: dpkg no longer installs conffiles??)

Hi! On Wed, 2016-11-30 at 20:25:05 +0100, Sven Joachim wrote: > On 2016-11-30 14:16 +0100, Guillem Jover wrote: > > On Tue, 2016-11-29 at 19:18:41 +0100, Simon Richter wrote: > >> To force reinstallation of configuration files, invoke dpkg with the > >> "--force-

Re: Bug#843073: dpkg-shlibdeps fix for merged /usr

On Mon, 2016-12-12 at 04:26:20 +0100, Marco d'Itri wrote: > On Nov 21, Guillem Jover wrote: > > First I have to go over a list of queued pending items and then I'll > > get to this during this week. I have not yet reviewed the patches (in > > part because I didn&#

Re: Auto-detecting -dev package dependences from pkg-config

Hi! On Sun, 2016-12-11 at 21:48:17 -0800, Josh Triplett wrote: > [Please CC me on replies.] > I'd like to build some tools (possibly including a dh_pkgconfig) to do > this automatically; those tools could generate a pkgconfig:Depends > substvar for use in debian/control. Before starting on those

Re: [RFC] Enabling bindnow by default in dpkg-buildflags?

On Wed, 2016-12-14 at 14:05:44 +0100, Bálint Réczey wrote: > 2016-12-13 9:29 GMT+01:00 Bálint Réczey : > > 2016-11-27 23:11 GMT+01:00 Bálint Réczey : > >> 2016-11-23 2:30 GMT+01:00 Guillem Jover : > >>> My mine concern is and has always been that bindnow chang

Re: [RFC] Enabling bindnow by default in dpkg-buildflags?

On Sat, 2016-12-17 at 09:20:40 +0100, Bálint Réczey wrote: > 2016-12-17 3:14 GMT+01:00 Guillem Jover : > > On Wed, 2016-12-14 at 14:05:44 +0100, Bálint Réczey wrote: > >> 2016-12-13 9:29 GMT+01:00 Bálint Réczey : > >> > 2016-11-27 23:11 GMT+01:00 Bálint Réczey : >

Re: depending on libssl1.0-dev, buildd fails to find it

Hi! On Mon, 2016-12-19 at 13:12:32 +0100, Johannes Schauer wrote: > Quoting Mattia Rizzolo (2016-12-18 11:38:24) > > On Sat, Dec 17, 2016 at 09:27:12PM -0500, James McCoy wrote: > > > As Arno hinted at, it's to have reliable builds. A transient inability > > > to install the first arm of an alter

Re: Migration despite an RC bug?

Hi! On Fri, 2016-12-30 at 09:25:20 +0100, Emilio Pozuelo Monfort wrote: > On 29/12/16 23:36, Christoph Biedl wrote: > > Emilio Pozuelo Monfort wrote... > >> Unforunately, the BTS exported a broken/incomplete RC bug list, and > >> britney used > >> that and didn't see that some packages had an RC

Re: [buildd-tools-devel] Bug#843773: Bug#843773: misleading timestamps in binnmus

[ Had this half-drafted, but had not found the time to finish it up until now. ] Hi! On Mon, 2016-11-14 at 13:52:18 +, Ian Jackson wrote: > Johannes Schauer writes ("Re: [buildd-tools-devel] Bug#843773: Bug#843773: > misleading timestamps in binnmus"): > > Instead, file conflicts might be

Feedback on 3.0 source format problems

Hi! I'm interested in what things people still find so off-putting to the point of not wanting to use the new 3.0 source formats, or what makes people use them in anger and similar (if people would state which one of these apply that would be helpful). All these including objective and subjective

Re: Feedback on 3.0 source format problems

On Sun, 2017-01-01 at 10:47:59 -0800, Nikolaus Rath wrote: > On Jan 01 2017, Guillem Jover wrote: > > (I'm not using <https://wiki.debian.org/Projects/DebSrc3.0> because > > TBH it read more like a sales brochure than a more neutral page…) > > TBH this feels lik

[RFC] The PIE unholy mess

Hi! I'd like to get some feedback from porters and package maintainers, given that this affects at least both groups. Some background first. One of the reasons PIE has in the past not been enabled by default in dpkg-buildflags, is because it introduced some slowness on some arches, although this

Re: [RFC] The PIE unholy mess

On Wed, 2017-01-18 at 08:10:53 +0100, Bálint Réczey wrote: > 2017-01-18 4:34 GMT+01:00 Guillem Jover : > > So, I'd like to know how people feel about the requested interface > > (i.e. not enabling PIE globally from dpkg-buildflags). If there's > > consensus that po

Re: please, let's *completely* drop md5sums for buster (was Re: no-strong-digests-in-dsc MBF)

On Sun, 2017-01-22 at 13:54:26 +0100, Philipp Kern wrote: > On 22.01.2017 12:34, Bernd Zeimetz wrote: > > afaik people are criticizing that there are still (only) md5sum files in > > /var/lib/dpkg/info. As dpkg --verify uses them, it might indeed make > > sense to replace them. > > (yes, dpkg is no

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

Hi! [ Thanks, I also wanted to chime in and mention this, because it seems other people might not be clear on the history and motivations for build-profiles! ] On Mon, 2018-01-08 at 18:37:11 +, Wookey wrote: > On 2018-01-03 13:30 +, Simon McVittie wrote: > > On Wed, 03 Jan 2018 at 15:

Re: [yay for broken usage of was: in the Subject header]

On Thu, 2018-01-11 at 01:06:06 +0100, Johannes Schauer wrote: > Quoting Philipp Kern (2018-01-11 00:20:17) > > Why is it making comparing packages with each other difficult? > > What I meant here was what I mentioned elsewhere in this thread. We can check > whether two binary packages built with a

Re: Storing build profiles in binary packages (was: Re: Bug#886238: Please introduce official nosystemd build profile)

[ Just few comments to complement josch's veyr nice reply, with which I completely agree with. ] On Thu, 2018-01-11 at 00:47:28 +0100, Johannes Schauer wrote: > Quoting Steve Langasek (2018-01-10 21:49:02) > > As a policy, I think it's clear that packages built with non-default > > profiles > >

Re: RFC: Support for selective usage of (fake)root during package build (R³)

Hi! On Mon, 2017-11-13 at 01:28:08 +0100, Guillem Jover wrote: > On Sat, 2017-10-28 at 15:59:00 +, Niels Thykier wrote: > > * Deadline for feedback: 2 weeks from today (but we are happy to extend > >it if people find this too short). > >- if there are no maj

Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)

On Thu, 2018-01-18 at 18:52:57 +0100, Emilio Pozuelo Monfort wrote: > On 10/01/18 01:29, Sam Hartman wrote: > > A build profile seems like a great way to express the flag, and like > > many things in Debian, the work would fall on those who would benefit > > from it. > > I think it'd be better to

Re: Reducing the attack surface caused by Berkeley DB...

Hi! On Thu, 2018-01-25 at 23:59:06 +0100, Lionel Debroux wrote: > Several days ago, jmm from the security team suggested that I start a > discussion on debian-devel about Berkeley DB, which has known security > issues, because doing so may enable finding a consensus on how to move > away from it i

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

Hi! On Wed, 2018-01-31 at 07:35:32 +0100, Philipp Hahn wrote: > 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 :-( dpkg-buildpackage does support -J in stretch (sta

Re: Debian part of a version number when epoch is bumped

On Fri, 2018-02-09 at 12:01:46 +, Ian Jackson wrote: > Seth Arnold writes ("Re: Debian part of a version number when epoch is > bumped"): > > tar will treat a filename with : in it as a command to connect to a remote > > machine via rsh and execute /etc/rmt remotely: > > ftp://ftp.gnu.org/old-

Re: Debian part of a version number when epoch is bumped

On Fri, 2018-02-09 at 14:35:15 -0500, Jeremy Bicha wrote: > On Fri, Feb 9, 2018 at 2:22 PM, Andrey Rahmatullin wrote: > > On Fri, Feb 09, 2018 at 06:58:49PM +0100, Philipp Kern wrote: > >> If Ubuntu uses an epoch without Debian following that decision, they can > >> never sync with Debian again, i

Re: Debian part of a version number when epoch is bumped

Hi! Given that other parts of the original thread have started to repeat the same that has been discussed in previous referenced discussions, or even within this thread iteration, I've sat down and written a dpkg FAQ entry:

Re: FHS: Where to store user specific plugins / code

On Wed, 2018-02-28 at 18:14:17 -0500, Marvin Renich wrote: > * Ian Jackson [180228 17:45]: > > Georg Faerber writes ("FHS: Where to store user specific plugins / code"): > > > Currently, we allow users to run / execute their own plugins, stored in > > > /etc/schleuder/plugins. Obviously, that's no

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

Hi! On Thu, 2018-03-22 at 12:47:44 +0200, Lars Wirzenius wrote: > On Thu, 2018-03-22 at 09:58 +0100, Andreas Tille wrote: > > I admit I do not agree with this and it was discussed here before. Can > > we please agree that anonscm.debian.org remains a valid URL and stop > > starting another round

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

On Fri, 2018-03-23 at 03:33:48 +0100, Adam Borowski wrote: > apt show $PACKAGE > > There's no need to duplicate the information inside .dsc/.deb and apt > indices. Do you realize that the point of the repository (not apt :) indices is precisely to duplicate all the information from the .dsc/.deb?

Re: New lintian warning: vcs-deprecated-in-debian-infrastructure

On Thu, 2018-03-22 at 23:23:22 +0100, Markus Koschany wrote: > Am 22.03.2018 um 15:40 schrieb Guillem Jover: > > On Thu, 2018-03-22 at 12:47:44 +0200, Lars Wirzenius wrote: > >> On Thu, 2018-03-22 at 09:58 +0100, Andreas Tille wrote: > >>> I admit I do not agree with

RFC: Support for zstd in .deb packages?

Hi! In 2016 Paul Wise mentioned the Zstandard compressor on IRC [Z], and I briefly checked it out as a potential candidate for dpkg (while also mentioning it to Julian Andres Klode who was considering adding lz4 support to apt). At the time it looked like it was not worth it (apt went with lz4), s

Re: RFC: Support for zstd in .deb packages?

On Sat, 2018-04-28 at 19:44:08 +0300, Adrian Bunk wrote: > On Fri, Apr 27, 2018 at 07:02:12AM +0200, Guillem Jover wrote: > >... > > As a replacement for gzip, it would > > definitely make sense, but otherwise I'm not sure I see it. > > The number of package

Re: Dealing with ci.d.n for package regressions

On Fri, 2018-05-04 at 12:08:31 +0100, Ian Jackson wrote: > Ian Jackson writes ("Re: Dealing with ci.d.n for package regressions"): > > I hadn't realissed that _test_ dependencies would trigger retests, as > > well as actual package dependencies. > > Having read Mattia's message, and looking at the

Re: RFC: Support for zstd in .deb packages?

Hi! On Mon, 2018-04-30 at 20:23:15 +, Nick Terrell wrote: > On Fri, 27 Apr 2018, Guillem Jover wrote: > [...] > > * Format stability: Although it's supposedly frozen now, it has > > changed quite often in recent times. AFAIR it was also mentioned at > > least in

Re: RFC: Support for zstd in .deb packages?

Hi! On Fri, 2018-04-27 at 07:02:12 +0200, Guillem Jover wrote: > The following is a quick run-down of the items from [F], not all > being important from Debian's perspective, but being for dpkg's: > * License: Permissive (dual BSD + GPL-2), which makes universal >

Re: packages which have not been rebuild since December 2016

Hi! On Wed, 2018-05-30 at 22:29:24 +0100, Chris Lamb wrote: > > One issue we forgot to mention there is that all binary packages built > > with dpkg < 1.18.17 need to be rebuild. Is that something easy to find > > out with UDD? > > Unless I'm missing something, I don't think that UDD has this. W

Re: Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others

On Fri, 2018-07-20 at 02:18:51 +0200, Marco d'Itri wrote: > On Jul 18, Marco d'Itri wrote: > > Some day it may replace crypt(3), currently provided by glibc: > > https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt > I tried creating a package which would divert libc's lib

Re: Let's start salvaging packages!

Hi! I think the proposal sounds very good in general. I just might see a problem with one of the requirements, which seems open to potential conflict. On Sun, 2018-07-29 at 17:40:49 +0800, Tobias Frost wrote: > Reasons to salvage a package > > A package is eligible f

<    3   4   5   6   7   8   9   10   >