Re: Status of Debian package utility tester

On 2013-04-05 13:37, Paul Tagliamonte wrote: > On Fri, Apr 05, 2013 at 11:56:04AM +0200, Thomas Koch wrote: >> Hi, >> >> as I've posted some minutes ago I'm searching to generate the files in >> debian/ >> and remembered the DPU project[1]. It took me some time to find the blogpost >> again and

Re: alternative debian/rules

On 2013-04-27 18:45, Thorsten Glaser wrote: > Russ Allbery dixit: > >> >That code adds the line ".nr g 2" to the start of cpio.1 and adds it to >> >the package as paxcpio.1.gz. > Incidentally, there is a massive limitation of the debhelper tools: > THEY CANNOT RENAME FILES. > No, not out of the

Re: jessie release goals

On 2013-05-06 14:49, Andreas Beckmann wrote: > Hi, > > now might be the right time to start a discussion about release goals > for jessie. Here are some points that come into my mind right now (and > some were already discussed very recently): > While the ideas themselves are worthwhile, they d

Re: wheezy postmortem re rc bugfixing

On 2013-05-09 00:48, anarcat wrote: > [...] > In fact, I am of the opinion that we should relax the requirements that > the release team systematically review every diff posted during the > freeze, especially if the freeze is going to last almost a year... That > always seemed to me to be an insane

Re: Depends: libfoo:foreign ???

On 2013-05-09 07:56, Paul Wise wrote: > On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote: > >> I just noticed that we have the first amd64 package in the archive that >> has dependencies on :i386 qualified libraries: >> >> Package: teamspeak-client > > It appears that will block it from rea

Re: Depends: libfoo:foreign ???

On 2013-05-09 21:00, Steve Langasek wrote: > [...] > > Sorry for not knowing the answer to this, but does britney support :any > dependencies? These don't require any cross-architecture dependency > resolution, but should be satisfiable within each architecture; britney just > needs to support th

Re: Depends: libfoo:foreign ???

On 2013-05-10 14:48, Ben Hutchings wrote: > On Thu, 2013-05-09 at 08:43 +0200, Niels Thykier wrote: >> On 2013-05-09 07:56, Paul Wise wrote: >>> On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote: >>> >>>> I just noticed that we have the first amd

Re: /bin/sh (was Re: jessie release goals)

On 2013-05-11 20:26, Thorsten Glaser wrote: > Oh, sorry, I forgot, you work for Canonical (which totally explains some > of your writings in the other eMail too, which I’m not going to comment > on). Of course, for *buntu people it’s not about choice. > > Now please take that attitude and go back

Re: /bin/sh (was Re: jessie release goals)

On 2013-05-11 20:53, Thorsten Glaser wrote: > [...] >> that: >> >> """ >> The Debian Project welcomes and encourages participation by everyone. """[1] >> >> That includes Canonical and *buntu. > > … but that doesn’t give either preferential treatment. > I never said that and I never said I took

Re: Release sprint results - team changes, auto-rm and arch status

On 2013-11-28 21:24, Daniel Pocock wrote: > I've found the builds on the less used architectures have been useful > for flushing out unusual bugs, particularly when the code ships with > many test cases and it exposes problems for big endian machines, etc. > > Also, kFreeBSD and HURD are both kind

Re: Release sprint results - team changes, auto-rm and arch status

On 2013-11-29 09:22, Aurelien Jarno wrote: > On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: >> Note that s390x and powerpc could also do with more porters, but at >> this time we are not giving an official warning for them. > > I see on http://rele

Re: Role of Release Goals

On 2013-12-02 23:59, Charles Plessy wrote: > Hi all, > Hi, > am I wrong or among the supporters of the concept of release goals, > there are no members of the release team themselves ? If yes, then > it may be more fruitful to explore alternatives. > I think there are (or, at least, were) som

Re: Release sprint results - team changes, auto-rm and arch status

On 2013-11-29 10:48, Svante Signell wrote: > On Thu, 2013-11-28 at 21:04 +0100, Niels Thykier wrote: >> In this new and exciting update from your Debian Release Team... > >> kFreeBSD was a technology preview, and has not generated enough user >> interest to bring in su

