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: salsa.debian.org: merge requests and such

Hi! On Tue, 2018-11-06 at 15:00:03 +, Matthew Vernon wrote: > Jacob Adams writes: > > The consensus seems to be that people should enable email > > notifications in salsa and open a bug when filing a merge request. > > > > https://lists.debian.org/debian-devel/2018/08/msg00235.html > > > > h

Re: usrmerge -- plan B?

Hi! On Wed, 2018-11-21 at 10:23:46 +0100, Adam Borowski wrote: > with less confidence: > • making usrmerge Essential (large amount of effort, known issues) Oh dear, no, please! First off, as I've said in the past, I have no problem whatsoever with the concept, I think it brings both advantages

Tainted builds (was Re: usrmerge -- plan B?)

Hi! On Wed, 2018-11-28 at 07:52:08 +0500, Alexander E. Patrakov wrote: > Well, the buildd configuration change has been reverted. What worries me now > is that there is a risk not yet mitigated, coming from personal systems of > Debian developers, and we should also check porter boxes. > > As lon

Re: Tainted builds (was Re: usrmerge -- plan B?)

On Wed, 2018-11-28 at 22:13:41 +0500, Andrey Rahmatullin wrote: > On Wed, Nov 28, 2018 at 02:48:32PM -0200, Antonio Terceiro wrote: > > (ischroot(1) is from debianutils which is Essential). > "On GNU/Linux, chroot detection is not possible when not root." I think this was just missed as part of t

Re: Tainted builds (was Re: usrmerge -- plan B?)

On Fri, 2018-11-30 at 05:51:35 +0900, Mike Hommey wrote: > "Only Essential: yes and direct build dependencies installed"? Why not > extend .buildinfo with the list of all packages installed that aren't > Essential:yes or build dependencies? Because that'd have the potential to leak privacy and sec

