Sam Hartman:
"Simon" == Simon McVittie writes:
Simon> On Thu, 16 Jan 2025 at 09:38:38 -0700, Sam Hartman wrote:
>> But the meson setup call is in override_dh_auto_configure. I
>> don't know at that point how to figure out of I am building arch
>> all packages.
Simon>
Julien Plissonneau Duquène:
(trimming the Cc: list a bit now that the announcements are done, last
Cc: to #1091394, followup on debian-devel)
Hi Helmut,
Le 2025-01-16 10:18, Helmut Grohne a écrit :
I'm attaching my proof of concept. Would you join forces and turn either
of these PoCs into a
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
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 maintaining these packages.
Its a way to
Hi,
Starting with announcement:
The next dpkg upload will change the default!
The Release Team has accepted the default change as long as we follow it
to the door, which I have every intention to do. :)
With this, we are now entering the endgame for this transition!
# How can you help?
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
Hi,
This is an update on the MBF for `Rules-Requires-Root: no` as the new
default.
# Qualitative updates:
* The bugs have all been filed. Most where filed on Dec 7, but I had
to file 15 special cases manually, which happened Dec 14.
* A number of permission denied issues have been iden
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
Daniel Baumann:
Hi,
both sound good (dropping mandatory priority is nice and consistent,
fixing unknown section behaviour too), thanks!
Thanks for the feedback. :)
ideally these changes would be in dpkg in trixie, but maintainers would
start dropping priority fields *after* trixie so that f
Hi,
Historically, if you omitted `Priority` and `Section` from your
package, `dpkg` would warn and use `-` or `unknown` as placeholder
when it absolutely needed a value for these fields in the `.dsc` and
the `.changes` file. The resulting `.deb` would omit the field.
We would like to change this
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
Helmut Grohne:
Hi Guillem and other developers,
I am one of those who builds a lot of different packages with different
requirements and found that picking a good parallel=... value in
DEB_BUILD_OPTIONS is hard. Go too low and your build takes very long. Go
too high and you swap until the OOM ki
Santiago Vila:
This is awesome work! I hope you can start the MBF soon.
One minor comment:
* 862 failures
- Of these 217 failed with an error related to this change
- The remaining failed for other reasons (including running
out of memory on the host, etc.)
I'd like to look a
Hi
We would like to propose a change in default for `dpkg`, which will
enable `rootless` by default (changing it from "opt-in" to "opt-out").
This would be a considerable milestone bringing us to into 90-99%
territory of removing the need for root (`fakeroot` or otherwise)
in the Debian packaging
Simon Josefsson:
Otto Kekäläinen writes:
[...]
Could you propose a DEP -1 to establish a recommended naming procedure?
Including how to escape negative numbers in the shortened form, for
which I suggest using DEP--1 to avoid confusion with DEP-1.
:)
/Simon
Surely, the short form of DEP--1
Jakub Ružička:
Hello,
I've fixed #1081191 through changelog entry in knot/3.4.0-3 and it's
marked as Done but the bug still blocks knot migration for reasons I
don't understand:
https://qa.debian.org/excuses.php?package=knot
What do I need to do to finally finish migration?
Cheers,
Jakub Ruž
Jonas Smedegaard:
[...]
DEP5 already encourages (but does not require) use of SPDX shortnames,
except where Debian and SPDX disagree on sensible naming.
See https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#spdx
and the historical notes at
https://wiki.debian.org/Proposals/Copy
Helmut Grohne:
Hi fellow developers,
(modified resend, as first attempt didn't arrive)
please allow me to open a can of worms. Package removal from unstable.
Deciding when it is time to remove a package from unstable is difficult.
There may be users still and it is unclear whether keeping the p
Fabio Fantoni:
Il 05/08/2024 03:14, Andrey Rakhmatullin ha scritto:
[...]
Thanks for reply, what I mean is precisely a standard field that points
to a file, inside the package or even an url as already explained can be
very useful in most cases) that contains all the useful information for
c
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
Simon McVittie:
On Fri, 02 Aug 2024 at 16:40:15 +0900, Mattia Rizzolo wrote:
[...]
* decide on a directory name (`./debian/export_artifacts/`?)
* the build process will dump any files that could be interesting to
export in there (no decision if/how to define the structure within
t
Soren Stoutner:
After reading a number of comments to the email below, I thought I would
provide a bit of context for this email and Phil’s excellent work on Mentors.
Recently Phil has taken it upon himself to triage every package that requests
sponsorship on mentors.debian.net. Here is an exam
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
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
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
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
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
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.
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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> 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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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 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,
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
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
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
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
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
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
&
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
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
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
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
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).
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
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
>>
>> "&
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
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
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
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
>
>
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:
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
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
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
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
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
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
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
>>
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
1 - 100 of 384 matches
Mail list logo