Re: Release sprint results - team changes, auto-rm and arch status

On 2013-11-29 10:27, Stéphane Glondu wrote: > Le 28/11/2013 21:52, Niels Thykier a écrit : >>> [...] >> >> Keeping them around is different from them being considered as release >> architectures (or even just keeping them in testing). Keeping these >> architec

Re: Release sprint results - team changes, auto-rm and arch status

On 2013-12-23 00:54, Dimitri John Ledkov wrote: > On 22 December 2013 16:56, Cyril Brulebois wrote: >> Dimitri John Ledkov (2013-12-22): >>> On 28 November 2013 20:04, Niels Thykier wrote: >>>> * Architecture Status >>>>* ia64 in danger

Re: Bits from the release team (freeze time line)

On 2013-12-26 19:23, Josh Triplett wrote: > On Thu, Dec 26, 2013 at 06:08:03PM +0100, Niels Thykier wrote: >> Britney changes >> === >> >> We have deployed a change in Britney that causes her to pay more >> attention to essential packages. In particula

Re: [DEP 8] About "XS-Testsuite: autopkgtest": time to remove "XS-" ?

On 2013-12-27 17:35, Guillem Jover wrote: > Hi! > > On Fri, 2013-12-27 at 17:41:26 +0900, Charles Plessy wrote: >> the use of autopkgtest as documented in DEP 8 is taking momentum. >> >> How about allowing a "Testsuite" field to replace the "XS-Testsuite" field? > > Last time this came up here, i

Re: Release sprint results - team changes, auto-rm and arch status

On 2013-11-29 04:14, Steve Langasek wrote: > Hi Niels, > Hi Steve, Sorry for the long overdue answer, > On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: >> kFreeBSD was a technology preview, and has not generated enough user >> interest to bring in suffi

Re: Release sprint results - team changes, auto-rm and arch status

On 2014-01-05 08:16, Steve Langasek wrote: > On Tue, Dec 31, 2013 at 10:34:49AM +0100, Niels Thykier wrote: >> [...] > >> On a related note, I suspect a good part of this problem would go away >> if we had an automated tool to deal with the case where a (sid-only) >>

Re: Better pdiff handling for apt