Re: CTTE decision on vendor-specific patch series (bug #904302)

On Tue, 2018-11-13 at 19:22:09 +0100, Tollef Fog Heen wrote: > Resolution […] > The Committee therefore resolves that: > > 1. Any use of dpkg's vendor-specific patch series feature is a bug for >packages in the Debian archive (including contrib and non-free). > >This should be i

Re: wicd-daemon-run_1.0_amd64.changes REJECTED

On Thu, 2018-11-29 at 13:56:40 -0800, Josh Triplett wrote: > Preferably in a package maintained by someone who actually uses that > daemon with sysvinit, rather than one maintained by someone who doesn't. > (And bugs in the use of that package with sysvinit then belong to that > separate package, w

Re: Tainted builds (was Re: usrmerge -- plan B?)

On Wed, 2018-11-28 at 14:48:32 -0200, Antonio Terceiro wrote: > On Wed, Nov 28, 2018 at 02:57:52PM +0100, Guillem Jover wrote: > > This is actually a great idea! I went ahead and implemented this, see > > attached tentative patch which I'm planning on including in dpkg 1.19.

Re: Tainted builds (was Re: usrmerge -- plan B?)

On Mon, 2018-12-03 at 16:45:15 -0500, Michael Stone wrote: > On Sun, Dec 02, 2018 at 04:28:46PM -0800, Russ Allbery wrote: > > Guillem Jover writes: > > > Whether a package is being built within a chroot or not, has nothing > > > to do with how that installation is be

Re: usrmerge -- plan B?

On Sun, 2018-12-02 at 13:40:05 +0200, Niko Tyni wrote: > On Fri, Nov 23, 2018 at 04:32:17PM +0100, Guillem Jover wrote: > > Please, if we decide we want to do merged /usr, let's do it properly. > > I'm toying with the idea of creating a merged-usr package indicating >

Re: Removing conflicts of init system

Hi! On Fri, 2018-12-21 at 23:57:38 +0100, Thorsten Glaser wrote: > On Fri, 21 Dec 2018, Dmitry Bogatov wrote: > > > I propose to replace current approach with update-alternatives(1) > […] > > Opinions? > No. update-alternatives is too fragile to handle things like > /bin/sh and init(8). While t

Re: call for epoch (was Re: Bug#915553: ITP: pd-csound -- Csound external for Pure Data)

On Tue, 2018-12-04 at 23:22:19 +0100, Adam Borowski wrote: > There already is an epoch, you can't remove it. On the other hand, with the > damage already done, there's little reason not to bump it. I think this is a misconception. It is true that any possibly ugliness will not go away, and increa

Re: Policy and procedures issue: init package hijacked via hostile NMU (declined by maintainers)

Hi! On Sat, 2018-12-22 at 10:11:53 -0800, Josh Triplett wrote: > Please note in the following mail that I'm raising this *exclusively* as a > policy and procedures issue, *not* a technical issue.> > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838480 . Rough > summary of events: I thin

Re: Removing conflicts of init system

On Sat, 2018-12-22 at 20:11:13 +0100, Adam Borowski wrote: > On Sat, Dec 22, 2018 at 05:54:26PM +0100, Guillem Jover wrote: > > On Fri, 2018-12-21 at 23:57:38 +0100, Thorsten Glaser wrote: > > > No. update-alternatives is too fragile to handle things like > > > /bin/sh

Re: Policy and procedures issue: init package hijacked via hostile NMU (declined by maintainers)

On Sat, 2018-12-22 at 21:03:18 +0100, Andreas Henriksson wrote: > (Not sure debian-devel is the right place for this discussion, but > oh well...) Yeah, this should probably have been brought up on debian-project, if at all… > On Sat, Dec 22, 2018 at 08:32:07PM +0100, Guillem Jover wrot

Re: usrmerge -- plan B?

Hi! On Mon, 2018-12-03 at 18:22:03 -0800, Russ Allbery wrote: > Guillem Jover writes: > > The current merged-/usr deployment (via usrmerge or the bootstrapping > > symlink generation before unpack) is a major hack, and bypasses the dpkg > > understanding of the filesystem,

Re: usrmerge -- plan B?

On Sun, 2018-12-23 at 04:06:14 +0100, Guillem Jover wrote: > […] They also imply to permanently suffer the aliasing problems. To expand and clarify a bit on this. We have aliasing in general with symlinks and hardlinks, but those tend to not be as problematic when aliasing the last component,

Re: Policy and procedures issue: init package hijacked via hostile NMU (declined by maintainers)

On Sat, 2018-12-22 at 22:51:37 +, Simon McVittie wrote: > On Sat, 22 Dec 2018 at 22:25:48 +0100, Guillem Jover wrote: > > Procedurally? I guess it was > > OKish, but I guess that's a consequence we get when people involved > > the ctte to muddle the social and proced

Re: usrmerge -- plan B?

On Sun, 2018-12-23 at 16:45:28 +0100, Guillem Jover wrote: > On Sun, 2018-12-23 at 04:06:14 +0100, Guillem Jover wrote: > > […] They also imply to permanently suffer the aliasing problems. > > To expand and clarify a bit on this. We have aliasing in general with > symlinks

Re: Potentially insecure Perl scripts

Hi! On Wed, 2019-01-23 at 14:05:54 +0100, Vincent Lefevre wrote: > I've just reported > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920269 > > against gropdf (also reported upstream to bug-groff), about the use of > the insecure null filehandle "<>" in Perl, which can lead to arbitrary

Re: Potentially insecure Perl scripts

On Thu, 2019-01-24 at 21:08:00 +, Niels Thykier wrote: > Ian Jackson: > > I asked codesearch about > >while.*\<\> > > and got 10780 results. > > I had a similar thought but tried a slightly more complex pattern: > > (while\s*|for(each)?\s*(my)?\s*\$.*)\(.*<>\s*\) > > The pattern also

Re: Namespace for system users

Hi! On Sat, 2019-02-09 at 13:10:27 +0100, Philipp Kern wrote: > at work we have a large fleet of Debian machines, but also more than 200k > user accounts with no reuse and somewhat painful rename experiences. > Obviously an increasing number of accounts leads to a much increased risk of > collisio

Re: Bug#922353: ITP: socket-activate -- Run a socket-activated daemon with minimal dependencies

Hi! On Thu, 2019-02-14 at 17:36:31 -0500, Daniel Kahn Gillmor wrote: > Package: wnpp > Severity: wishlist > Owner: Daniel Kahn Gillmor > > * Package name: socket-activate > Version : 0.1 > Upstream Author : Daniel Kahn Gillmor > * URL : https://gitlab.com/dkg/socket-a

Re: Recreating history of a package

Hi! On Sat, 2019-02-16 at 12:22:04 +, peter green wrote: > 2. Snapshot.debian.org is only offered over plain insecure http. For >recent versions the packages can be verified against the >Packages/Sources files which can in turn be verified with gpg but >older versions are more prob

Re: Bug#922353: ITP: socket-activate -- Run a socket-activated daemon with minimal dependencies

On Fri 2019-02-15 04:34:47 +0100, Guillem Jover wrote: > > Another option would be to implement this in start-stop-daemon, like > > the similar support for the systemd readiness protocol was recently > > implemented there too. > > Thanks for the suggestion! How widely-dis

Re: Bug#922353: ITP: socket-activate -- Run a socket-activated daemon with minimal dependencies

Hi! On Fri, 2019-02-15 at 17:24:24 +0100, Andrej Shadura wrote: > Speaking of which, maybe it would also make sense to merge my changes > in? > > https://bitbucket.org/andrew_shadura/start-stop-daemon-isolate/commits/8646be59e3fde0b22f84a842ef5729a5de08fd3b This being

Re: Tainted builds (was Re: usrmerge -- plan B?)

Hi! On Mon, 2018-12-03 at 18:20:44 -0800, Russ Allbery wrote: > Guillem Jover writes: > > … and then I'm not entirely sure a non-minimal environment should be > > qualified as tainted? For example contrast using a minimal but outdated > > installation to a non-minimal

merged-/usr-via-symlinks damage control (was Re: usrmerge -- plan B?)

Hi! On Tue, 2018-11-20 at 22:16:17 +0100, Adam Borowski wrote: > Thus, it seems to me that the plan A for usrmerge has serious downsides for > dubious benefits. What about the plan B I described above? So, people still seem to be conflating merged-/usr (the filesystem layout) with the different

Re: Unifying logging by default

On Wed, 2019-02-20 at 14:19:02 -0800, Russ Allbery wrote: > Josh Triplett writes: > > While there are *absolutely* configurations in which system > > administrators want to log to arbitrary locations and files, I would > > like to propose that for consistency we should configure software to > > un

Re: Bug#922643: ITP: build-alternative -- helper to build Debian package with diet libc

Hi! On Mon, 2019-02-18 at 19:37:38 +, Dmitry Bogatov wrote: > Package: wnpp > Severity: wishlist > Owner: Dmitry Bogatov > > * Package name : build-alternative > Version : 0.0.1 > Upstream Author : Dmitry Bogatov > * Url : https://salsa.debian.org/kaction/buil

Re: merged-/usr-via-symlinks vs a-different-layout

On Tue, 2019-02-19 at 08:54:12 +0100, Ansgar wrote: > Guillem Jover writes: > > 3) Switching packages to the merged-/usr layout could have been > >accomplished automatically via debhelper for a coverage of around > >99% (?) of the archive. With somethi

Re: merged-/usr-via-symlinks damage control (was Re: usrmerge -- plan B?)

Hi! On Tue, 2019-02-19 at 05:49:24 +0100, Guillem Jover wrote: > So, as part of damage control I'm going to: > > - include the Build-Tainted-By patches into dpkg 1.19.5. Done. > - include a bug-script in dpkg for reportbug to report whether the > system has been

Re: merged-/usr-via-symlinks damage control (was Re: usrmerge -- plan B?)

On Sun, 2019-02-24 at 03:23:09 +0100, Guillem Jover wrote: > On Tue, 2019-02-19 at 05:49:24 +0100, Guillem Jover wrote: > > So, as part of damage control I'm going to: > > > > - include the Build-Tainted-By patches into dpkg 1.19.5. > > Done. > >

Re: merged-/usr-via-symlinks vs a-different-layout

On Sun, 2019-02-24 at 08:27:20 +0100, Ansgar wrote: > Guillem Jover writes: > > You are still conflating the concept with the deployment. The > > underlaying properties of merging /usr is that the contents for > > directories that are present in both / and /usr get merged i

Re: merged-/usr-via-symlinks vs a-different-layout

On Sun, 2019-02-24 at 09:23:14 -0500, Sam Hartman wrote: > >>>>> "Guillem" == Guillem Jover writes: > Guillem> On Sun, 2019-02-24 at 08:27:20 +0100, Ansgar wrote: > >> Guillem Jover writes: > You are still conflating the concept with >

Re: ITP: fossology -- FOSSology is an open source license compliance software system and toolkit.

Hi! On Fri, 2019-03-15 at 20:27:57 +0530, Gaurav Mishra wrote: > Package: wnpp > Severity: wishlist > Owner: Gaurav Mishra > Package name : fossology > Version : 3.4.0 > Upstream Author : Michael Jaeger > URL : https://www.fossology.org/ > License : GPL-2.0-only, LGPL-2.1-only > Pro

Re: first epoch for acme-tiny

Hi! On Sat, 2019-04-06 at 14:11:57 +0100, Samuel Henrique wrote: > In order for that to happen I need to introduce an epoch as we were using > calver and now we have semver, I'm assuming this is a non-controversial > epoch but I need to send this email on d-devel anyway. > > Previous version:

Re: is Wayland/Weston mature enough to be the default desktop choice in Buster?

Hi! On Fri, 2019-04-05 at 16:12:22 +0100, Jonathan Dowland wrote: > I was surprised to learn — by way of synaptic being autoremoved — that > the default desktop in Buster will be GNOME/Wayland. I personally do not > think that Wayland is a sensible choice for the default *yet*; and if > the conseq

Re: SIMDebian: Debian Partial Fork with Radical ISA Baseline

Hi! On Fri, 2019-02-08 at 16:25:41 +, Mo Zhou wrote: > For most programs the "-march=native" option is not expected to bring any > significant performance improvement. However for some scientific applications > this proposition doesn't hold. When I was creating the tensorflow debian > package,

Re: is Wayland/Weston mature enough to be the default desktop choice in Buster?

On Sat, 2019-04-06 at 21:48:57 +0200, Bastian Blank wrote: > On Sat, Apr 06, 2019 at 08:47:51PM +0200, Guillem Jover wrote: > > I don't use GNOME at all, but I tried to switch to Wayland last month > > (from i3 to sway), and sadly the experience lasted only a couple of da

Re: SIMDebian: Debian Partial Fork with Radical ISA Baseline

On Tue, 2019-04-09 at 06:48:59 +, Mo Zhou wrote: > On Sat, Apr 06, 2019 at 10:55:35PM +0200, Guillem Jover wrote: > > If what you are interested in though is just a small subset of the > > archive, another option that would benefit everyone and is perhaps > > less cumb

Re: Bug#927725: Please build with --enable-mmdblookup

On Wed, 2019-04-24 at 04:39:50 -0400, Anthony DeRobertis wrote: > On 4/23/19 5:12 AM, Michael Biebl wrote: > > My main concern is to keep the rsyslog core package reasonably small > > (dependency wise). I think either a new package for this plugin or a conglomerate package with extra stuff sound g

Re: Bug#927725: Please build with --enable-mmdblookup

On Tue, 2019-04-23 at 19:35:50 -0500, John Goerzen wrote: > On Tue, Apr 23 2019, Michael Biebl wrote: > > Am 23.04.19 um 11:12 schrieb Michael Biebl: > >> But splitting each tiny module into a separate package adds significant > >> overhead packaging-wise. > > > > (not to forget NEW round trips) >

Bogus upstream source tarball signature files in the archive

Hi! Some days ago I noticed that uscan is generating bogus upstream tarball signature files when converting them from the ones fetched from upstream. There are several problems, but the main ones are that it will rearmor some of the ASCII armored signatures based on the extension, and that it will

Re: .deb format: let's use 0.939, zstd, drop bzip2

Hi! On Wed, 2019-05-08 at 19:38:26 +0200, Adam Borowski wrote: > First, the 0.939 format, as described in "man deb-old". While still being > accepted by dpkg, it had been superseded before even the very first stable > release. Why? It has at least two upsides over 2.0: I'll try to detangle the

Re: .deb format: let's use 0.939, zstd, drop bzip2

On Sat, 2019-05-11 at 12:08:05 +0100, Ian Jackson wrote: > John Goerzen writes ("Re: .deb format: let's use 0.939, zstd, drop bzip2"): > > Plus, of course, when discussing tar, there is always the "which tar > > format do you mean?" question. > > > > https://manpages.debian.org/stretch/libarchive-

Re: .deb format: let's use 0.939, zstd, drop bzip2

On Fri, 2019-05-10 at 05:18:18 +0200, Guillem Jover wrote: > I'll propose an actual diff I've got here of deb(5) tomorrow, but > otherwise if there are no great concerns, I'd like to start adding > support for this for dpkg 1.20.x. Unfortunately I think I'll have to

dh_testroot usage is still always required (was Re: Do we want to Require or Recommend DH)

On Wed, 2019-05-15 at 09:18:26 +0100, Simon McVittie wrote: > It uses dh_testroot, so it probably can't have Rules-Requires-Root: no, > and needs to be built as (fake)root indefinitely - even though a package > this simple can almost certainly be built correctly without fakeroot. You've mention th

Re: Do we want to Require or Recommend DH

On Mon, 2019-05-13 at 08:33:44 -0400, Sam Hartman wrote: > As promised, I'd like to start a discussion on whether we want to > recommend using the dh command from debhelper as our preferred build > system. So, here's my take on this. I do use debhelper everywhere, I also use dh mostly at work, and

Potentially forking bzip2 (was: Re: Removing bzip2 support from apt due to rustification)

Hi! On Thu, 2019-06-06 at 23:35:28 +0200, Julian Andres Klode wrote: > seeing that Federico Mena Quintero has taken over bzip2 development > and is in the process of porting it to Rust[1], we should consider > removing bzip2 support from apt, dpkg, etc. following the release > of buster. Argh. :(

Re: OpenCL / handling of hardware-specific packages

Hi! On Mon, 2019-07-01 at 22:59:51 +0100, Rebecca N. Palmer wrote: > On 01/07/2019 18:10, Enrico Weigelt, metux IT consult wrote: > > Please don't do that. This IMHO clearly belongs into the operator's > > hands > > Do you mean "not as long as it would cause the above bugs" or "not ever"? > If th

Re: OpenCL / handling of hardware-specific packages

On Tue, 2019-07-02 at 16:40:14 +0200, Petter Reinholdtsen wrote: > [Guillem Jover] > > The closest thing I'm aware of is isenkram, but re-checking it now, it > > looks it's now tailored for hot-plugged hardware? Its README contains > > interesting information on alt

Re: systemd services that are not equivalent to LSB init scripts

On Mon, 2019-07-15 at 12:30:09 +0200, Simon Richter wrote: > On Sun, Jul 14, 2019 at 07:23:31PM +0100, Simon McVittie wrote: > > Some systemd system services are meant to start on-demand via socket > > events (systemd.socket(5)), and can work via inetd on non-systemd-booted > > systems. micro-httpd

Re: default firewall utility changes for Debian 11 bullseye

Hi! On Tue, 2019-07-16 at 11:07:15 +0200, Arturo Borrero Gonzalez wrote: > as you may know, Debian 10 buster includes the iptables-nft utility by > default, which is an iptables flavor that uses the nf_tables kernel > subsystem. Is intended to help people migrate from iptables to nftables. Yeah,

Re: merged-/usr-via-symlinks damage control (was Re: usrmerge -- plan B?)

On Sun, 2019-02-24 at 03:23:09 +0100, Guillem Jover wrote: > On Tue, 2019-02-19 at 05:49:24 +0100, Guillem Jover wrote: […] > > - file a bug on base-installer to request an option to install > > non-broken systems due to merged-/usr-via-symlinks. > > Done. <https:

Re: tag2upload (git-debpush) service architecture - draft

On Thu, 2019-08-01 at 04:37:41 -0700, Sean Whitton wrote: > On Wed 31 Jul 2019 at 10:53PM +01, Rebecca N. Palmer wrote: > > Do "complicated and inconvenient" mean "harder to remember than 'git > > debpush'" (which could equally well be fixed by a local-only script), > > the confusing errors mention

Re: What is the status of cross pkg-configs?

Hi! On Mon, 2019-08-26 at 10:26:24 +0100, Simon McVittie wrote: > On Mon, 26 Aug 2019 at 02:54:29 +0300, Jussi Pakkanen wrote: > > However these prefixed pkg-config executables do not exist e.g. for > > armhf. > > They are meant to be created by a dpkg trigger (as symlinks to > /usr/share/pkg-con

Re: What is the status of cross pkg-configs?

Hi! [ Jussi, you might also want to use the debian-cross mailing list in the future, which I've CCed now. :) ] On Mon, 2019-08-26 at 14:21:54 +0100, Simon McVittie wrote: > On Mon, 26 Aug 2019 at 15:50:52 +0300, Jussi Pakkanen wrote: > > On Mon, Aug 26, 2019 at 1:06 PM Simon McVittie wrote: >

Re: Generating man Pages by help2man can be Problematic when Cross-Compiling, why?

On Tue, 2019-09-03 at 17:45:31 +0500, Andrey Rahmatullin wrote: > On Tue, Sep 03, 2019 at 07:24:30PM +0700, Bagas Sanjaya wrote: > > > For executable programs that take arguments, please consider writing a > > > manual page, rather than expecting users to pass --help or similar. Note > > > that gen

Re: Proposed build profile: noinsttests

Hi! On Wed, 2019-09-04 at 23:16:39 +0200, Helmut Grohne wrote: > On Wed, Sep 04, 2019 at 11:09:27AM +0100, Simon McVittie wrote: > > The "noinsttests" name is inspired by previous discussion (on a bug > > asking for more in some package, if I remember correctly?), > > and by ginsttest-runner in t

Re: Git Packaging Round 2: When to Salsa

On Thu, 2019-09-12 at 15:37:49 +0100, Ian Jackson wrote: > Ansgar writes ("Re: Git Packaging Round 2: When to Salsa"): > > (Using dgit to upload packages is sadly incompatible with best > > practices around packaging.) > > Using dgit to upload packages is best practice. I'm sorry, but "best pract

Re: Git Packaging Round 2: When to Salsa

On Sat, 2019-09-14 at 13:07:09 +0200, Marc Haber wrote: > On Fri, 13 Sep 2019 13:05:20 -0700, Sean Whitton wrote: > > On Thu 12 Sep 2019 at 09:35PM +02, Marc Haber wrote: > > > How about documenting that branches prefixed with "wip" can be force > > > pushed any time and people pulling from those b

Re: Git Packaging Round 2: When to Salsa

On Sun, 2019-09-15 at 00:37:00 +0530, Pirate Praveen wrote: > On 2019, സെപ്റ്റംബർ 15 12:35:18 AM IST, Holger Levsen > wrote: > > I guess because according to https://trends.debian.net/#vcs-hosting > > there's *still*, today, almost 1 source packages in unstable which > > declare they are main

Re: tag2upload (git-debpush) service architecture - draft

On Thu, 2019-08-01 at 16:22:19 +0100, Sean Whitton wrote: > On Thu 01 Aug 2019 at 02:35PM +02, Guillem Jover wrote: > > This argument seems very counter-intuitive. This assumes a > > Debian-archive-centric world-view, where most of the heavy lifting is > > delegated to some

Re: RFC: More C errors by default in GCC 14 (no more implicit function declarations etc.)

Hi! On Tue, 2023-04-18 at 17:54:20 -0500, G. Branden Robinson wrote: > At 2023-04-18T16:07:45+0200, Florian Weimer wrote: > > TL;DR: I want to propose a GCC 14 change which will impact > > distributions, so I'd like to gather some feedback from Debian. > > I would appreciate some discussion on th

Re: 64-bit time_t transition for 32-bit archs: a proposal

Hi! On Tue, 2023-05-16 at 21:04:10 -0700, Steve Langasek wrote: > === Technical details === > > The proposed implementation of this transition is as follows: > > * Update dpkg-buildflags to emit -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 > by default on 32-bit archs.  (Note that this enables L

Re: 64-bit time_t transition for 32-bit archs: a proposal

On Thu, 2023-05-18 at 12:01:40 -0700, Steve Langasek wrote: > On Thu, May 18, 2023 at 03:04:30AM +0200, Guillem Jover wrote: > > On Tue, 2023-05-16 at 21:04:10 -0700, Steve Langasek wrote: > > > === Technical details === > > > > The proposed implementation of

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

Hi! On Fri, 2023-05-19 at 12:42:32 +0100, Steve McIntyre wrote: > Guillem Jover wrote: > >On Thu, 2023-05-18 at 12:01:40 -0700, Steve Langasek wrote: > >> > […], I'm also dubious about this, and introduces a special case > >> > and complexity that does not se

Re: 64-bit time_t transition for 32-bit archs: a proposal

Hi! On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote: > On Fri, May 19, 2023 at 05:34:56AM +0200, Guillem Jover wrote: > > Enabling time64 explicitly is what also had first come to my mind, > > which does not seem too onerous if all the debhelper override > > di

Re: re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy

Hi! On Sat, 2023-06-17 at 11:39:51 +0200, Étienne Mollier wrote: > Martin-Éric Racine, on 2023-06-16: > > Someone filed a bug asking to re-introduce an epoch. > > > > An older fork of the same package back in Wheezy last featured the epoch. > > > > Personally, I'm fine with either marking the bu

Re: 64-bit time_t transition for 32-bit archs: a proposal

ft that can be cleaned up lazily > > What do you think? Yeah, sounds good to me. > On Thu, Jun 08, 2023 at 04:06:08AM +0200, Guillem Jover wrote: > > On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote: > > > > Hmm, rechecking the script, I think we'd want to at le

Re: Policy consensus on transition when removing initscripts.

On Tue, 2023-06-27 at 21:05:57 -0700, Russ Allbery wrote: > Simon Richter writes: > > On 6/28/23 02:31, Russ Allbery wrote: > >> Normally Conflicts is always added with Replaces because otherwise you can > >> have the following situation: > > >> * Package A version 1.0-1 is installed providing fi

Re: systmd-analyze security as a release goal

Hi! On Thu, 2023-07-06 at 18:41:38 +1000, Trent W. Buck wrote: > "Trent W. Buck" writes: > > e.g. I expect "SystemCallArchitectures=native" to break for a lot of > > people (anyone doing dpkg --add-architecture) Yes, see #982456. > Short version: > > • SystemCallArchitectures=native + debian

Re: hardening flags

Hi! On Sat, 2023-07-29 at 16:59:29 +0200, Martin Uecker wrote: > are there any plans to add -fstack-clash-protection to > the hardening flags? See #918914. Thanks, Guillem

Issues in the Patch Tagging Guidelines

Hi! Lately I've been updating metadata in patches in packages I maintain and noticed several issues with the Patch Tagging Guidelines, and after Lucas created the new great patches UDD service [P] and we discussed some other issues there, it looked like the guidelines could do with some fixes and

Re: Potential MBF: packages failing to build twice in a row

Hi! On Wed, 2023-08-09 at 19:55:41 +0200, Johannes Schauer Marin Rodrigues wrote: > I would only consider switching the default if at the same time, some checks > were done that made sure that the result is bit-by-bit identical to the > original. > > The source package is the *input* to sbuild no

Re: Potential MBF: packages failing to build twice in a row

On Wed, 2023-08-09 at 22:10:51 +0200, Johannes Schauer Marin Rodrigues wrote: > Quoting Guillem Jover (2023-08-09 20:55:17) > > I think I've mentioned this before, but dpkg-source is supposed to be > > generating reproducible source packages since around the time dpkg-deb >

Re: Issues in the Patch Tagging Guidelines

Hi! [ Started this some days ago and only finished it now, I see Jonathan has covered some parts of this. ] On Thu, 2023-08-10 at 15:42:03 +0200, Lucas Nussbaum wrote: > On 08/08/23 at 01:25 +0200, Guillem Jover wrote: > > Lately I've been updating metadata in patches in packa

Re: Enabling branch protection on amd64 and arm64

Hi! On Tue, 2023-06-27 at 16:09:40 +0100, Wookey wrote: > On 2023-06-27 16:58 +0200, Moritz Mühlenhoff wrote: > > Am Wed, Jun 21, 2023 at 05:41:36PM +0200 schrieb Emanuele Rocca: > > > On 2022-10-26 08:20, Moritz Mühlenhoff wrote: > > > > I think this should rather be applied early after the Bookw

Re: Enabling -fstack-clash-protection for trixie

Hi! On Sun, 2023-08-06 at 23:25:23 +0200, Moritz Mühlenhoff wrote: > Following the procedure to modify default dpkg-buildflags I propose to > enable -fstack-clash-protection on amd64. The bug for dpkg tracking this > is #918914. > > | -fstack-clash-protection > | Generate code to prevent stack cl

Re: Enabling branch protection on amd64 and arm64

Hi! On Sun, 2023-08-27 at 12:51:53 +0200, Guillem Jover wrote: > On Tue, 2023-06-27 at 16:09:40 +0100, Wookey wrote: > > OK. We're all agreed on that then. Guillem can stick it in the next > > dpkg upload. So this happened, and Johannes reported that this seems to be bre

Re: [idea]: Switch default compression from "xz" to "zstd" for .deb packages

Hi! On Sat, 2023-09-16 at 10:31:20 +0530, Hideki Yamane wrote: > ## More bandwidth > > According to https://www.speedtest.net/global-index, broadband bandwidth > in Nicaragua becomes almost 10x > > - 2012: 1.7Mbps > - 2023: 17.4Mbps Well that page still does not look too great for many othe

Re: Linking coreutils against OpenSSL

Hi! On Thu, 2023-11-09 at 17:38:05 -0500, Benjamin Barenblat wrote: > coreutils can link against OpenSSL, yielding a substantial speed boost > in sha256sum etc. For many years, this was inadvisable due to license > conflicts. However, as of bookworm, coreutils requires GPL-3+ and > OpenSSL is Apac

Re: New Essential package procps-base

Hi! On Tue, 2023-11-14 at 17:29:01 +1100, Craig Small wrote: > What: > Create a new package procps-base. This uses the existing procps source > package and just enable building of pidof. procps-base will be an Essential > package and only contain pidof. > > Why: > This would bring the pidof varia

Re: Signature strength of .dsc

Hi! On Fri, 2023-12-01 at 00:20:16 +, Dimitri John Ledkov wrote: > Currently dak requires signatures on .changes & .dsc uploads. .changes with > signatures are publicly announced and then .dsc are published in the > archive with signatures. .changes references .dsc. > > All .dsc have Checksums

SOP migration (was Re: Reaction to potential PGP schism)

Hi! Daniel thanks for all your work on the OpenPGP working group, and on SOP! :) On Wed, 2023-12-20 at 22:16:28 -0500, Daniel Kahn Gillmor wrote: > # What Can Debian Do About This? > > I've attempted to chart one possible path out of part of this situation > by proposing a minimized, simplified

Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

> are a number of newly-identified packages that fail to compile and have a > > large number of reverse-dependencies. I will continue to work to identify > > false-positives here in the hopes of bringing this count down before pulling > > the trigger on an actual transition. &

Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)

Hi! On Fri, 2024-02-02 at 08:21:57 -0800, Steve Langasek wrote: > Once all of these packages have built in experimental and we have identified > and addressed all adverse interactions with the usrmerge transition, the > plan is: > > - dpkg uploaded to unstable with abi=time64 enabled by default[

Re: Bug#1064082: ITP: golang-github-cheggaaa-pb -- Console progress bar for Golang

Hi! On Fri, 2024-02-16 at 15:07:55 -0800, Loren M. Lang wrote: > Package: wnpp > Severity: wishlist > Owner: Loren M. Lang > * Package name: golang-github-cheggaaa-pb > Version : 3.1.5-1 > Upstream Author : Sergey Cherepanov > * URL : https://github.com/cheggaaa/pb >

Re: Another take on package relationship substvars

Hi! On Thu, 2024-02-22 at 19:32:21 +0100, Niels Thykier wrote: > Our current way of dealing with package relationship substvars such as > ${misc:Depends} has been annoying me for a while. As it is, we are stuck in > this way setup where the "Depends" field in debian/control is de facto > mandatory

Re: Another take on package relationship substvars

Hi! On Thu, 2024-02-22 at 23:14:13 +0100, gregor herrmann wrote: > On Thu, 22 Feb 2024 19:32:21 +0100, Niels Thykier wrote: > > If you forget to add a susbtvars that you should added, it is a latent RC > > bug with only a warning from dpkg-gencontrol that you might miss if you grab > > a coffee wh

Re: time_t progress report

Hi! On Mon, 2024-02-19 at 19:48:38 -0800, Steve Langasek wrote: > I have coordinated with the gcc maintainer so that we can have the default > flags in gcc-13 changed this week. > > We are therefore targeting Friday for the mass NMUs to unstable though there > is a possibility this won't start un

Re: Another take on package relationship substvars

Hi! On Fri, 2024-02-23 at 17:59:14 -0800, Steve Langasek wrote: > One generic case that this doesn't handle is Essential: yes packages. For > many of these, the ${shlibs:Depends} gets promoted in debian/control to > Pre-Depends, not to Depends. Ah! Good point. I think the particular case of the

<    1   2   3   4   5   6   7   8   9   10   >