Simon McVittie:
On Thu, 22 Feb 2024 at 20:43:21 +0100, Niels Thykier wrote:
Simon McVittie:
On Thu, 22 Feb 2024 at 19:32:21 +0100, Niels Thykier wrote:
We could also make unused substvars a hard failure (FTBFS).
I'd prefer not this
Reminder: My proposal only covers ${foo:Depends
IOhannes m zmölnig:
[...]
While I like the idea in general, I wonder how I could override these automatic
additions.
I think there are some packages that even demote `${shlibs:Depends}` to
Recommends.
mfh.her.fsr
IOhannes
I had the same conceptual concern when I originally thought about t
Guillem Jover:
Hi!
On Thu, 2024-02-22 at 19:32:21 +0100, Niels Thykier wrote:
[...]
Right, this is annoying. This was actually brought up some time
ago (2010) in debian-devel as part of #597340. There was not much
reaction at the time (one good, a couple bad).
I reinvented a decade old
Steve Langasek:
Hi Niels,
On Thu, Feb 22, 2024 at 07:32:21PM +0100, Niels Thykier wrote:
[...]
I am omitting Breaks, Conflicts, and Replaces because I am not aware of any
users of these at the moment. I am open to adding them, if there is a strong
use-case.
One generic case that this
Gioele Barabucci:
On 24/02/24 11:26, Bernd Zeimetz wrote:
On Thu, 2024-02-22 at 20:52 +0100, IOhannes m zmölnig wrote:
I think there are some packages that even demote `${shlibs:Depends}`
to Recommends.
Absolutely. collectd for example - otherwise you would install *all*
plugin dependencies w
Hi
It seems the discussion on this topic has settled, so I am now doing a
summary of the discussion as I understand it.
* Generally, the original proposal seems to have been received
favorably at a conceptual level.
* Several people requested the scope to be expanded to extra fields.
Niels Thykier:
Hi
It seems the discussion on this topic has settled, so I am now doing a
summary of the discussion as I understand it.
* Generally, the original proposal seems to have been received
favorably at a conceptual level.
[...]
A follow up on this:
* The proposal is now
tho...@goirand.fr:
[...]
Hi Niels,
Thanks a lot for your work on this, I very much agreed with the premiss that
subst vars were a thing easy to fall into traps. It is a very welcomed
improvement to automate them and avoid mistakes.
Is there a place where you wrote some kind of doc about
Hi
Sent to d-devel and d-mentors, since the members of both lists are the
target audience. If you reply, please consider whether both lists should
see the message (and prune the recipient list accordingly as necessary).
In response to a recent thread on debian-devel about editor support for
Soren Stoutner:
I would like to respectfully disagree will some of the opinions expressed in
this email.
Hi Soren
Not sure if we disagree all that much to be honest. :)
First, I should say that I am painfully aware of how long it takes to run
lintian on large
packages. When working on qt
Andreas Tille:
Hi Niels,
at first sorry for my late answer.
At Thu, May 09, 2024 Niels Thykier wrote:
[...] >> For me, lintian fails in all roles it has. It is not a good tool for
newbies
to get help, since it can only test build artifacts. As an example, your
feedback look is
PICCA Frederic-Emmanuel:
I tried it on one of my package silx
warning: File: ./debian/tests/control:22:14:22:19: It is possible that the value is a
typo of "i386". [Correctable via --auto-fix]
22: Architecture: !i386
It seems wrong to me, the test control file allow !i386
Cheers
Frederi
Russ Allbery:
> The root problem, at least as I understand it, is that the two relevant
> upstreams (and probably lots more) have followed those practices to vendor
> and pin versions of jQuery, and are not regularly updating those pins, so
> the current version in Debian may or may not work.
As I
Russ Allbery:
> Jonas Smedegaard writes:
>
>> Let's see if Debian can agree on a single normalization of 822-ish
>> files. For starters, I disagree that "wrap-and-sort -a" is a suitable
>> normalization, as that will involve re-indentation when keys change.
>> Instead, I propose this as starting
Hi participants,
If you follow up on this thread, then please move it to mailing lists
that are more politically focused such as -vote (given it is a response
to vote).
The topic certainly off-topic for debian-devel, which has the following
tag line for content:
Discussion about *technical de
Johannes Schauer Marin Rodrigues:
> Quoting Michael Biebl (2021-07-19 15:10:42)
>> [...]
>>
>> According to
>> apt-file search -x '^/(lib|bin|sbin)'
>> on my Debian sid/amd64 system, we have 1747 packages shipping 24583
>> files in those directories.
>
> more precisely, on amd64 unstable:
>
> /b
Ludovic Rousseau:
> Hello,
>
> I am fixing Debian bug #990154.
>
> After some work I am able to remove the obsolete conf file using:
> rm_conffile /etc/reader.conf.d/0comments 1.9.3-2~ pcscd
> in debian/pcscd.maintscript
>
> Nice.
> Now I would like to use the method documented in deb-conffiles
Ludovic Rousseau:
> Hello Niels,
>
> Le 08/08/2021 à 09:09, Niels Thykier a écrit :
>> Ludovic Rousseau:
>>> [...]
>>
>> Hi Ludovic,
>>
>> You cannot use that feature yet as it would break during upgrade. The
>> dpkg version in stable does n
Timothy M Butterworth:
> All,
>
> I just ran across this article
> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
> the attacks on Debian 11 and they work successfully giving me a root
> shell prompt.
>
> Tim
>
Hi Tim,
All of the attacks presented assumes that the local
Sam Hartman:
>
> TL;DR: Should we hold off on moving stuff from / to /usr in packages
> until we develop our plan?
> If so, how do we communicate that to people?
>
>> "Russ" == Russ Allbery writes:
>
> Russ> Simon Richter writes:
> >> It is less nonsensical because usrmerge exists,
Sam Hartman:
>>>>>> "Niels" == Niels Thykier writes:
>
> Niels> As I understand it, the issue does not depend on whether
> Niels> "usrmerge" is run before or after installing the "/lib"
> Niels> version of "f
Simon Richter:
> Hi,
>
> On 25.08.21 21:45, Sam Hartman wrote:
>
>> The dpkg maintainer hasn't been happy with the discussions here, and
>> I think facilitating to a level where Guillem is part of the
>> consensus is beyond my skill.
>
> The discussion so far has been around the question whether
Sam Hartman:
>>>>>> "Niels" == Niels Thykier writes:
>
> Niels> If the project consensus of this discussion is aligned with
> Niels> the belief that we should block decentralized volunteer work
> Niels> on the transition, I will r
Niels Thykier:
> Ludovic Rousseau:
>> Hello Niels,
>>
>> Le 08/08/2021 à 09:09, Niels Thykier a écrit :
>>> Ludovic Rousseau:
>>>> [...]
>>>
>>> Hi Ludovic,
>>>
>>> You cannot use that feature yet as it would break durin
G. Branden Robinson:
> Hi folks,
>
> It's been a while since I've done any packaging. I was baffled when
> presented with the following.
>
>dh_clean
> cp: cannot stat
> 'debian/.debhelper/bucket/files/19c12bb2ca19e68724c2854ed0512469518df19b0710cc2011a5ca540810979c':
> No such file or dire
Sandro Tosi:
> and lets use once again numpy: 2 days ago i've uploaded 1.21.5 to
> replace 1.21.4 in unstable. [...]
>
> Regards,
Hi,
If you feel discussing patch releases is worth a topic of its own, I
think we should start a separate thread for that because the process is
likely to be consider
Paul Wise:
On Tue, 2022-09-06 at 07:13 +0200, Gioele Barabucci wrote:
* Packages not meant to be included in Debian (and without access to a
changelog server): Creators that want to preserve the full history can
use the `--no-trim` option to disable the trimming.
Most derivatives aren't going
tcome.
Thanks,
~Niels
On Sat, 4 Aug 2018 21:04:59 +0200 Helmut Grohne wrote:
Hi Niels,
On Sat, Aug 04, 2018 at 08:38:00AM +0000, Niels Thykier wrote:
> On Sat, 7 Jul 2018 11:40:54 +0300 "Yuriy M. Kaminskiy"
> wrote:
> > I think (at least, 'Multi-arch: foreign' *and
Simon McVittie:
On Sat, 08 Oct 2022 at 11:00:30 +0200, Niels Thykier wrote:
On Sat, 7 Jul 2018 11:40:54 +0300 "Yuriy M. Kaminskiy"
wrote:
I think (at least, 'Multi-arch: foreign' *and* 'Architecture' != all)
packages should have explicit parent package arch dep
Jelmer Vernooij:
Hi Lucas,
On Thu, Aug 26, 2021 at 11:39:06AM +0200, Lucas Nussbaum wrote:
[...]
Jelmer, did you already think about that? Is there a way one could help
you?
Reviving this thread that's more than a year old...
[...]
Known issues that still need to be addressed:
* backport
Andrius Merkys:
Hello,
On 2022-12-15 11:20, Filippo Rusconi wrote:
I have uploaded a package yesterday. That package does not have any
dh_auto_test
target in d/rules.
The builds all fail, as described here:
https://buildd.debian.org/status/package.php?p=minexpert2
and I do not understand why.
Package: wnpp
Severity: wishlist
Owner: Niels Thykier
X-Debbugs-Cc: debian-devel@lists.debian.org, ni...@thykier.net
* Package name: debputy
Version : 0.1.1
Upstream Contact: Niels Thykier
* URL : https://salsa.debian.org/debian/debputy/
* License : GPL-2
Simon McVittie:
On Fri, 10 Feb 2023 at 03:18:16 +0100, Johannes Schauer Marin Rodrigues wrote:
Quoting Santiago Vila (2023-02-09 17:32:08)
- No intervention from individual maintainers is required for fixing this, as
we already have a binNMU mechanism which we already use for transitions.
Onc
Simon McVittie:
> [...]
>
> The opentmpfiles and opensysusers packaging will need to arrange to do
> something analogous, most likely in cooperation with dh_installsystemd
> or some other debhelper step for the first two points, and with LSB init
> scripts for the tasks where systemd uses one-shot
Paul Wise:
> On Sat, Feb 1, 2020 at 2:39 PM Niels Thykier wrote:
>
>> * debhelper generate a temporary writable directory for $HOME
>>and $XDG_RUNTIME_DIR plus clear all remaining XDG_* variables.
>>This simplifies packaging of tools that insist on writing to
&
Michael Lustfield:
> [...]
>
> I too would love to engage in a civil discussion about ways to improve the
> situation. Let's start with this-
>
> Why do reviews take so long?
> - The team is tiny
> - Much of the team seems very burned out
> - The ones that are active tend to stick to source or "u
Hideki Yamane:
> On Sat, 1 Feb 2020 15:38:14 +0100
> Niels Thykier wrote:
>> * The "dh-sequence- build-dependency" to replace the
>>"--with " parameter to dh in the debian/rules.
>>- Note that third-party add-ons may not have added the rele
Hideki Yamane:
> On Mon, 10 Feb 2020 21:37:05 +0100
> Niels Thykier wrote:
>> Remember to *remove* "--with python3" from d/rules as well. An explicit
>> "--with python3" will cause issues with Build-Depends-Indep and other
>> conditional usage (e.g. b
Simon McVittie:
Hi :)
> On Mon, 09 Mar 2020 at 10:09:46 +0100, Guillem Jover wrote:
>> We'd like to standardize on a new set of artifact build pathnames
>> for our deb toolchain. These would have the following form:
>>
>> - debian/.build/upstream*
>>
>> These could be used for out-of-tree b
Simon McVittie:
> On Mon, 09 Mar 2020 at 20:45:13 +0100, Niels Thykier wrote:
>> Simon McVittie:
>>> For example, dpkg-buildpackage could perhaps read one glob per
>>> line from debian/artifacts and hardlink matched files (if any) into
>>> debian/.build/a
Control: tags -1 moreinfo
Michael Biebl:
> Package: debhelper
> Version: 12.9
> Severity: wishlist
>
> Hi,
>
Hi,
Thanks for the suggestion. :)
(CC'ing d-devel because I think this is relevant to the discussion there)
> some packages have a very detailed debian/changelog which goes back
> yea
Sean Whitton:
> Hello,
>
> On Sat 04 Apr 2020 at 09:28AM +02, Lucas Nussbaum wrote:
>
>> Well, no, there doesn't seem to be any serious user-visible issues.
>>
>> That's why I keep wondering whether it makes sense to just keep all this
>> technical debt around.
>
> It could be useful to someone,
Sam Hartman:
> 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 friendly for new maintainers.
> So I'd prefer s
Sean Whitton:
> Hello,
>
> On Tue 14 Apr 2020 at 10:54AM +02, Niels Thykier wrote:
>
>> Guillem and I have debated this and come to a solution, which we believe
>> will be able to address the concerns about the path being "hidden". It
>> also enables us to
Guillem Jover:
> 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
> sourc
Hi,
This is a heads up about my intention to remove debhelper compat levels
5 and 6. This is also an intention to do a MFB for this removal now at
severity important, which will be bumped to RC later.
With the current rate of migration as well as the current number of RC
bugs in testing, I expec
Mattia Rizzolo:
> On Sun, Sep 06, 2020 at 10:53:05PM +0200, Christian Kastner wrote:
> [...]
>> Or do dpkg or debhelper apply some kind of mapping logic from _OPTIONS
>> to _PROFILES for the popular options nocheck, nodoc, noopt?
>
> debhelper does. various helpers do things differently with such
Christian Kastner:
> On 2020-09-06 23:27, Mattia Rizzolo wrote:
>> On Sun, Sep 06, 2020 at 10:53:05PM +0200, Christian Kastner wrote:
>> The thing is, according to the build profile spec, if you specify nodoc
>> or nocheck in _PROFILES you *MUST* also specify it on _OPTIONS (talking
>> about when y
Neil Williams:
> On Sat, 16 Jul 2016 23:04:51 +0300
> Shachar Shemesh wrote:
>
>> Another question I have is regarding packaging. The Policy suggests
>> that libargtable2-doc should install the docs
>> to /usr/share/doc/libargtable2. It seems that debhelper is not a
>> friend in that regard, push
Martin Michlmayr:
> * ni...@thykier.net [2016-08-17 22:05]:
>> 2020), please respond with a signed email containing the following
>> before Friday, the 9th of September:
>
> Can you please specify where to respond to? I don't think dozens of
> emails to -ports and -devel make any sense.
>
Ah,
Kurt Roeckx:
> On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
>> * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>>also apply to this port? [0]
>
> If -fPIE is the default will -fPIC override it?
>
> It will also default to tell the linker to use
Guus Sliepen:
> On Fri, Aug 26, 2016 at 09:47:39PM +0200, Adam Borowski wrote:
> [...]
> Possible things this tool could do:
>
> - Notify about orphaned packages the DD is using
> - Notify about installed packages with RC bugs
> - Notify about installed packages with RFH/RFA bugs
> [...]
>
Aren'
Ian Jackson:
> Holger Levsen writes ("Re: removal instead of orphaning?"):
>> Maybe a solution would be a third kind of maintainer/uploader, so
>> people could indicate that they are happy to do house-cleaning work on
>> this package, even though they are not apt to maintain it properly.
>>
>>
Aurelien Jarno:
> On 2016-08-17 22:05, ni...@thykier.net wrote:
>> Hi,
>>
>> Like last release, we are doing a roll call for porters of all release
>> architectures. If you are an active porter behind one of the [release
>
Hi,
Apologies for the tardiness on my part for this.
> Does it really c
ni...@thykier.net:
> Hi,
>
> Like last release, we are doing a roll call for porters of all release
> architectures. If you are an active porter behind one of the [release
> architectures] for the entire lifetime of Debian Stretch (est. end of
> 2020), please respond with a signed email containin
Mathieu Malaterre:
> Hi all,
>
> [...]
>
> [Let's assume that we can't find a powerpc porter in time for Stretch.]
>
> 1. Will `powperpc` automatically be downgraded to simple port ? Or is
> this also not automated and the port may simply be removed (eg. sparc)
> ?
> 2. Apart from loosing the au
John Paul Adrian Glaubitz:
> On 09/30/2016 06:08 PM, Niels Thykier wrote:
>> I strongly /suspect/ that "no porters" for powerpc will imply the
>> removal of powerpc for Stretch. It may or may not be moved to ports
>> (assuming someone is willing to support it there)
Niels Thykier:
> [...]
>
> As for "porter qualification"
> =
>
> We got burned during the Jessie release, where a person answered the
> roll call for sparc and we kept sparc as a release architecture for
> Jessie. However, we end
Hi,
Slightly overdue, we have created a survey for the Stretch artwork.
Please cast your vote at:
*
https://surveys.larjona.net/index.php?r=survey/index&sid=926823&lang=en_us
* Please be nice and vote only once!
The survey closes: 2016-10-19 23:59 UTC
Thanks,
~Niels
signature.asc
Descrip
Martin Zobel-Helas:
> Hi,
>
> On Mon Oct 03, 2016 at 22:02:00 +0000, Niels Thykier wrote:
>> Hi,
>>
>> Slightly overdue, we have created a survey for the Stretch artwork.
>>
>> Please cast your vote at:
>> *
>> https://surveys.larjona
Vlad Orlov:
> Hi all,
>
Hi :),
I am moving this to debian-release with the MATE packaging team as CC.
(Also BCC'ed to debian-devel@lists.debian.org)
> I'm one of the upstream developers of MATE desktop environment. Current
> version, 1.16, just reached Unstable and should make it into Testing s
Thomas Pierson:
> Hi,
>
> On 04/10/2016 00:02, Niels Thykier wrote:
>> https://surveys.larjona.net/index.php?r=survey/index&sid=926823&lang=en_us
>> * Please be nice and vote only once!
>
> I just vote. Thanks to the artists for all these propositions.
>
W. Martin Borgert:
> On 2016-10-12 21:41, Vincent Bernat wrote:
>> ❦ 12 octobre 2016 18:54 CEST, Martín Ferrari :
>>> I had always understood that rebuilding from source was a hard
>>> requirement. Is this not the case any more?
>>
>> This has never been the case. Since the beginning, there was n
Mike Hommey:
> On Thu, Oct 13, 2016 at 05:48:00AM +0000, Niels Thykier wrote:
>> [...]
>> This should happen on its own as people convert their packages to
>> debhelper compat 10.
>
> which is not possible for everyone who cares about backporting their
> packages
Hi,
We are very excited to announce that the default theme for Stretch is:
~~~ softWaves ~~~
Many thanks to all the artists and all who voted. :) For the full
announcement, please v
Marc Haber:
> On Sat, 5 Nov 2016 13:46:16 +0100, Sebastiaan Couwenberg
> wrote:
>> [2017-Jan-05] Soft freeze (no new packages, no re-entry, 10-day
>> migrations)
>
> Does this really mean "once you're out, you'll stay out"?
>
> Greetings
> Marc
>
Yes.
Wouter Verhelst:
> On Tue, Nov 08, 2016 at 11:05:59AM +0100, Christian Seiler wrote:
>> 30 days within the deep freeze should be plenty enough - and as I
>> said: if the problem is more complicated, just talk to the release
>> team _while the package is still in testing_.
>
> Let's say I'm on holi
Marc Haber:
> On Wed, 9 Nov 2016 19:45:02 +0100, gregor herrmann
> wrote:
>> I don't quite understand where all this fuzz about auto-removals
>> suddenly comes from. The auto-removals exist since Septemer 2013 [0]
>> and they were also in place for the jessie freeze [1], with the small
>> differen
Marco d'Itri:
> On Nov 14, Lisandro Damián Nicanor Pérez Meyer wrote:
>
>> And yes, I would step back and switch libssl-dev to provide libssl1.0-dev
>> and
>> have libssl1.1-dev around for anyone who can really do the switch.
> I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a
Niels Thykier:
> Marco d'Itri:
>> On Nov 14, Lisandro Damián Nicanor Pérez Meyer wrote:
>>
>>> And yes, I would step back and switch libssl-dev to provide libssl1.0-dev
>>> and
>>> have libssl1.1-dev around for anyone who can really do the switc
Ian Jackson:
> Ian Jackson writes ("Re: OpenSSL 1.1.0"):
> [...]
>
> I was not able to find the message where the release team gave
> permission for the upload of openssl 1.1.x (in particular, the new
> version of libssl-dev) to unstable, that started the transition. [...]
>
> [...]
>
> Ian.
>
Hideki Yamane:
> Hi,
>
> Just a question, sometimes some dependency-broken packages would go into
> repository and apt may complain it. Of course, someone would report it
> and maintainers would fix it soon, but 0 dependency-broken packages is
> best.
>
> Can we integrate piuparts to prevent
Ian Jackson:
> We are running a multitude of services.
>
> [...]
>
> Should we not have public test instances of all these things ?
>
> [...]
>
> My starting points for answers to these questions are something like
> this:
>
> [...]
>
> If we wrote some of this down then infrastructure opera
Jose Gutierrez de la Concha:
> Hi!
>
> I'm upstream developer for zeroc-ice, in one of the packages build from
> this source zeroc-icegridgui, a bug has been reported regarding missing JAR
> dependencies (Bug#846498).
>
> The package in question uses java:depends but that seems to not work here
>
Lucas Nussbaum:
> Hi,
>
> On 28/11/16 at 12:04 +, Ian Jackson wrote:
>> [...]
>
> No.
>
> I think that we should rather push for using tools such as Vagrant or
> Docker to provide a way to easily create development environments for
> services.
>
> [...]
>
> Lucas
>
So I happily agree tha
Josh Triplett:
> [Please CC me on replies.]
>
> [...]
>
> Does it seem reasonable to attempt to introduce these new sections
> before the release, so that these pieces of software in stable can
> successfully work with upcoming sections that will appear in
> testing/unstable/backports?
>
> I'd b
Andreas Metzler:
> [...]
>
> Hello,
>
> No, the encoding was not correct. Compare how you (your MUA) just did it in
> this message with the rejected one.
>
> From: =?UTF-8?Q?TOMAS_MARTI=c5=a0IUS?=
>
> From: =?utf-8?b?VG9tYXMgTWFydGnFoWl1cyA8dG9tYXNAcHVnYS52ZHUubHQ+?=
>
Hi,
The latter i
Niels Thykier:
> Andreas Metzler:
>> [...]
>>
>> Hello,
>>
>> No, the encoding was not correct. Compare how you (your MUA) just did it in
>> this message with the rejected one.
>>
>> From: =?UTF-8?Q?TOMAS_MARTI=c5=a0IUS?=
>>
>>
Russ Allbery:
> [...]
>> I wouldn't have expected that either, but it appeared to be 4-5 times
>> slower than the equivalent code with fork a decompressor, which is why I
>> swapped it out. [I didn't bother to benchmark them, because the
>> differences between them was so stark.]
>
> I've done ext
Ian Jackson:
> Steve Langasek writes ("Re: Auto reject if autopkgtest of reverse
> dependencies fail or cause FTBFS"):
>> [...]
>
> The question is whether marking a test non-blocking should involve the
> release team. I think it should not. It should involve the package
> maintainer (unless th
Ole Streicher:
>>> >> What is the reason not to use automated bug reports here? This would
>>> >> allow to use all the tools the bug system has: severities, reassigning
>>> >> closing etc.
>> >
>> > [...]
> I already don't understand this with the piuparts blocker: we have an
> established workflow
Ian Jackson:
> Santiago Vila writes ("Help requested: Packages which FTBFS randomly"):
>> The following packages FTBFS for me randomly. First column is the bug
>> number, second column is the estimated probability of failure in my
>> build environment, which is described here:
>
> [...]
>
> To th
Andrey Rahmatullin:
> On Mon, Jan 01, 2018 at 08:40:38PM +0100, Jérémy Lal wrote:
>> wouldn't it be simpler to couple debhelper dependency to
>> Standards-Version ?
> There are packages which may break with newer debhelper, but can be easily
> updated to the current policy.
>
Also, there are pack
Andrey Rahmatullin:
> On Mon, Jan 01, 2018 at 05:26:35PM +, Sean Whitton wrote:
>> IMO the point of the field is to ensure that you /don't/ have to upgrade
>> to the latest version of Policy right away. It allows you to keep track
>> of the version of Policy you are up-to-date with, so you can
Jonas Smedegaard:
> Quoting Niels Thykier (2018-01-02 09:23:00)
>> Andrey Rahmatullin:
>>> On Mon, Jan 01, 2018 at 08:40:38PM +0100, Jérémy Lal wrote:
>>>> wouldn't it be simpler to couple debhelper dependency to
>>>> Standards-Version ?
>>>
Sean Whitton:
> Hello,
>
> On Sun, Jan 21 2018, Guillem Jover wrote:
>
>> Ok, there were some comments provided, and some important omissions
>> were spotted. I'm attaching the diff for those changes, which mark now
>> the spec as a stable recommendation with 1.19.0.5.
>
> Sounds like this inva
Jeremy Bicha:
> On Fri, Jan 26, 2018 at 9:38 AM, Andrey Rahmatullin wrote:
>> I wonder what percent of the packages has compat < 10.
>
> Well start with
> https://lintian.debian.org/tags/package-uses-deprecated-debhelper-compat-version.html
>
> Thanks,
> Jeremy Bicha
>
For the curious:
* Dep
Mattia Rizzolo:
> On Thu, Mar 29, 2018 at 03:37:10PM +0100, Ian Jackson wrote:
>> But, Andreas linked to the excuses page (his [1], above) which mention
>> a lot of other architectures, where installability of the dependencies
>> is not relevant. Eg
>> paleomix/s390x unsatisfiable Depends: pytho
clone 886968 -1
retitle -1 debhelper: Make -V the default for dh_makeshlibs
severity -1 wishlist
tags -1 patch
thanks
Emilio Pozuelo Monfort:
> [...]
>
> It's not in policy (but I don't think it has to be), but following the
> conversation on #-ftp yesterday I opened:
>
> #895949 lintian: warn a
Thomas Goirand:
> [...]
>> I'm generally in favor of getting rid of old stuff, but python2 isn't
>> there yet.
>
> Right. But I do believe we need to be very careful to not send a wrong
> message to our users. Debian deprecating Python 2 is good. A strong,
> bold deprecation message is needed, eve
Ian Jackson:
> Paul Gevers writes ("Dealing with ci.d.n for package regressions"):
>> As I just announced on d-d-a¹, we have enabled autopkgtest usage for
>> unstable-to-testing migration.
>
> This is great.
>
> I have some suggestions/observations, looking particularly at
> https://release.deb
Ian Jackson:
> AFAICT we had consensus that by default both the delayer and the
> delayee should get mails about test failures. But I don't think that
> is implemented yet.
>
> I recently found out rather late that a test had failed which was
> important to me. I want to set up a thing to email
Ian Jackson:
> Now that we have autopkgtests blocking testing migration, there is a
> much stronger incentive for people to keep their tests passing in
> testing.
>
s/blocking/delaying/
While it is a goal to get it to a blocking state, we are not there yet.
> If one's tests are broken by an upd
Scott Kitterman:
> [...]
>
> So a maintainer misses one email and anything goes?
>
The maintainer would get no less than two emails AFAICT:
* One when the ITS is filed.
* Another one after 21 days when the maintainer is *explicitly* CC'ed
on the nmudiff for the NMU (that is required to c
Theodore Y. Ts'o:
> On Sun, Aug 05, 2018 at 10:20:38PM +0100, Simon McVittie wrote:
>> On Sun, 05 Aug 2018 at 16:52:46 -0400, Theodore Y. Ts'o wrote:
>>> 1) Am I right in understanding that after modifying or adding any
>>>systemd unit or timer files, I must run "systemctl daemon-reload"?
>>
>>
Bastien ROUCARIES:
> Hi,
>
> They are a few package that FTBFS due to lack of browserify under debian [1]
>
> The most significant point is to render javadoc FTBFS due to lack of
> browserified version of pako a port of zlib to javascript.
>
> I plan to upload browserify soon but browserify is b
Mattia Rizzolo:
> On Thu, Sep 13, 2018 at 11:22:37AM +0100, Ben Hutchings wrote:
>> - Would it make sense to split the changelog, leaving older entries
>> only in the source package? If so, should this be done manually, or
>> would it make sense to have dh_installchangelogs split at some age or
>>
Santiago Vila:
> On Fri, Feb 17, 2017 at 06:23:00AM +0000, Niels Thykier wrote:
>
>> Santiago already brought it up in #844264. I believe my answer in
>> comment 70 is still relevant (other than I incorrectly used "after the
>> freeze" when I meant "aft
Simon McVittie:
> On Fri, 17 Feb 2017 at 18:08:01 -0500, Jeremy Bicha wrote:
>> GNOME 3.24 modules have begun including meson build scripts.
>
> It looks as though Meson approximately follows the Autotools-like
> build pipeline that dh assumes, so something like this should work:
>
> override_dh_
Marc Haber:
> On Mon, 6 Feb 2017 23:01:39 +0100, Dominik George
> wrote:
>> xrdp, a remote desktop server for X.org, has an (upstream) bug that
>> makes it impossible to use it from clients with high resolutions, like
>> 1920x1080.
>
> Is this already filed in Debian? If so, what's the bug number
201 - 300 of 384 matches
Mail list logo