On 2014-01-05 11:40, Vitaliy Filippov wrote: > Hi! > >> (I think a nice efficient compromise method would be Patch-Step-Size: >> 8 8 4 4 4 4 2 2 1, which would only update a lg(diffs) each time you >> updated the packages file, and only require users to download and >> apply a maximum of lg(diffs)

Re: Upcoming switch to ESR24 for iceweasel in stable-security

On 2014-01-18 00:12, Mike Hommey wrote: > On Fri, Jan 17, 2014 at 06:11:29PM -0400, David Prévot wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> Hi, >> >> Le 16/01/2014 17:36, Moritz Mühlenhoff a écrit : >> >>> quick heads up for everyone maintaining xul-ext-* packages: >> >> (CC

Re: Bits from the Release Team: Architecture health check

On 2014-01-30 03:49, Yaroslav Halchenko wrote: > > On Wed, 29 Jan 2014, Niels Thykier wrote: >> * sparc >>- We have seen no improvements. Therefore, out of date >> binaries on sparc will no longer prevent packages from >> migrating to testing and Br

Re: Status of build-arch coverage

On 2014-02-20 18:21, Steve Langasek wrote: > On Thu, Feb 20, 2014 at 12:31:28PM +, Colin Watson wrote: >> On Wed, Feb 19, 2014 at 02:29:45PM -0800, Steve Langasek wrote: >>> Ok. The statistics still seem awfully low to me; but I guess >>> http://people.debian.org/~cjwatson/dhstats.png shows th

Re: anonscm seems to be broken for SVN

On 2014-03-01 21:14, Andreas Tille wrote: > Hi Adam, > > [...] > > Well, I actually do not really the difference. As far as I know both - > specifically anonscm which is verified by lintian - should work and it > does not. > > Kind regards > > Andreas. > Verified is the wrong word here.

Re: Please do not use /run yet

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2011-04-06 13:12, Noel David Torres Taño wrote: >> On Wed, Apr 6, 2011 at 12:18:32 +0200, Reinhard Tartler wrote: >>> On Wed, Apr 06, 2011 at 10:54:53 (CEST), Roger Leigh wrote: As of base-files 6.2 which went into unstable yesterday, we hav

Re: this list archive spoils e-mails + strange Enigmail typos

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2011-05-06 18:52, Stanisław Findeisen wrote: > On 2011-05-06 12:18, Stanisław Findeisen wrote: >> Heh, that's what this question is about. :-) >> >> Restricting certain privileges (like su root) to certain users only >> looks more secure than lett

Re: Lintian auto-rejects

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2011-05-29 17:31, Michael Meskes wrote: > I received an auto-reject because of a lintian error message that, as my > system > says, is correctly overridden. Could anyone please tell me which lintian > version we use to determine auto-rejection an

Re: Debian mailing lists archives as mbox

On 2011-08-04 09:16, Christian PERRIER wrote: > (from soc-coordination) > > Quoting Sukhbir Singh (sukhbir...@gmail.com): >> Hi, >> >> Here is what we implemented during this time, in more detail: >> >> 1. Wrote a script that fetches messages for lists.debian.org from >> Gmane and then creates a m

Bug#636698: O: eclipse-pydev

Package: wnpp Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi I am hereby orphaning eclipse-pydev on behalf of the Java Team. The package has not seen an upload for over 3 years and has been RC buggy a bit longer than that. Should you wish to adopt the package, feel free to

Re: gclcvs: Should this package be orphaned (or removed)?

unmaintained and RC buggy. ~Niels On 2011-08-08 09:43, Niels Thykier wrote: > Package: gclcvs > Severity: serious > > Hi > > I noticed this package have two RC bugs that appears to have gotten > no attention since March and April (repsectively). Furthermore it > was

Re: release goal proposal: enable hardening build flags

On 2011-09-14 00:38, Kees Cook wrote: > Hi, > > I would like to propose a release goal of enabling hardening build flags[1] > for all C/C++ packages in the archive[2]. For Wheezy, specific sub-goals are > being chosen. > > The default flags are almost settled[3], additional subgoals may come > up

Re: release goal proposal: enable hardening build flags

On 2011-09-14 18:36, Kees Cook wrote: > Hi, > > On Wed, Sep 14, 2011 at 08:02:13AM +0200, Niels Thykier wrote: >> I have two questions so far. First what usertag will you be using for >> the bugs (if any)? As far as I can tell, there is not listed on the >> wiki. Sec

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

On 2014-11-28 14:41, Marco d'Itri wrote: > On Nov 28, Svante Signell wrote: > > [...] >> b) New installs should get systemd-sysv as default init with a debconf >> message about alternative init systems. > It would be totally unacceptable to waste the time of every Debian user > with pointless ad

Re: Please respect Freeze Policy

On 2014-12-04 08:46, Bart Martens wrote: > On Wed, Dec 03, 2014 at 10:42:54AM +0100, Didier 'OdyX' Raboud wrote: >> Le mercredi, 3 décembre 2014, 10.20:32 W. Martin Borgert a écrit : >>> Would it be OK to abuse experimental for new upstreams during >>> freeze? >> >> during freezes, where unstable s

dd-list of RC buggy packages affecting Jessie

Hi, As promised in [1], attached you will find two dd-lists of people with RC buggy packages. * The unfixed-rc-dd-list[2] is the list of RC bugs affecting both Jessie and sid. * The unfixed-in-jessie-rc-dd-list[3] is the list of RC bugs fixed in unstable but not in testing. Some of thes

Jessie status: Need more RC bug fixes in unstable

Hi, A quick release update (compared to last week)[1][2]. The executive summary: "We are not fixing RC bugs fast enough to keep the RT busy - please fix RC bugs faster. Thanks!" The long version: * 2 out of 3 known blockers (puppet and libc-bin) got fixed in unstable - puppet is unblocke

Re: debian-devel-requests unresponsive

On 2015-03-17 10:52, Bas van den Dikkenberg wrote: > Hi have tried to unscribe my self from this list 5 times now but now luck. > Can some fix this ? > > > WIth kind regards, > > > Bas van den Dikkenberg > Hi Bas, Have you tried contacting listmas...@lists.debian.org ? ~Niels -- To UNSU

Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)

On 2015-04-04 09:54, Josselin Mouette wrote: > Le jeudi 02 avril 2015 à 19:37 +0200, Esokrates a écrit : >> Hi, >> >> I am particularly interested in automatic debug packages, as the current >> situation is pretty messy imho. I found >> https://wiki.debian.org/AutomaticDebugPackages. >> Does any

Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)

