he hook target and you will end up very confused by
why `debhelper` is ignoring your override.
As said in the beginning, the example Simon gave does not have this
problem, so that example should be fine. But be careful with
`dh_listpackages` based conditionals outside override/hook targets.
and then it is too late.
Therefore, I strongly recommend *against* putting it into `devscripts`.
Other than that, I am looking forward to seeing this in sid (and later
stable-backports).
Best regards,
Niels
PS: The `python` dependency of Helmut script is not a deal breaker
itself. We have other bo
Andreas Tille:
Hi Niels,
Am Sun, Jan 05, 2025 at 12:40:54PM +0100 schrieb Niels Thykier:
The "I'll do the job until the second someone else shows up" sounds close to
RFA (Request For Adoption).
Maybe we can do with a variant like OFA (Open For Adoption), which does not
have
Niels Thykier:
Marc Haber:
On Sat, 21 Dec 2024 22:23:19 +0100, Gioele Barabucci
wrote:
This branch of the discussion started by pointing out the fact that some
maintainers _do_ in fact orphan their packages to remove the "feeling of
being responsible", and then go on maintai
ld, it would be combined with
Low NMU Threshold / QA upload semantics for drive-by fixes, since the
maintainer is supposedly not very attached to the package.
Best regards,
Niels
OpenPGP_signature.asc
Description: OpenPGP digital signature
ls!
Best regards,
Niels
OpenPGP_signature.asc
Description: OpenPGP digital signature
Niels Thykier:
Hi,
This is an update on the MBF for `Rules-Requires-Root: no` as the new
default.
Two weeks further down the line with another update. :)
# Qualitative updates:
* I have asked the release team to look into whether we should go ahead
with this for Trixie or wait until
ar without you.
Best regards,
Niels
Alberto Gonzalez Iniesta
modsecurity-apache
tripwire
Benjamin Mako Hill
most
Christoph Biedl
schroot
Davide G. M. Salvetti
witalian
Debian HA Maintainers
heartbeat
Debian X Strike Force
xorg
Ervin Hegedus
modsecurity-apach
Charles Plessy:
Le Sun, Dec 15, 2024 at 09:27:06AM +0100, Niels Thykier a écrit :
We would like [...] that `dpkg` provides defaults [...] if the fields
are omitted from `debian/control`, you get `Priority: optional` and
`Section: unknown` as default in all artifacts (`.dsc`, `.changes`,
and in
https://salsa.debian.org/ftp-team/dak/-/merge_requests/284
My understanding is that the case would be safe, but annoying to the FTP
masters (ending up in NEW for manual reject rather than automatic
reject). Either way, it is a 3-line change.
Best regards,
Niels
OpenPGP_signature.asc
Description: OpenPGP di
g and this change will
no affect that.
* Any tool that reads `Section` and `Priority` from `.deb` files.
The fields will now always be there rather than theoretically
optional.
Best regards,
Guillem and Niels
OpenPGP_signature.asc
Description: OpenPGP digital signature
Michael Biebl:
Hi Niels, hi Guillem,
thanks for the initiative and +1 from my side.
Thanks.
Am 29.11.24 um 11:08 schrieb Niels Thykier:
# The bug template used
What's your proposed timeframe for making the switch? Trixie, Forky, no
targetted release but when bug count is reasonabl
Michael Biebl:
Hi Niels, hi Guillem,
thanks for the initiative and +1 from my side.
Thanks.
Am 29.11.24 um 11:08 schrieb Niels Thykier:
# The bug template used
What's your proposed timeframe for making the switch? Trixie, Forky, no
targetted release but when bug count is reasonabl
elper build systems around
in the archive[1], that in theory could do with this (though they are
probably not worth hunting out - more of "update if they become a
problem"). Then there is `debputy`, but I can have a look at that later
after I have reviewed the patch for `debhelper`.
B
ple:
https://debusine.debian.net/debusine/work-request/57852/
(If you need logs of logs, have a look at the debsuine-rebuild's
"log-download" command to see how it finds the URL).
That is the best I can offer here, so I hope it was useful.
Best regards,
Niels
[ignored-prob
maining failed for other reasons (including running
out of memory on the host, etc.)
The `check-logs` script (attached) has the regexes used for classifying
the logs for the curious.
# Thanks
Thanks to the Debusine team for providing the test infrastructure.
Thanks to Stefano for his rebuild too
would be DEP+1 since
-(-1) is +1. This would also ensure maximum confusion.
To add some real value to this thread. I am fine with the DEP-X variant.
Best regards,
Niels
OpenPGP_signature.asc
Description: OpenPGP digital signature
As it is, "dak ls knot" does list knot/3.3.9-1 as a known version for
sid (rmadison should also show this as the case). It is unclear to me
why, but once you resolve that I think the rest should follow from there.
Best regards,
Niels
[1]:
https://bugs.debian.org/cgi-bin/version.c
migration to fully compliant
SPDX names.
Best regards,
Niels
discussion, so we are clear on it
and also who is the authoritative source for future changes.
In my book, debian-devel consensus gathering is slow and can be quite
draining, so we should not use it for "day-to-day" operational matters.
To me, that implies having a team with authori
am happy to work on the client side of this problem. I already took a
stab at something similar (see [1], currently stuck on getting a single
source of truth data source), so it would fit into the work I am doing
anyway.
Best regards,
Niels
[0]: I mean a dedicated `JSON` or `YAML` file in
Simon McVittie:
On Fri, 02 Aug 2024 at 18:17:52 +0200, Niels Thykier wrote:
Simon McVittie:
In the design that I prototyped, it's declarative, loosely inspired by
the equivalent Gitlab-CI feature:
- the maintainer can write patterns into debian/build-artifacts for
package-specific q
r putting it into
the build helper. I think this boils down to the use-case would be
invoked in practice where exactly the logic goes. But I feel it is again
a problem that is very solvable once we have the infrastructure in-place
and a proper idea of how to play out the use-case.
Dear, sbuild/pbuilder maintainers, feel free to give me a holler on this
and lets fix this with a prototype somewhere.
Best regards,
Niels
butions to Debian will be even more impactful when he can sponsor the
packages he feels are ready.
https://nm.debian.org/process/1305/
[...]
Thanks for supporting Phil. :)
Best regards,
Niels
86
Cheers
Frederic
Thanks for reporting this issue.
I have pushed a fixed for this to main.
I hope you will report any other issues you might discover. Though
please consider using the BTS or salsa for future findings. :)
Best regards,
Niels
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
ant
feedback and I do not see lintian ever "getting there". The
architectural design of lintian has it locked into "high latency
diagnostics-only feedback with no quick fixes" to reduce it into a
"one-liner". In my book that should not be a newcomer facing too
me. I have also included a small section on troubleshooting below
my signature in case it becomes relevant.
I hope you will find this makes Debian packaging files easier to work with!
Best regards,
Niels
# Troubleshooting
A small section on troubleshooting.
## Debugging the language
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
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
ases.
If it turns out full-field demotion is a common case, then debhelper
will support while if it is an unique snowflake case, the manual
substvar fiddling will have to do for that handful of packages.
Best regards,
Niels
[1]: The original debhelper maintainer used "~10 cases in the arch
buckets it wants and therefore everything would "just work"(tm).
Whether collectd should be split might be a relevant conversation but
please take it in a separate thread or in the BTS. Thank you! :)
Best regards,
Niels
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
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
consider if we have a bug that needs
fixing. Not sure we are there yet given a single example (the one in
Colin's email). However, I be interested to know how frequent this
pattern is and whether we therefore should look at fixing this at a
different layer.
Best regards,
Niels
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
record static linking relationships), if any
tool provides such a variable.
Best regards,
Niels
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
king relationship
substvars be less annoying for users and Debian as a whole.
Best regards,
Niels
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. Th
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
quot;-style warning out of it.
Maybe I should just add that feature directly to `dh_assistant`. Then
you can have one more command for your checklist! :D
Best regards,
Niels
out running the full lintian program. Not sure what became of it.
Best regards,
Niels
sed problems at some point. In that sense, there is already
"prior art" for debhelper managing asymmetry between d/control and
DEBIAN/control.
But it
could be dropped in other places (CONTROL in .deb and Packages indices)
as well.
Yes please!
Best regards,
Niels
debian package tooling for the next release that can solve the static
ownership problem, but not the human time/effort part.
Thanks,
~Niels
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
to looking more at my prototype for getting even more
packages buildable with "Rules-Requires-Root: no".
Thanks,
~Niels
n though debhelper is "in sync" between
stable-backports and testing (or even sid at the moment).
Other than that, I think this looks great and I hope this will help make
backporting more smooth.
Thanks,
~Niels
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
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
s for
some repositories, perhaps allow a config option to disable it?
Sounds like a job for (not yet implemented) DEB_BUILD_OPTIONS=notrimdch
(or some other name).
Thanks,
~Niels
s is
likely to be considerably different compared to a *major library change*
(which is what Jonas asked for).
Thanks,
~Niels
* Ensure you do not have anything messing around with debhelper's
internals inside debian/.debhelper. You can break plenty of
features by deleting or changing random files inside that
directory.
* Restore affected fines manually
(read debian/.debhelper/bucket/index for a list of files)
* Run 'rm -fr debian/.debhelper/bucket' to get dh_clean "unstuck".
* Complete a clean of the package.
* Continue what you were doing.
Thanks,
~Niels
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
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
Else we are back to the same problem that Sam
listed with package splits (just with the paths inverted).
That is, a solution based on that plan should also involve a plan for
getting each and every package affected by the usrmerge updated in
bookworm+1.
Thanks,
~Niels
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
plan?
* When is "until" we have a defined plan?
For concrete values of those definitions, I can be convinced to stop
further changes and rollback the systemd / -> /usr change. However, as
long as these definitions are variations of "somebody" or "everyone" or
"the project" and "eventually" or "when it is ready", then I am not
convinced that waiting is the right option.
For now, I will hold on further "/ -> /usr" changes in debhelper, but I
am not convinced that I should actively rollback the changes already made.
Thanks,
~Niels
PS: Guesstimates suggests that there 16.5 months until the transition
freeze assuming the release team keeps the current cadence.
e manager only for
package management purposes.
We’ll look at how this permission can be abused to gain root access to
the machine via a root shell.
"""
(from the "Introduction")
My reading is that "this permission" refers to the "assigned sudo
permissions".
Thanks,
~Niels
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
as it would break during upgrade. The
dpkg version in stable does not support the feature. Which is also why
there is no debhelper feature to support it yet.
Thanks,
~Niels
helper will your problem but there will packages that will
need manual migration. As I see it, there will *not* be "the debhelper
patch to fix them all" - even if there will /some/ debhelper patchers
that will fix "most of them".
Related, I have no intention of supporting / maintaining a rewrite of
"--prefix/PREFIX" parameters to configure/make/cmake or whatever. (Not
saying anyone proposed it - but mentioning it as another "there will
definitely be manual clean up" data point).
~Niels
development* topics.
(emphasis mine).
Best regards,
~Niels
It would be a non-starter for me to maintain
those comments elsewhere simply because wrap-and-sort keeps steam
rolling them into oblivion.
~Niels
ot work.
As I recall, in the doxygen case the "jQuery" is in fact jQuery +
modifications. So it is not even trivial to fix this with symlinking
even if the version "match".
~Niels
eck,
> _OPTIONS > _PROFILES, so I wonder why _PROFILES is favored.
>
>>From Niels' response, I guess one can conclude why this isn't an issue
> for the nodoc case.
>
>> You should read the manpages for more details.
>
> I did, and while _OPTIONS and_PRO
d _PROFILES after
_OPTIONS (as one of many "semi-permanent papercuts" in Debian packaging
that I would like to remove eventually).
~Niels
are deprecated (level 7 in
> use)
The option is documented in "Supported flags in DEB_BUILD_OPTIONS" in
"man 7 debhelper"[2].
The option is intended as a debug aid to detect "soon to be" removed
compat levels in a simple automated fashion (manual review of
codese
rce tree, with debian/ mixing generated and manual
> files.
> - dpkg-dev tools cannot assume the location of the binary package
> to be built, as that depends on the packaging logic and how that
> might drive the various commands.
>
> [...]
>
> Thanks,
> Nie
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
ll.
- I will expose d/tmp by default for now but "parallel" d/tmp-X dirs
are not (they currently require a --destdir to work as it is now).
* d/ are exposed by default for now.
Any other debhelper artifact will move to a new path in a future compat
level (at this stage, we
the fact that technical debt
is doing harm in that it has a cost for our contributors. But at the
same time, I know it is hard to compare objectively to the cost of the
alternatives (such "janitorial uploads to fix technical debts" or
"removals"). If it was easy, we would probably have computed the
optimal trade-off and solved this very old issue long ago. :)
~Niels
then spend a decade
removing it again because it has become obsolete[1].
Lets not add "yet another papercut" to our packaging process.
On the topic of derivatives: I am happy to hear from derivatives that
have different needs for changelog trimming. As mentioned in the d-d
thread, there is Ubuntu which is currently the only one I am aware of.
~Niels
[1] The time spent removing features from debhelper is literally
measured in decades.
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
proach would be
better than a standard ENV variable a la AUTOPKGTEST_ARTIFACTS and some
easy way to declare additional artifacts to be extracted?
I am fine either way, but I could image that the
debian/.build/artifacts will feature interact with e.g.
"dpkg-buildpackage -tc" where a AUTOPKGTEST_ARTIFACTS replacement would not.
~Niels
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
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
ing
the issue so a "non-FTP-team"-member can take a stab at fixing them?
~Niels
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
&
as much as possible in
> favor of pure declarative syntax in the packages. [...]
Hear, Hear!
Bonus points for anyone with a solution *without* maintscripts!
(But in the absence of perfection, a debhelper tool with a autoscript
snippet can do).
Thanks,
~Niels
information is
> stale, but at least previously ftp-master rejects were not based on
> severity, but rather on a hard-coded list of tags maintained by
> ftp-master.
For reference, Russ is correct. For the people curious about the
concrete tags, please see [1].
Thanks,
~Niels
[1] https://ftp-master.debian.org/#lintianrejects
changes with the automatic ones. The
rewrites I propose above and debdry's approach can be combined/composed
(including by adding this feature directly to debdry and have it be the
reference implementation for these rewrites)
Thanks,
~Niels
stemd_enable to enable my template automatically:
>
> dh_systemd_enable has been deprecated,
> dh_installsystemd/dh_installsystemduser need to be used instead.
>
FYI dh_installsystemd does *not* handle templated unit files either (see
#889635).
I do not remember if dh_installsystemduser does off-hand and I did not
check.
Thanks,
~Niels
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).
they produce.
Rewritten as:
"""
My suggestions below will concentrate on XFCE because I use that myself.
Though most of these changes are probably useful to other desktop
environments as well.
"""
(Replace "use" with "tested" if you do not actually use XFCE regularly;
I assumed you did but apologies if I guessed wrong)
This rewrite would have made a world of difference for how I perceived
the email.
Thanks,
~Niels
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
>>
>> "&
ion (the commented lines works around that if re-enabled).
@Vincent: Do you feel something like this would be helpful, useful and
doable? My only reference in the memcached, so the above is tailored to
the above.
Would it help if we could remove the dependency on having a d/changelog
(i.e. make it optional)? I have not fully checked if it is doable, but
I can look into it if it makes sense and if someone wants to help me
test this.
Thanks,
~Niels
es from anything but the latest point
> release of the previous stable release?
>
> My belief is based on the release notes saying that you should upgrade
> to the latest point relesae first.
>
My understanding is that we prefer that upgrade paths works regardless
of which minor version of the stable release you upgrade from (to the
extend possible).
Thanks,
~Niels
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
he latter, please follow up
on the relevant bugs filed by Lucas against lintian to add those tags).
Thanks,
~Niels
vel (which is an addition in my
> lintian fork) is emitted.
>
> L.
>
Here "cdbs" being "a part of cdbs known to use debhelper". At the
moment, these cdbs snippets are (to lintian) known to use debhelper:
* /usr/share/cdbs/1/rules/debhelper.mk
* /usr/share/R/debian/r-cran.mk
Patches/MR are welcome at https://salsa.debian.org/lintian/lintian/ or
in the BTS.
At the moment, the code you are looking for will be:
https://salsa.debian.org/lintian/lintian/blob/master/checks/debhelper.pm#L180
Thanks,
~Niels
ositives due to the number of
false-positive complaints).
Thanks,
~Niels
ies to cover "for" and "foreach" while also being
more strict to prune false positives (C++ templates, Pascal and SQL trip
naive searches for "<>").
This variant still puts us in the 3000 - 4000 results, which (while
being less than half of the original number) is far more than is likely
to be resolved manually in a reasonable time frame.
Thanks,
~Niels
uot;another path with even more spaces"
Which still leaves much to be wanted, but it works.
(Sadly, this is made worse by dh_install and others "splitting" properly
quoted paths because people have started to rely on the argument being
split. The result is that is helpers are inconsistent about how they
handle spaces in arguments and the result is much sadness /o\)
Anyway, hope it helps.
Thanks,
~Niels
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
&
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
d those
> are implemented by external parsers. This means it needs to scan
> the changelog twice, and then parse+output+parse the data from
> the parser. I've already implemented an optimization (to be
> included in dpkg 1.18.2) when forcing the format to be debian,
> that uses a builtin parser, which halves the execution time.
> «dpkg-parsechangelog -Fdebian». I guess I can take this further
> and use the builtin parser whenever the format is debian.
>
To my knowledge, Guillem has implemented an improvement that makes the
default case faster.
Thanks,
~Niels
gaps for
people in the situation you refer to), then we could save time from the
FTP team and distribute it to the people actively working on the packages.
~Niels
it would be fine to have something like this in
dh_installchangelogs enabled by default for Debian changelogs.
Merge requests on salsa welcome.
Thanks,
~Niels
or a
GPL-like license? If not, there should be no need for Built-Using.
Thanks,
~Niels
1 - 100 of 390 matches
Mail list logo
