Heads up: Changes in dpkg-shlibdeps directory search list

[ Please follow up on d-d and d-cross (M-F-T set). ] Hi! There are several cleanups and order changes in the pipe for the default dpkg-shlibdeps shared library directory search list in dpkg 1.18.x. It was previously, in decreasing order of preference: 0. «dpkg-shlibdeps -l» (or via «dh_shlibd

Re: static linking

Hi! On Tue, 2015-05-19 at 18:21:40 +0100, Rebecca N. Palmer wrote: > What's the preferred way to set Built-Using: > http://sources.debian.net/src/chromium-browser/42.0.2311.135-2/debian/control/?hl=82#L82 This one is wrong in two ways, it's missing the exact version, and the field does not belon

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

Hi, On Sun, 2015-06-14 at 01:08:29 +0200, Thomas Goirand wrote: > On 06/13/2015 10:55 AM, Paul Wise wrote: > > On Sat, Jun 13, 2015 at 4:23 PM, Thomas Goirand wrote: > >> I've been using xz compression for a long time, but I see a big defect > >> which is today pushing me to turn it off for the .o

Re: DEB_SIGN_KEYID vs DEBSIGN_KEYID

Hi! On Sun, 2015-06-07 at 10:36:41 +0200, Harald Dunkel wrote: > For devscripts you can define a variable "DEBSIGN_KEYID". For > dpkg it is called "DEB_SIGN_KEYID". git-buildpackage doesn't > support a keyid environment variable at all, as it seems. All > ignore the default-key option set in .gnup

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

Hi! On Sun, 2015-06-14 at 16:48:21 +0200, Vincent Lefevre wrote: > On 2015-06-14 05:46:00 +0200, Guillem Jover wrote: > > On Sun, 2015-06-14 at 01:08:29 +0200, Thomas Goirand wrote: > > > On 06/13/2015 10:55 AM, Paul Wise wrote: > > > > On Sat, Jun 13, 2015 at

Re: Is the Debian dependency system broken? (wget vs libgnutls-deb0-28)

Hi! On Tue, 2015-06-16 at 09:18:34 +0200, Vincent Bernat wrote: > There is not a lot of documentation about how to handle that from an > upstream point of view. There is the info page (section VERSION) of ld > about -version-script. That's true, there's lots of information spread all over the pla

Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide

On Sun, 2015-06-14 at 14:08:24 +0200, Thomas Goirand wrote: > On 06/14/2015 05:46 AM, Guillem Jover wrote: > > Well if you want reproducible output, then use the same tool version. > > That's not possible: Jessie, Sid and Trusty don't have the same version, > and we n

Timezone name in Debian changelog format

Hi! The other day, while fixing some dpkg code, I noticed that the Debian changelog trailer regex intended to support a timezone name inside parenthesis, like this: -- Name Sat, 30 May 2015 03:18:43 +0200 (CEST) is bogus (since its inception in dpkg 1.3.0, 1996-08), and it only accepts one ch

Re: Allowing both cross building and using an alternative compiler

On Tue, 2015-06-16 at 16:07:20 +0100, Wookey wrote: > (Guillem - I was wondering if you had any response to my post on this > therad. I do. > I hope I haven't derailed your progress by asking awkward > questions without really providing solutions. I should really take > your suggestion and try to

Re: Bug#790933: ITP: drive - Google Drive tool

Hi! On Fri, 2015-07-03 at 09:09:42 +0200, Sophie Brun wrote: > Package: wnpp > Severity: wishlist > Owner: Sophie Brun > X-Debbugs-Cc: debian-devel@lists.debian.org > Package name : drive > Version : 0.2.5 > Upstream Author : Emmanuel Odeke

Re: Bug#790399: ITP: structlog -- tructured Logging for Python

Hi! On Wed, 2015-07-01 at 02:58:41 +0100, Filippo Giunchedi wrote: > On Mon, Jun 29, 2015 at 01:56:55PM +0500, Andrey Rahmatullin wrote: > > On Mon, Jun 29, 2015 at 10:22:30AM +0200, Adrien CLERC wrote: > > > Le 29/06/2015 02:51, Filippo Giunchedi a écrit : > > > > * Package name: structlog >

Re: Bug#791857: ITP: daemonize -- tool to run a command as a daemon

Hi! On Wed, 2015-07-08 at 16:45:12 -0400, Sandro Tosi wrote: > Package: wnpp > Severity: wishlist > Owner: Sandro Tosi > > * Package name: daemonize > Version : 1.7.6 > Upstream Author : Brian Clapper, b...@clapper.org > * URL : http://software.clapper.org/daemonize/

LFS status, and enabling it opportunistically on next SONAME bump

Hi! Our Large File Support on some 32-bit architectures is a bit poor, and this has been going on for a while now: (Although this includes some false-positives as reported in #787853.) In addition, the problem is ac

Re: Timezone name in Debian changelog format

Hi! On Fri, 2015-06-26 at 10:56:58 +0200, Santiago Vila wrote: > On Fri, Jun 26, 2015 at 04:40:58AM +0200, Guillem Jover wrote: > > So given that the timezone name has never been accepted, many > > time-parsing functions ignore it, it is redundant, declared obsolete > >

Re: Huge data files in Debian

Hi! On Fri, 2015-07-17 at 12:03:36 -0400, Yaroslav Halchenko wrote: > On Fri, 17 Jul 2015, Ole Streicher wrote: > > But: These packages sum up to ~25 GB, with the maximal package size of > > 3.5 GB. What is the best way to deal with them? Loosely following the > > discussion about the Icedove icon

Bug#793404: massive waste of CPU time in debian/rules by inline commands

Control: block -1 by 793330 Hi! On Thu, 2015-07-23 at 19:43:46 +0200, Eduard Bloch wrote: > Package: general > Severity: minor > The problem: I see lots of $(shell ...) stuff. In boost, there are about > 12 such calls. And they run dpkg-architecture or dpkg-parsechangelogs or > similar commands.

Bug#793404: massive waste of CPU time in debian/rules by inline commands

Control: block -1 by 657390 [ Blocking on that, because there's currently no other such bug. So not to imply this is lintian maintainers sole responsibility. ] Hi! On Fri, 2015-07-24 at 12:19:36 +0200, Jakub Wilk wrote: > dpkg-buildpackage -B will run debian/rules 4 times: once to determine if

Re: LFS status, and enabling it opportunistically on next SONAME bump

Hi! On Tue, 2015-07-21 at 19:00:18 +0200, Niels Thykier wrote: > The tag being experimental is orthogonal to its severity. If you are > interested in seeing it become a non-experimental tag, I can recommend > having a look at writing a patch for #787853. From memory, the > information needed is

Re: Facilitating external repositories

Hi! On Sat, 2015-07-25 at 11:10:25 +0800, Paul Wise wrote: > I would suggest reviewing Ubuntu's solution for adding PPA sources.list > snippets and seeing if we can take any inspiration from it or make our > solution more compatible with it. > > https://help.ubuntu.com/community/Repositories/Ubun

Re: Heads up: Upcoming dpkg-buildpackage -j precedence change

Hi! On Wed, 2015-05-13 at 14:21:54 +0200, Guillem Jover wrote: > On Tue, 2015-05-12 at 10:02:27 +0100, Jonathan Dowland wrote: > > On Mon, May 11, 2015 at 08:40:16PM +0200, Guillem Jover wrote: > > > $ make -jN -f debian/rules build > > > > > > and > &g

Re: Facilitating external repositories

Hi! On Mon, 2015-08-17 at 09:53:17 +0200, Wouter Verhelst wrote: > A repository with a whitelist cannot install packages with names outside > that whitelist. It should also not be able to have packages with > Provides: or Replaces: headers outside that whitelist (so you can't ship > a package that

Re: Improving your archive and package system for small package

Hi! On Thu, 2015-09-03 at 17:28:38 +0200, Adrien CLERC wrote: > This may have been discussed before, but could we achieve something like > this with virtual package? With the implemented version Provides, which means having versioned virtual packages, this is actually probably a good solution, ei

Re: Improving your archive and package system for small package

Hi! On Thu, 2015-09-03 at 13:26:12 -0700, Josh Triplett wrote: > Jonas Smedegaard wrote: > > Seems Osamu Aoki is working on at least part of the puzzle: > > https://bugs.debian.org/797045 > > Merging multiple sources *really* shouldn't be necessary. And the > metadata for those sources will vary

Re: Bug#800093: ITP: libdpkg-parse-perl -- module to parse various dpkg files into Perl Objects

Hi! On Sat, 2015-09-26 at 21:12:57 +0300, Andy Beverley wrote: > Package: wnpp > Owner: Andy Beverley > Severity: wishlist > X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org > > * Package name: libdpkg-parse-perl > Version : 0.03 > Upstream Author : Adam

Re: Bug#800093: ITP: libdpkg-parse-perl -- module to parse various dpkg files into Perl Objects

Hi! On Mon, 2015-09-28 at 12:37:22 +0100, Andrew Beverley wrote: > On Mon, 2015-09-28 at 13:12 +0200, Guillem Jover wrote: > > On Sat, 2015-09-26 at 21:12:57 +0300, Andy Beverley wrote: > > > Package: wnpp > > > Owner: Andy Beverley > > > Severity: wishl

Re: Defaulting to i686 for the Debian i386 architecture

On Thu, 2015-10-01 at 19:15:54 +0200, Matthias Klose wrote: > question to the Hurd and KFreeBSD maintainers ... change that on these > platforms too? As it currently stands, this is not a question when it comes to dpkg, that specific change is all or nothing. The Debian ←→ GNU cpu mapping is globa

Re: Replacing ldconfig maintscripts with declarative methods

Hi! On Mon, 2015-10-05 at 16:14:38 +, Niels Thykier wrote: > As of debhelper/9.20151004, dh_makeshlibs is now using triggers rather > than maintainer scripts to invoke ldconfig. > > * Lintian in untable + testing is already aware of this > * Lintian has /not yet/ been backported. Lintian f

Heads up: New -Wdate-time in default dpkg-buildflags output

Hi! On Tue, 2015-11-10 at 17:32:31 +, Mattia Rizzolo wrote: > As part of the Reproducible Builds effort [0] we added a > "reproducible/timeless" feature area to dpkg which exports -Wdate-time > via CPPFLAGS [1]. > > In our CI infrastructure we enabled that in Spring. > > We now think this is

Re: What is the correct way to set owner to package's files?

Hi! On Wed, 2015-12-30 at 16:46:23 +0300, Konstantin Khomoutov wrote: > Two caveats: > > 1) Be aware that a user "foo" on your build system might have different >UID than the user "foo" on the customer's system, and files' metadata >has owning user and group recorded as a pair of integers

libmd (was Re: Having a single, good arc4random in Debian)

Hi! [ Just posting to debian and fdo mailing lists, but this might be of interest to other distros, please feel free to forward. ] On Mon, 2016-01-18 at 18:25:36 +0100, Marco d'Itri wrote: > On Jan 18, Steven Chamberlain wrote: > > More background information follows. What do others think abo

Re: Having a single, good arc4random in Debian

Hi! On Mon, 2016-01-18 at 09:57:27 -0800, Russ Allbery wrote: > Steven Chamberlain writes: > > I think it would be good for Debian to standardise on a single, good > > arc4random implementation, available to any application that wants to > > use it. > > > I'd like it to become ubiquitous, on all

Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?

Hi! On Tue, 2016-02-02 at 20:23:08 +, Simon McVittie wrote: > On 02/02/16 17:38, Jonathan Dowland wrote: > > I must say that I do not like this proposal. The current situation does > > result > > in under-maintained packages requiring churn, but that's true for many > > aspects > > of them,

Re: libmd (was Re: Having a single, good arc4random in Debian)

Hi! On Tue, 2016-01-19 at 01:18:28 +0100, Guillem Jover wrote: > [ Just posting to debian and fdo mailing lists, but this might be of > interest to other distros, please feel free to forward. ] This still applies. > On Mon, 2016-01-18 at 18:25:36 +0100, Marco d'Itri wrote: >

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

Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

On Sat, 2020-11-14 at 11:15:03 -0800, Vagrant Cascadian wrote: > On 2020-11-14, Sune Vuorela wrote: > > Unfortunately, only like 10% of the relevant packages have test suites > > enabled and run, because gettings things to work reliable is sometimes > > hard. > So, based on your estimate and the c

Bug#974934: RFP: golang-github-ncabatoff-go-seq -- sequence Go values to allow sorting them

Package: wnpp Severity: wishlist * Package name: golang-github-ncabatoff-go-seq Version : 0.0~git20180805.b08ef85-1 Upstream Author : Nick Cabatoff * URL : https://github.com/ncabatoff/go-seq * License : Expat Programming Lang: Go Description : sequence

Bug#974935: RFP: golang-github-ncabatoff-fakescraper -- scrape Prometheus metrics from inside the app

Package: wnpp Severity: wishlist * Package name: golang-github-ncabatoff-fakescraper Version : 0.0~git20201102.4b37ba6-1 Upstream Author : Nick Cabatoff * URL : https://github.com/ncabatoff/fakescraper * License : https://github.com/ncabatoff/fakescraper/issues/

Bug#977164: RFP: golang-github-victoriametrics-metricsql -- standalone PromQL and MetricsQL parser

Package: wnpp Severity: wishlist Tags: patch * Package name: golang-github-victoriametrics-metricsql Version : 0.8.0-1 Upstream Author : VictoriaMetrics * URL : https://github.com/VictoriaMetrics/metricsql * License : Apache-2.0 Programming Lang: Go Descript

Re: Bug#974087: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

Hi! On Mon, 2020-11-16 at 02:33:53 +0100, Guillem Jover wrote: > On Sat, 2020-11-14 at 11:15:03 -0800, Vagrant Cascadian wrote: > > > Adding more hurdles does not help. > > > I think this is a hurdle we do not need. > > > > To me, a one-line change in packagin

Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

On Fri, 2021-01-08 at 19:23:13 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > [snip] > > We did a full archive rebuild testing this change, and I provided > > patches to all known affected packages several months ago. It is a > > one-line change in debian/rules in most cases: > > > > > > ht

Re: Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

having a thought about too. But as a starting point I prepared the attached patch, which sets the variable from dpkg-buildpackage and pkg-info.mk. Once there's agreement on the variable(s), I'm fine merging this, but whether to include this for bullseye would need release-team approval a

Re: move to merged-usr-only?

*Sigh*, replying only now because I find this topic exhausting, draining, tiresome and I'd rather be doing productive stuff instead of rehashing stuff for the nth time. :( Even though I've also tried to document and summarize this in the dpkg FAQ and the dpkg MergedUsr wiki page, but I assume I'm n

Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic

Hi! On Thu, 2021-02-11 at 21:59:42 +0100, Raphaël Hertzog wrote: > Package: general > Severity: normal > User: de...@kali.org > Usertags: origin-kali > X-Debbugs-Cc: hert...@debian.org, debian-d...@lists.debian.org > Control: affects -1 ftp.debian.org dpkg-dev > After having been bitten (in Kali)

Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic

On Fri, 2021-02-12 at 01:05:21 +0100, Mattia Rizzolo wrote: > On Fri, 12 Feb 2021, 12:52 am Guillem Jover, wrote: > > Then there's the problem with changing contents for already seen > > files, which seems like a dak bug. It does not allow to change a > > tarball once it

Re: Questioning debian/upstream/signing-key.asc

Hi! [ Ccing Daniel, as he proposed the shipping of upstream signatures, so leaving full context. ] On Fri, 2021-03-26 at 10:13:25 +0100, Christoph Biedl wrote: > a few days ago, I ran uscan on a package where I knew there was a new > upstream version - just to encounter an validation error sinc

Re: Questioning debian/upstream/signing-key.asc

[ CCing Daniel. ] On Fri, 2021-03-26 at 17:31:16 +0100, Ansgar wrote: > On Fri, 2021-03-26 at 09:06 -0700, Russ Allbery wrote: > > I'm not all that familiar with the intended semantics of OpenPGP key > > expirations, but intuitively I think a signature made before the > > expiration should be cons

Re: Questioning debian/upstream/signing-key.asc

Hi! On Fri, 2021-04-02 at 13:38:51 +0200, Guillem Jover wrote: > On Fri, 2021-03-26 at 10:13:25 +0100, Christoph Biedl wrote: > > However, I uncertain whether is really worth the efforts to maintain > > d/u/s-k, or more precisely, ping maintainers to do so. Personally, I > >

Re: Proposed mass-bug filing: missing support for build-arch or build-indep

Hi! On Mon, 2021-04-19 at 15:11:21 +0200, Lucas Nussbaum wrote: > I would like to propose a mass bug filing on source packages that miss > support for build-arch or build-indep targets in debian/rules. Thanks, that'd be great! > There are currently 411 packages in testing that do not include tho

Re: Epoch bump for kernelshark

On Tue, 2021-05-25 at 20:04:04 -0300, David Bremner wrote: > Mattia Rizzolo writes: > > On Sun, May 23, 2021 at 03:17:10PM -0500, Richard Laager wrote: > >> On 5/23/21 8:34 AM, Sudip Mukherjee wrote: > >> > And, as a result, upstream kernelshark is now at v2.0 but the Debian > >> > packaged versio

Re: Planning for libidn shared library version transition

On Tue, 2021-05-25 at 19:43:21 +0200, Andreas Metzler wrote: > On 2021-05-24 Simon Josefsson wrote: > > Generally, does things looks okay? Specifically, what about the > > Breaks/Replaces/Conflicts? The d/changelog entry? Will the confusing > > 'Replaces: libidn11-dev' for the libidn11 (!) pack

Re: Bug#989068: ITP: object-cloner -- Java Object cloning library with extensible strategies

Hi! On Mon, 2021-05-24 at 20:08:57 -0400, James Valleroy wrote: > Package: wnpp > Severity: wishlist > Owner: James Valleroy > X-Debbugs-Cc: debian-devel@lists.debian.org, jvalle...@mailbox.org > > * Package name: object-cloner > Version : 0.2 > Upstream Author : Kamran Zafar >

Re: What are desired semantics for /etc/shells?

Hi! On Thu, 2021-06-10 at 20:00:02 +0200, Helmut Grohne wrote: > Due to working on installation bootstrap, I was looking into > `/etc/shells`. > > Introduction > > > `/etc/shells` contains valid login shells. Some programs match the configured > shell of a user against this file to

Re: Debian package on Windows

Hi! On Mon, 2016-02-22 at 14:05:33 +, Jonathan Dowland wrote: > [ for -devel: this is a reply to a post to debian-apache, please see > https://lists.debian.org/debian-apache/2016/02/msg4.html ] Inlining parts of that mail here: > On Sat, 20 Feb 2016 01:09:18 +, Eric Mittelette wrot

Re: Archive changes

Hi! On Tue, 2016-03-15 at 15:32:40 -0700, Josh Triplett wrote: > On Tue, Mar 15, 2016 at 11:15:16PM +0100, Joerg Jaspert wrote: > > I've just activated a few changes to the archive we talk(ed) about for a > > long time. And while it is not exactly the start of this release cycle, > > it should sti

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

On Sun, 2016-03-20 at 20:31:13 +, Ben Hutchings wrote: > On Sun, 2016-03-20 at 12:39 -0700, Josh Triplett wrote: > > Leaving aside any other reasons: many packages have a versioned > > dependency on iceweasel, and we don't have versioned provides. > Yes we do, since dpkg 1.18. Actually since

Re: Bug#821066: ITP: glide -- Vendor package management for golang

Hi! On Fri, 2016-04-15 at 13:34:37 +0800, ChangZhuo Chen wrote: > Package: wnpp > Severity: wishlist > Owner: "ChangZhuo Chen (陳昌倬)" > > * Package name: glide There is already an unrelated glide source package in the archive. Which also generates several *glide* binary packages. Namespacing

Time for a .changes file format 2.0?

Hi! Samuel Thibault recently reported in #818618 that the Binary field in the .changes files does not get filtered to only include the binary packages that are being uploaded, as documented in the ancient doc/programming.sgml in dpkg 1.3.3 [P], current debian-policy and now in the dpkg deb-changes

gcc-on-diet (was Re: Seriously, these binaries should be stripped by default)

Hi! On Thu, 2016-04-21 at 18:28:59 +0100, Steve McIntyre wrote: > Control: severity -1 serious > Justification: wasting many megabytes of space and download Yes. > We're shipping broken toolchain packages that are intentionally too > large, and this is causing issues elsewhere. The "netinst" CD

Re: Bug#823052: ITP: python-mkdocs-bootswatch -- Bootswatch themes for MkDocs

Hi! On Sat, 2016-04-30 at 21:57:47 +1000, Brian May wrote: > Would appreciate it if somebody could confirm that the license is BSD > and if so what version of the BSD license this is. > > https://github.com/mkdocs/mkdocs-bootswatch/blob/master/LICENSE That looks like a BSD-2 clause license but w

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

Hi! On Sun, 2016-05-15 at 21:45:55 +0200, Bálint Réczey wrote: > 2016-05-15 20:49 GMT+02:00 Niels Thykier : > > Bálint Réczey: > >> I think making PIE and bindnow default in dpkg (at least for amd64) would > >> be > >> perfect release goals for Stretch. > > > > I support the end goal, but I suspe

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

On Tue, 2016-05-17 at 12:08:09 +0200, Matthias Klose wrote: > I'm not a fan myself for turning on hardening flags in the compiler itself, > but if you do that, then dpkg issues like https://bugs.debian.org/823869 > need to be addressed (whether all obscure build systems picking these up, or > not).

Re: Bug#824130: ITP: libgames-support -- Useful functionality shared among GNOME games

Hi! On Thu, 2016-05-12 at 17:39:57 +0200, Michael Biebl wrote: > Package: wnpp > Severity: wishlist > Owner: Michael Biebl > > * Package name: libgames-support > Version : 1.0.2 > Upstream Author : Michael Catanzaro > * URL : https://wiki.gnome.org/Apps/Games > * Lic

Re: Debian i386 architecture now requires a 686-class processor

Hi! On Tue, 2016-05-10 at 19:17:15 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > On Saturday 07 May 2016 13:23:30 Ben Hutchings wrote: > > Last year it was decided to increase the minimum CPU features for the > > i386 architecture to 686-class in the stretch release cycle. This > > means dr

Re: Debian i386 architecture now requires a 686-class processor

Hi! On Wed, 2016-05-18 at 16:57:48 +, Sune Vuorela wrote: > On 2016-05-18, Julien Cristau wrote: > > Why aren't those bugs RC? That's indeed a good question! It would probably be best if a neutral party would do that. :) > Either we give both users on old hardware a bad experience or all th

Re: PIE and static libraries

uggestions, improvements, wording tweaks, etc. Thanks, Guillem From d3a6f97736bade62a8945f91c22593f22f3e2ae4 Mon Sep 17 00:00:00 2001 From: Guillem Jover Date: Sun, 22 May 2016 19:20:04 +0200 Subject: [PATCH] man: Document interaction between PIE and libraries Prompted-by: Christian Seiler --- man/dpkg-bu

Re: Bug#827678: ITP: pacapt -- Arch's pacman-like package manager for some Unices

Hi! On Sun, 2016-06-19 at 23:44:50 +0800, ChangZhuo Chen wrote: > Package: wnpp > Severity: wishlist > Owner: "ChangZhuo Chen (陳昌倬)" > * Package name: pacapt > Version : 2.3.8 > Upstream Author : Anh K. Huynh > * URL : https://github.com/icy/pacapt > * License

Re: [MBF]: Building arch:all and arch:any without build-{arch,indep} targets

Hi! On Sun, 2016-04-03 at 17:29:32 +, Niels Thykier wrote: > The targets are "officially" mandatory and have been since 3.9.4 > (released in September 2012). Currently lintian and dpkg still forgive > their absence to avoid auto-rejects and FTBFS bugs. > However, Guillem and I would like to

Re: dpkg-genchanges warning for -dbgsym packages

Hi! On Wed, 2016-05-04 at 02:06:56 +0200, Iustin Pop wrote: > I'm very glad for the automatic debug packages, but I wonder if I'm > doing something wrong since I get this warning: > > dpkg-genchanges: warning: package foo-dbgsym listed in files list > but not in control info > > The pa

[MBF] Obsoleting bzip2 compression in .deb packages

Hi! 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 never accepted them. For bzip2 there are currently 31 source packages that produce some

[RFC] Switching dpkg-deb --uniform-compression by default

Hi! I'd like consider switching dpkg-deb --uniform-compression by default, so that both control.tar and data.tar members use the same compression, which currently would be xz (or gzip with -Zgzip). This would give us more uniform and smaller packages. I think the d-i people wanted something like

[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

<    3   4   5   6   7   8   9   >