On 2015-04-04 12:58, Esokrates wrote: > On Saturday, April 04, 2015 10:54:09 AM Niels Thykier wrote: >> [...] >>- Trying to get the reproducible team to try it out to see if it >> regresses anything (incl. reproducible builds) > > I guess the ddeb's

Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)

On 2015-04-07 21:10, Niels Thykier wrote: > On 2015-04-04 12:58, Esokrates wrote: >> On Saturday, April 04, 2015 10:54:09 AM Niels Thykier wrote: >> >> [...] >> >> I know predictions are hard, but is there a plan to get things done for the >> next release

Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)

On 2015-04-09 09:25, Esokrates wrote: > On Tuesday, April 07, 2015 10:11:18 PM Niels Thykier wrote: >> [...] > > So mostly that is more a decision making (political) problem, than a > technical > one. It is not entirely clear to me that we any have (major) political issu

Re: Experimental ddeb support in debhelper and lintian

On 2015-04-11 07:14, Niels Thykier wrote: > [...] > >> Stretch is a two year time frame though, which makes me kinda sad. Thanks >> for you effort though, keep up the amazing work! If I understand correctly, >> if >> it would have been something for stretch,

Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)

On 2015-04-04 10:54, Niels Thykier wrote: > On 2015-04-04 09:54, Josselin Mouette wrote: >> Le jeudi 02 avril 2015 à 19:37 +0200, Esokrates a écrit : >>> Hi, >>> >>> I am particularly interested in automatic debug packages, as the current >>> situa

Re: Stetch goal: improvements to testing-proposed-updates / experimental?

On 2015-05-02 08:41, Andreas Tille wrote: > On Wed, Apr 29, 2015 at 09:02:58AM +0200, Joerg Jaspert wrote: >> >>> - during the freeze, uploads to unstable that bump sonames should be held >>> for RM review (or that will otherwise prevent new uploads of other packages >>> to unstable from being sui

Re: Upcoming mass-bug filing: GStreamer 0.10 removal

On 2015-05-13 12:46, Sebastian Dröge wrote: > [...] >> Indeed, asking the release team for a transition tracker for the Gst 0.10 >> removal >> itself might be useful. > > How would I go about that? Just a mail to debian-release or what's the > procedure? > > [...] > > > Sebastian > Please fi

Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)

On 2015-05-03 18:58, Guillem Jover wrote: > Hi! > > On Tue, 2015-04-07 at 22:11:18 +0200, Niels Thykier wrote: >> A) Use ".deb" (i.e. the regular extension) with a new "section". > > Is there any problem with using the existing "debug" section

Re: Experimental ddeb support in debhelper and lintian

On 2015-04-12 05:31, Paul Wise wrote: > On Sat, Apr 11, 2015 at 3:20 PM, Niels Thykier wrote: > >> As noted on IRC, mentors.debian.net / debexpo will probably need to be >> updated too (at least if we go the "ddebs" route). > > debexpo needs a rewrite to a non-d

Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)

On 2015-04-19 19:10, David Kalnischkies wrote: > On Sat, Apr 04, 2015 at 10:54:09AM +0200, Niels Thykier wrote: >> The resulting debs are installable with dpkg -i ( \o/ ). I have not >> tried anything fancy like setting up a local APT mirror and tried to >> convince APT do i

Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)

On 2015-05-02 13:46, David Kalnischkies wrote: > On Fri, May 01, 2015 at 11:46:42PM +0200, Niels Thykier wrote: >> […] ddeb support […] > > +1. \o/ > > >>- apt now properly handles the "pkg:arch" dependency. > > [...] > > I would reve

Status on (experimental) ddeb support in Debian

Here is an updated status on ddeb support in Debian. The big picture: Still not done. Currently we are just waiting for two parties to implement the missing parts. Where are we? = * We seem to have a rough consensus on using the ".deb" extension for ddebs. I have implemented t

Re: Bits from the Stable Release Managers

On 2015-05-26 15:42, Ian Campbell wrote: > [...] > > Perhaps the infrastructure could use something which doesn't clash with > real person usages, e.g. "_$arch-buildd.changes" perhaps? > > (Eventually I mean). > > Ian. > Hi, I believe dak has been changed to not care about the file name, but

Re: Upstream and packaging

On 2015-06-07 14:17, Geert Stappers wrote: > > Hi, > > What about creating a guide line where upstream creates a directory > Packaging where sub directories are like Debian, Ubuntu, Mint, > Redhat, CentOS, Suse and such? > > So Upstream can ship their tar-balls / git repositories with > the pack

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

On 2015-06-15 08:04, Neil Williams wrote: > On Sun, 14 Jun 2015 13:26:26 -0700 > Russ Allbery wrote: > >> Simon McVittie writes: >> >>> This is a recurring (anti-)pattern: >> >>> * an ABI-stable, high-level library, say libhigh0, links to a >>> lower-level library, say liblow0 >>> * we have an

Status on ddeb support in Debian

Niels From fe1277fe3301839d5c8b1d9c7ef518909e1b4277 Mon Sep 17 00:00:00 2001 From: Niels Thykier Date: Sat, 4 Apr 2015 08:45:21 +0200 Subject: [PATCH] Unconditionally enable ddeb-support Signed-off-by: Niels Thykier Conflicts: dh_strip --- dh_strip | 3 ++- 1 file changed, 2 insertions(

Re: Status on ddeb support in Debian

On 2015-06-29 22:00, Jakub Wilk wrote: > * Niels Thykier , 2015-06-29, 18:17: >> * debhelper in unstable can now build ddebs - disabled by default. > > Thanks! > >> - Test with env DH_BUILD_DDEBS=1, but please don't upload ddebs to any >> Debian archive. >

Re: Status on ddeb support in Debian

On 2015-06-29 22:06, Vincent Bernat wrote: > ❦ 29 juin 2015 18:17 +0200, Niels Thykier : > >> * Only known blocker is missing archive/dak support. > > Is any help needed here? > It has been a while since I synchronised with the FTP masters (CC'ed), so things might

Re: Status on ddeb support in Debian

On 2015-06-30 07:14, Paul Wise wrote: > On Tue, Jun 30, 2015 at 12:17 AM, Niels Thykier wrote: > >> * [Derivatives] Please consider upgrading your infrastructure / >>tooling if/where needed. > > A lot of derivatives use reprepro, do you know how that will handle &g

Re: Status on ddeb support in Debian

On 2015-06-30 07:20, Tomas Pospisek wrote: > May I suggest you add: > > What is it? > === > > * ddeb's are Debian packages with the extenstion .ddeb that > contain debugging symbols and are built implicitly. > - A package foo_1.23.deb will receive a corresponding > foo_1.23-dbgsym

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

On 2015-07-19 23:57, Sebastian Andrzej Siewior wrote: > On Sun, Jul 12, 2015 at 07:37:23PM +0200, Guillem Jover wrote: >> Hi! > Hi, > >> Our Large File Support on some 32-bit architectures is a bit poor, and >> this has been going on for a while now: >> >> >>

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

On 2015-07-24 12:19, Jakub Wilk wrote: > * Jonas Smedegaard , 2015-07-23, 21:40: >>> One mistake boost makes is using ":=" instead of plain "=". Contrary >>> to popular belief, the former almost always causes more evaluation of >>> $(shell) stuff, specially when dh is involved. >> Could you elabora

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

On 2015-07-25 10:27, Niels Thykier wrote: > [...] > >> So your ":=" variable will be evaluated 4 times, or 7+N times if you use >> dh. >> >> [...] >> > > It should be doable to reduce the dh side of it to 1+N by caching the > result of make

Replacing ldconfig maintscripts with declarative methods

Hi, Currently, all Debian libraries (is required to) have a call ldconfig in postrm and postinst. I would like to replace that with a declarative method somehow. There are a couple of reasons for this: * Packages without postinst scripts do not need to be "configured" explicitly (because dp

Re: Raising the severity of reproduciblity issues to "important"

On 2015-08-24 21:24, Santiago Vila wrote: > [...] > Hi Santiago, > Making a great percentage of packages in the archive to be "suddenly" > buggy is unacceptable. > I can see where you are coming from. I have to admit that I am personally not too concerned with the severity change. Given it i

Re: Raising the severity of reproduciblity issues to "important"

Hi, On 2015-08-24 22:12, Colin Tuckley wrote: > [...] > Same here, in my view reproducibility is a 'nice to have' it should > *never* be forced on a package. > > We are in the business of packaging upstream software for > distribution. We should not make arbitrary changes to upstream > software

Re: Raising the severity of reproduciblity issues to "important"

Hi, On 2015-08-24 22:06, Matthias Klose wrote: > [...] So what about identifying categories which should be fixed in any > case, and maybe which should have special rules for accelerated NMUs and such? Personally, I find that proposal quite interesting. > Categories would include: > > - runnin

[DDEB] Status on automatic debug packages (2015-08-24)

Hi, Here is the "post-debconf" status on automatic debug packages ("ddebs"). The previous status from 2015-06-29 can be found in [0]. What is it? === * ddebs are Debian packages with the extension .deb that contain debugging symbols and are built implicitly. - A package foo_1.23.deb

Re: [DDEB] Status on automatic debug packages (2015-08-24)

On 2015-08-24 23:28, Steve Langasek wrote: > Hi Niels, > > On Mon, Aug 24, 2015 at 11:12:41PM +0200, Niels Thykier wrote: >> [...] > > I wonder how this list was arrived at. Offhand, I see the libc6-dbg and > python3.5-dbg packages are both in section 'debug'

Re: [DDEB] Status on automatic debug packages (2015-08-24)

On 2015-08-25 11:29, Matthias Klose wrote: > On 08/24/2015 11:12 PM, Niels Thykier wrote: >> * debhelper will be including debug-ids in the control file to make it >>easier to find the necessary debug symbols for a given file. >>- Thanks to paultag for this idea. &

Re: Replacing ldconfig maintscripts with declarative methods

On 2015-08-25 15:12, Ian Jackson wrote: > Niels Thykier writes ("Replacing ldconfig maintscripts with declarative > methods"): >> A possible solution is to replace these scripts with an >> "activate-no-await" trigger (again, no-await to avoid trigger cycles

Re: [DDEB] Status on automatic debug packages (2015-08-24)

On 2015-08-27 14:57, Bastian Blank wrote: > On Mon, Aug 24, 2015 at 11:12:41PM +0200, Niels Thykier wrote: >> * ddebs are Debian packages with the extension .deb that >> contain debugging symbols and are built implicitly. >> - A package foo_1.23.deb will receive a correspo

Re: Replacing ldconfig maintscripts with declarative methods

On 2015-08-29 23:52, Aurelien Jarno wrote: >[...] > >> * The major concern I have, is that "activate"-triggers are done for >>- unpack (is this ok?) >>- configure (ok) >>- remove (ok, assuming it is post-removal) >>- purge (should not be an issue) >>- deconfigure (would be a no

GCC-5 transition will move to testing tonight

Hi, Thanks to Adam, Julien, Jonathan, Matthias, Scott, Simon and many others, we are ready to migrate the bulk of the GCC-5 transition and related sub-transitions to testing tonight. Apologise for the short notice. We expect this to be *mostly* a smooth ride, but there are some caveats: * We w

Re: GCC-5 transition will move to testing tonight

On 2015-09-05 21:25, Niels Thykier wrote: > Hi, > > [...] > We expect this to be *mostly* a smooth ride, but there are some caveats: > > * We will have to remove some packages from testing temporarily > > * A total of 36 (amd64) / 31 (i386) binary packages will beco

Re: GCC-5 transition will move to testing tonight

On 2015-09-05 21:25, Niels Thykier wrote: > [...] > We expect this to be *mostly* a smooth ride, but there are some caveats: > > * We will have to remove some packages from testing temporarily > > * A total of 36 (amd64) / 34 (i386) binary packages will become >uni

Re: julia_1.0.0-1_amd64.changes REJECTED

Sean Whitton: > Hello, > > On Wed 21 Nov 2018 at 06:19PM GMT, Holger Levsen wrote: > >> On Wed, Nov 21, 2018 at 05:57:40PM +, Dimitri John Ledkov wrote: >>> Before we get there, we should first start autoremoving packages from >>> unstable, if we consider rc-buggy in unstable to be unacceptab

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

Hi, In the past 3½ years, several things have been improved and I am therefore taking the liberty of closing this bug against general (remaining issues as I understand it will be in individual packages). In particular, I think we have identified all major issues, solved most of them and triaged/a

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

Hideki Yamane: > Hi, > > On Thu, 03 Jan 2019 11:11:00 +0000 > Niels Thykier wrote: >> * Migrating to "Rules-Requires-Root: no" where possible. > > Is there any plan to set "Rules-Requires-Root: no" for default? > It seems that most of the p

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

Hideki Yamane: > Hi Niels, > > Thanks for your explanation :) > > On Sat, 05 Jan 2019 09:52:00 + > Niels Thykier wrote: >> We are very far from being able to flip the default. There are some >> 800+ packages that need to be updated to follow latest policy &

Re: quilt + dpkg + debhelper: Handling upstream files containing spaces

Mike Gabriel: > Hi all, > > I am a little clueless about the below. I hope that someone can shed > some light or provide a work-around. > > I am currently working on OpenBoard packaging. OpenBoard ships loads of > embedded jquery.* copies of code (and other JS libs, too). > > Those jquery.* et a

Re: Potentially insecure Perl scripts

Ian Jackson: > Ian Jackson writes ("Re: Potentially insecure Perl scripts"): >> Even if we care only about scripts which are part of Debian, rather >> than scripts which people merely expect to run on Debian (and where >> they trust Debian to not blow their leg off), there will probably be >> many

Re: Seeking hardening flag / blhc expoert

Otto Kekäläinen: > So apparently the 'D_FORTIFY_SOURCE=2' is in CPPFLAGS (not read by > cmake) but not in CXXFLAGS (read by cmake)[1]. > > So maybe I should define? > CXXFLAGS=$(CXXFLAGS) $(CPPFLAGS) > You have to with cmake, yes. I believe debhelper carries a similar work around (for CXXFLAGS

Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"

Lucas Nussbaum: > On 16/04/19 at 08:52 +0200, Andreas Tille wrote: >> On Mon, Apr 15, 2019 at 05:35:40PM +0200, Bastian Blank wrote: >>> On Mon, Apr 15, 2019 at 04:55:12PM +0200, Andreas Tille wrote: biococoa (U) does not use Debhelper (no compat level found) (source version:

Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"

Andreas Tille: > Hi again, > > speaking about false positives: > >libhmsbeagle (U) should switch to dh. Current build system: > debhelper (source version: 3.1.2+dfsg-5) > > I have no idea what might have triggered this on the current d/rules > file[1]. > > Kind regards > >

Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"

Andreas Tille: > Hi Niels, > > On Tue, Apr 16, 2019 at 12:54:00PM +0000, Niels Thykier wrote: >>> speaking about false positives: >>> >>>libhmsbeagle (U) should switch to dh. Current build system: >>> debhelper (source version: 3.1.2+d

Re: fixing debian-security-support upgrades from stretch (for good)

Sean Whitton: > Hello, > > On Mon 13 May 2019 at 11:52AM +00, Holger Levsen wrote: > >> [re-sent with debian-release list address corrected...] > > Also resending. Sorry. > >> so there is "#928172 debian-security-support: fails to upgrade from >> 'testing': >> dpkg: error: error executing hoo

Re: Difficult Packaging Practices

Vincent Bernat: > ❦ 28 mai 2019 08:59 +08, Paul Wise : > >>> People using tools like fpm will never get familiar with our tools and >>> will never be contributors. >> >> I enjoyed your blog post about pragmatic packaging using Debian's >> tools instead of fpm, it seems like a good approach if one

Re: Difficult Packaging Practices

Vincent Bernat: > ❦ 28 mai 2019 06:30 +00, Niels Thykier : > >> I.e. with the proper implementation of "make-it-work" (in the lack of a >> better name - maybe something "fetch-and-build"), the following should >> be possible >> >> "&

Re: Debian, so ugly and unwieldy!

Adam Borowski: > On Sun, Jun 09, 2019 at 09:46:37AM +0100, Chris Lamb wrote: >> [...] > >> As others have mentioned, I hope that Debian remains a project that >> makes it evermore welcoming to individuals > > Yeah but one of our core values is "we do not hide problems". I'd rather > lash out an

Re: Debian, so ugly and unwieldy!

Thomas Goirand: > On 6/10/19 8:46 AM, Niels Thykier wrote: >> However, at no point in this, can I understand how highlighting disdain >> for certain people (or what their "title") would help with anything in >> this endeavour (or any other cause for that matter).

Re: dh_systemd_enable and instances of unit-file templates

Andrej Shadura: > Hi, > > On Sat, 6 Jul 2019 at 20:02, Konrad, Martin wrote: >> I'm packaging a logging service for buster. Users typically only need to >> run one instance but power users might want to run multiple instances. >> This sounds like a perfect use case for systemd templates [1] to me

Could we generate d/control instead of working with "assembly level code" directly (was: Re: The noudeb build profile and dh-only rules files)

Simon McVittie: > On Mon, 08 Jul 2019 at 19:23:39 +0100, Colin Watson wrote: > [...] >> If the udeb stanzas in debian/control have "Build-Profiles: ", >> then debhelper will honour that when deciding which packages to build, >> so yes, anything built into debhelper should just work. > > Treating u

Re: Is it the job of Lintian to push an agenda?

Russ Allbery: >> Thanks to this new Lintian tag, the current situation is that packages >> won't pass NEW without a SysV init script (unless a FTP-masters ignore >> this specific tag despite its severity). > I haven't worked on Lintian in several years, so perhaps my information is > stale, but at

Re: dropping Priority field from binary packages for most packages

Ansgar: Hi, could we drop the Priority field from most packages? Most packages use "Priority: optional" and this is just noise in d/control (source package). Tools should just assume "optional" when no other value is set. [...] I would like to drop it pretty much everywhere, most importantly d

Re: Running Lintian against a debian/ directory?

Otto Kekäläinen: Hi! Currently Lintian requires a (source or binary) package to check[1]. However, many of the Lintian source package checks (e.g. spelling of debian/changelog entries) don't strictly depend on anything being built. Is anyone aware of a way to run lintian directly on a debian/ d

Re: Editor extensions to help editing debian/* files?

Otto Kekäläinen: Hi! What editors and extensions are you using to augment your productivity and minimize mistakes when editing debian/* files? I am aware of dpkg-dev-el for Emacs mentioned in the DD reference[1]. I am a big fan of Pulsar[2] and recently found a 'language-debian' plugin for Puls

Re: Editor extensions to help editing debian/* files?

Niels Thykier: [...] Btw, `debhelper` has a `dh_assistant` command that can do some very basic analysis as well. Not sure any of it is useful for editor integration (especially because some of the features requires that it receives the same arguments as `dh` or/and `dh_auto_configure

Re: Editor extensions to help editing debian/* files?

Otto Kekäläinen: Hi! Thanks for the tip, Niels! It would be cool if dh_assistant had some kind of generic command like "dh_assistant validate" which would attempt to introspect all information silently and emit output only if it fails to parse something. That might be an option. The question

Another take on package relationship substvars

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. It is an RC bug (waiting to happen) if you omit ${misc:Depends} or

Re: Another take on package relationship substvars

Simon McVittie: On Thu, 22 Feb 2024 at 19:32:21 +0100, Niels Thykier wrote: I think our package helper tooling should just automatically aggregate all provided substvars of the format ${*:Depends} and append it the Depends field. Rinse and repeat for other relationship fields. I recently

Re: Another take on package relationship substvars

Boyuan Yang: [...] Can we also consider ${*:Built-Using} as typically seen in ${sphinxdoc:Built-Using}? This is another field that people keep forget adding. While missing this field is not severely harmful, having it automatically handled would be beneficial. Thanks, Boyuan Yang Personally,

<    1   2   3   4   >