On 2024-06-25 15:02, Simon McVittie wrote:
> Could we use a container framework that is also used outside the Debian
> bubble, rather than writing our own from first principles every time, and
> ending up with a single-maintainer project being load-bearing for Debian
> *again*? I had hoped that a
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
Owner: Christian Kastner
* Package name: pyevolve
Version : 0.6rc1
Upstream Author : Christian S. Perone
* URL : http://pyevolve.sourceforge.net
* License : PSF
Programming Lang: Python
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: pyrit-cuda
Version : 0.3.0
Upstream Author : Lukas Lueg
* URL : http://code.google.com/p/pyrit/
* License : GPLv3 + linking exceptions for OpenSSL and CUDA
Programming Lang: C, Python
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: liblinear
Version : 1.51
Upstream Author : The LIBLINEAR Project
* URL : http://www.csie.ntu.edu.tw/~cjlin/liblinear/
* License : BSD
Programming Lang: C/C++
Description
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: libocas
Version : 0.93
Upstream Author : Vojtech Franc, Soeren Sonnenburg
* URL : http://cmp.felk.cvut.cz/~xfrancv/ocas/html/
* License : GPL-3
Programming Lang: C
Description
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: pybrain
Version : 0.3
Upstream Author : PyBrain Core Developers
* URL : http://www.pybrain.org/
* License : BSD
Programming Lang: Python
Description : Modular Machine Learning
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: cronie
Version : 1.4.4
Upstream Author : Marcela Mašláňová
* URL : https://fedorahosted.org/cronie/
* License : ISC
Programming Lang: C
Description : Fedora's fork of ISC
On 08/30/2010 09:06 PM, D M German wrote:
>
> After my presentation at DebConf this year I was pointed to your efforts
> on the Patch Tagging Guidelines.
>
> One thing I believe would be useful is if the patch included a
> license. The simplest license would be "Same as patched code" but it
> wi
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: shark
Version : 2.3.2
Upstream Author : Shark Project
* URL : http://shark-project.sourceforge.net/
* License : GPL-2+
Programming Lang: C++
Description : Modular Machine
On 09/29/2010 07:24 AM, Marc Haber wrote:
> This is no longer possible with the machine readable format of
> debian/copyright. Where am I supposed to put this information
> nowadays?
Not that I agree that the information should go in debian/copyright, but
according to DEP5, you could use arbitrar
Hello,
While considering a possible NMU for #589995, the question (in general)
came up whether an otherwise architecture-independent package can be
considered architecture-dependent if its features are only supported on
specific platforms.
As the most simple example, the package contains code th
On 12/22/2010 05:10 PM, Yaroslav Halchenko wrote:
> May be there is a lightweight utility which could be used for
> monitoring, e.g. it would report suspicious actions being taken from
> within a monitored environment? e.g., it would
>
> * sanitize environment variables
> * monitor open/socket/..
Hello,
it was recently pointed out to me that one of my library packages
encountered a build error whilst attempting to backport it to an older
system.
The build failed because I use symbol patterns, specifically c++ tags,
in the package's .symbols file. This feature was introduced in dpkg-1.15.6
On 01/24/2011 04:32 PM, Adam Borowski wrote:
> On Mon, Jan 24, 2011 at 03:02:17PM +0100, Christian Kastner wrote:
>> Hello,
>>
>> it was recently pointed out to me that one of my library packages
>> encountered a build error whilst attempting to backport it to an older
On 02/13/2011 11:50 PM, Patrick Matthäi wrote:
> Am 13.02.2011 23:45, schrieb Steve Langasek:
>> Hi folks,
>>
>> I have a bug report objecting to pam_unix logging all PAM sessions,
>> interactive and non-interactive alike, to syslog. Should pam_unix be
>> dropped from /etc/pam.d/common-session-non
On 2014-06-16 14:01, Thorsten Glaser wrote:
> Russell Stuart debian.org> writes:
>
>> messages. One of the reasons raised for not doing it is some felt
>> uncomfortable carrying around their GPG keys when travelling.
>>
>> My initial reaction was "that's being overly cautious" particularly
>> gi
On 2014-06-17 05:45, Matthias Urlichs wrote:
> Christian Kastner:
>> While that is sadly true, AFAIK all those legislations still require at
>> least good cause, but more usually a court order, to do so.
>>
> You have no legal protection whatsoever on the "internatio
On 2014-08-15 16:16, Raphael Hertzog wrote:
> - pkg/
> (note: git-buildpackage uses debian/ but I find this confusing
> as we then also have the "debian/" prefix for ubuntu or kali uploads, we
> don't need the vendor prefix as the usual versioning rules embed the
> downstream distribution
On 2014-09-03 13:10, Changwoo Ryu wrote:
> 2014-09-03 17:04 GMT+09:00 Simon McVittie :
>> On 02/09/14 21:17, Changwoo Ryu wrote:
>>> For fonts-nanum, the default is ~300 KiB 3.5% larger than -9e. And -9e
>>> is not better than -8e.
>>
>> I don't think anyone is arguing that higher compression setti
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: python-cachetools
Version : 0.6.0
Upstream Author : Thomas Kremmer
* URL : https://github.com/tkem/cachetools
* License : Expat
Programming Lang: Python
Description : extensible
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: librscode
Version : 1.3
Upstream Author : Henry Minsky
* URL : http://rscode.sourceforge.net
* License : GPL-3+
Programming Lang: C
Description : library implementing a Reed
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: gitinspector
Version : 0.3.2
Upstream Author : Ejwa Software
* URL : http://code.google.com/p/gitinspector/
* License : GPL-3+
Programming Lang: Python
Description : statistical
On 10/07/2011 02:28 AM, w...@debian.org wrote:
> The following is a listing of packages for which help has been requested
> through the WNPP (Work-Needing and Prospective Packages) system in the
> last week.
I really missed receiving this weekly update. Great to see it's back!
Christian
--
To
On 2014-12-14 00:36, Guillem Jover wrote:
> On Sat, 2014-12-13 at 23:09:08 +0100, Alexandre Detiste wrote:
>> This is needed to avoid that /etc/cron.allow & /etc/cron.deny disapears
>> when cron is purged but systemd-cron still needs those. (from v1.5.1)
>>
>> In http://anonscm.debian.org/cgit/pkg-
(Alexandre, sorry for the double reply, I only now noticed that my
webmail client did not reply to the list)
On 2014-12-15 12:12, Alexandre Detiste wrote:
>> On the other hand, if the problem is that the upgrade causes a remove,
>> and then some time later the user is going to tidy up by purging c
On 2014-12-15 15:56, Alexandre Detiste wrote:
>> Having various cron daemon implementations follows from their differing
>> designs,
>> but there isn't much design to merely writing out a file to a specific
>> directory securely.
>
> I agree.
>
> bcrontab does special magic and talk to it's dea
On 2015-02-16 13:47, Luke Kenneth Casson Leighton wrote:
> On Mon, Feb 16, 2015 at 11:42 AM, Christian Seiler wrote:
>> Am 16.02.2015 um 02:54 schrieb Luke Kenneth Casson Leighton:
>>>
>>> http://lkcl.net/reports/removing_systemd_from_debian/
>>
>>
>> It's funny that when Wheezy (not Jessie!) came
On 2015-02-16 16:26, Alastair McKinstry wrote:
> On 16/02/2015 14:41, Christian Kastner wrote:
>> I'll hazard another guess, namely that the great vast majority of users
>> simply do not care. I'd be surprised if most users even know what an
>> init system does,
On 2015-02-18 13:54, Luke Kenneth Casson Leighton wrote:
> that's right - i haven't. because (a) i have complete confidence in
> your technical abilities, as a group. i wouldn't use debian
> otherwise! :) and (b) this isn't a technical issue, it's a strategic
> one.
No, it's not. The issue is
On 2015-02-24 11:01, Alastair McKinstry wrote:
> I agree with this; are there any cases where only a static library _is_
> provided, and if so why? why not provide a .so?
One use case that was described to me was about libraries with APIs that
were not yet considered stable enough to be (properly)
On 2015-03-15 21:38, John Goerzen wrote:
> On 03/14/2015 07:36 AM, Vincent Bernat wrote:
>> The main difficulty is to handle the 0.9.5 to 1.x upgrade where the
>> configuration files change.
> I assume you mean the config files change in some dramatic way; that is,
> some way that means the existin
Hi,
(this pertains to RC bug #781050 [1])
Assume a package A with a conffile /etc/foo.conf. A while ago, package A
was split into package A and B, and B took over the conffile. B declares
the necessary Breaks/Replaces.
However, an upgrade to from a pre-split A to a post-split A did not
automatic
On 2015-05-25 21:26, Andrew Kelley wrote:
> I am working towards becoming a Debian Maintainer. Right now I need to
> get 2 Debian Developers to sign my key. Are there any Debian
> Developers in Phoenix, Arizona who would be willing to meet up and
> sign each other's keys?
AFAIUI, you only need two
(Speaking as one of the cron maintainers)
On 08.03.19 19:28, Adam Borowski wrote:
> On Fri, Mar 08, 2019 at 10:22:12AM -0800, Russ Allbery wrote:
>> cron is effectively maintained by the distributions anyway; there
>> hasn't been an official upstream release in more than twenty years.
>> This seem
On 08.03.19 20:38, Michael Stone wrote:
> On Fri, Mar 08, 2019 at 08:01:35PM +0100, Christian Kastner wrote:
>> I intended to post a transition proposal here soon, but it's not ready
>> yet... but long story short: I believe we would be far better off moving
>> to croni
Hi,
one of the cron maintainers here, and also the cronie maintainer.
On 07.07.19 17:00, Marc Haber wrote:
> On the other hand, there is cronie, which is used in the Red Hat world
> for years, is a well-tested code base, maintained upstream (in a rather
> slow pace), but only has an eight years o
On 09.07.19 09:32, Marc Haber wrote:
> It is good to know where things are going. Would you mind if I created
> a wiki page with this road map laid out about where Debian's cron
> world is going?
Not at all, on the contrary -- thanks for the offer!
> That would, though, only make sense if you cou
On 2023-08-02 13:33, Johannes Schauer Marin Rodrigues wrote:
> snapshot.debian.org is getting worse again. There is not a single snapshot for
> August yet and the last days of July are spotty:
[...]
> I'd argue that snapshot.d.o is part of the central services Debian provides
> and
> it should wor
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org
* Package name: half
Version : 2.2.0
Upstream Author : Christian Rau
* URL : https://sourceforge.net/projects/half/
* License
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: composable-kernel
Version : 0+git20230816
Upstream Author : Advanced Micro Devices, Inc.
* URL : https://github.com/ROCmSoftwarePlatform
On 2023-08-16 13:22, Simon McVittie wrote:
> I personally think the extent to which git has "won", both upstream and in
> Debian package maintenance, means that the Patch Tagging Guidelines should
> be encouraging the git-like style as primary
I think this is an excellent argument. DEP-3 hails from
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org
* Package name: llama.cpp
Version : b2116
Upstream Author : Georgi Gerganov
* URL : https://github.com/ggerganov/llama.cpp
* License
On 2024-03-30 17:00, Marco d'Itri wrote:
> On Mar 30, Jonathan Carter wrote:
>
>> Another big question for me is whether I should really still
>> package/upload/etc from an unstable machine. It seems that it may be prudent
> If we do not use unstable for development then who is going to?
Are you
On 2024-03-30 20:20, Russ Allbery wrote:
> I personally specifically want my workstation to be running unstable, so
> I'm watching to see if that's considered unsafe (either, immediately,
> today, or in theory, in the future).
>
> If I have to use a stable host, I admit I will be sad. I've been u
On 2024-03-30 22:59, Santiago Ruano Rincón wrote:
> The backdoor was discovered by someone using the compromised xz-utils *in
> their own machines*. So we are lucky we have people eating our own sid stuff
> before it becomes part of a stable release.
The luck was that this particular compromise
On 2024-03-31 04:22, Santiago Ruano Rincón wrote:
> I don't see the real benefit.
>
> As others have said, the best solution is to relay on HSW for handling
> the cryptographic material.
That's extremely important (which is why I use a HSM) but that "just"
prevents exfiltration of the keys. An a
Hi Jonathan,
just a brief correction:
On 2024-04-01 18:05, Jonathan Carter wrote:
> I don't want to single out DSA there, it's difficult and affects many
> other teams. The Salsa CI team also spent a lot of resources (time and
> money wise) to extend testing on AMD GPUs and other AMD hardware. It
The NEW queue length is down a single digit, from ~500 not all too long
ago. That's an amazing effort by ftp-master that must have consumed a
*lot* of energy.
THANK YOU!
https://ftp-master.debian.org/new.html
On 15.12.20 01:55, Russ Allbery wrote:
> Increasingly most of the people who work on Debian don't have i386
> hardware lying around, particularly i386 hardware that requires an i386
> kernel or that exercises the full range of older boot processes. If you
> do, testing and reporting good bugs woul
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: sphinx-prompt
Version : 1.3.0
Upstream Author : Stéphane Brunner
* URL : https://github.com/sbrunner/sphinx-prompt
* License : BSD-3-Clause
Programming Lang: Python
Description
Hi Bastian,
On 18.12.20 10:16, Bastian Blank wrote:
> On Fri, Dec 18, 2020 at 09:56:23AM +0100, Christian Kastner wrote:
>> Description : Sphinx directive to add unselectable prompt
>
> I'm trying to decipher what this (short) description is trying to tell
> me. &
On 01.04.21 08:52, Andrey Rahmatullin wrote:
> Can you please list some unsupported chips in addition to these specific
> Realtek ones?
I was looking for a WIFI USB dongle recently, and I found this site
quite useful for determining support status (I'm linking directly to the
chipset page, but the
On 26.08.21 11:39, Lucas Nussbaum wrote:
> Additionally, one could imagine a DSL to:
> - make minor changes to the source package before building (adjust
> dependencies, apply an additional patch, etc.)
> - tell sbuild that some build-dependencies must be pulled from backported
> packages
>
>
On 30.08.21 15:49, Jelmer Vernooij wrote:
> I think one of the main challenges here is to make sure that the
> dependencies for packages in unstable/testing are correct.
Why wouldn't they be correct, though? If it's less strict than it should
be, then that is a bug. And if it's too strict, experime
In case anyone missed it, the most recent release is now distributed
under the Apache 2.0 license:
https://lwn.net/Articles/868536/
On 2022-02-04 18:39, Russ Allbery wrote:
> In other words, this thread is once again drifting into a discussion of
> how to do copyright review *better*, when my original point is that we
> should seriously consider not doing the current type of incredibly tedious
> and nit-picky copyright review *
On 2022-02-05 16:07, Andrew M.A. Cater wrote:
> Just because someone else can't be bothered to do licence review checking
> doesn't mean that Debian shouldn't.
I wasn't advocating against license review checking in general, though.
We expect and trust all contributors to do that.
The question as
On 2022-02-15 12:28, Marc Haber wrote:
> Unfortunately, I don't have any i386 systems left, there don't seem to
> be any public i386 porterboxes other than 64bit boxes running 32bit
> chroots, and the i386 port traditionally doesn't have a port-specific
> mailing list
Package sbuild-qemu could hel
On 2022-03-12 21:42, Michael Biebl wrote:
> - Teach cron about systemd timers and allow cron entries to be marked
> with meta data that tells cron that when run under systemd it should
> skip those entries.
On 2022-03-13 01:07, Simon McVittie wrote:
> If there was a way to flag system cron jobs wi
On 2022-03-13 11:06, Marc Haber wrote:
> The anti-systemd faction in Debian is cordially invited to step in,
> bring cron and cronie up to shape, before asking the rest of the
> Distribution to stick with essential system software that has been
> unmaintained for years.
I don't think that's a very
On 2022-03-14 08:48, Marc Haber wrote:
> On Sun, 13 Mar 2022 18:02:55 +0100, Christian Kastner
>> I don't think that's a very constructive line of argument. As a former
>> maintainer, it was evident that user crontabs (crontab -e) are still
>> very popular,
On 2022-03-13 01:07, Simon McVittie wrote:
> - reserving an environment variable like SKIP_CRON_JOB_UNDER_SYSTEMD=1
> to act as a request to skip parsing this cron job on systemd systems
> (it would also be set like any other environment variable when the cron
> job is executed on a non-syste
Hi Steve,
thank you for bringing this up.
On 2022-04-19 02:27, Steve McIntyre wrote:
> 1. Keep the existing setup. It's horrible, but maybe it's the best we can do?
> (I hope not!)>
> 2. We could just stop providing the non-free unofficial images altogether.
> That's not really a promis
On 2022-04-19 12:41, Jonas Smedegaard wrote:
> Quoting Christian Kastner (2022-04-19 11:33:30)
>> Here's a somewhat radical idea: I propose that we make option (1) and
>> (2) conditional on all Debian infra switching to hardware entirely
>> free of binary firmware/micr
Hi Marc,
it took me a while to get into gears again...
I just pushed a branch ckk/sf3 that contains my "release candidate" for
src:cron converted to source format 3.0 (quilt).
The unpacked source is identical to the 1.0 unpacked source, and
unapplying all patches results in a source identical to
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
X-Debbugs-CC: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org,
debian-scie...@lists.debian.org
* Package name: python-seaborn
Version : 0.9.0
Upstream Author : Michael Waskom
* URL : https
On 19.11.19 05:59, Mo Zhou wrote:
> Given that there are also a number of packages in debian with OpenCL
> enabled, I'm wondering wether a shared buildd/CI/porterbox with GPU[2]
> could be helpful?
I would also be interested in this.
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-rust-maintain...@alioth-lists.debian.net
* Package name: broot
Version : 0.11.2
Upstream Author : Canop
* URL : https://dystroy.org/broot/
* License : MIT
Programming Lang: Rust
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: liac-arff
Version : 2.4.0
Upstream Author : Renato de Pontes Pereira
* URL : https://github.com/renatopp/liac-arff
* License : MIT/Expat
Programming Lang: Python
Description
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: python-configspace
Version : 0.4.12
Upstream Author : ConfigSpace developers
* URL : https://github.com/automl/ConfigSpace
* License : BSD-3-Clause
Programming Lang: Python
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: TPOT
Version : 0.11.1
Upstream Author : Epistasis Lab, Inst.for Biomedical Informatics, UPenn
* URL : https://epistasislab.github.io/
* License : GPL-3+
Programming Lang: Python
Russ,
On 25.03.20 03:25, Russ Allbery wrote:
> I'll repeat a point that I made earlier but put a bit of a sharper point
> on it: We should thoughtfully question whether the current approach to
> license review that we as a project ask ftpmasters to do is a correct
> investment of project resources
On 25.03.20 15:14, Tomas Pospisek wrote:
> I can be sure that if stuff lands in Debian then I won't get screwed
> by weird, dirty, missleading, underhanded licensing rules, which
> seems to be the standard outside the Open Source world and even on
> its fringes.
The only thing you can be sure about
On 25.03.20 15:50, Scott Kitterman wrote:
> The FTP Team review of debian/copyright is about DFSG and upstream license
> compliance. Most licenses require things like copyright statement
> preservation in binary distribution and debian/copyright is how we do that.
> Occasionally, in the proces
On 26.03.20 19:57, Andrej Shadura wrote:
> An example: commercial users. They need to know *exactly* what they
> are running and under which licenses.
The only way to know that is by performing your own due diligence.
> They are often bound by regulations with heavy fines for violating
> them, an
On 27.03.20 01:57, Paul Wise wrote:
> On Thu, Mar 26, 2020 at 8:30 PM Christian Kastner wrote:
>
>> [Well, technically, you could use your own lawyer to perform the due
>> diligence and have them submit any necessary changes to the BTS, but I
>> think it's
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: pyswarms
Version : 1.1.0
Upstream Author : pyswarms developers
* URL : https://github.com/ljvmiranda921/pyswarms
* License : MIT
Programming Lang: Python
Description : research
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: python-threadpoolctl
Version : 2.0.0
Upstream Author : Olivier Grisel
* URL : https://github.com/joblib/threadpoolctl
* License : BSD-3-Clause
Programming Lang: Python
Description
On 2020-06-23 02:12, Colin Watson wrote:
> On Tue, Jun 23, 2020 at 01:10:31AM +0200, Ansgar wrote:
>> On Mon, 2020-06-22 at 22:13 +0100, Colin Watson wrote:
>>> [1]
>>> https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html
>>
>> You might be interested in [2] as well. Specul
On 2020-06-23 08:14, Christian Kastner wrote:
> If it's not, then it's just about utility, and then honestly I don't see
> enough of it to merit the head-ache of breaking with the conventional name.
Having thought about that part some more, I realized I need to retract it.
On 2020-07-15 09:45, Philipp Hahn wrote:
> if a *previous* version of a software generated a *buggy* binary
> database, that bug got fixed in a *newer* version and also some
> *recovery* mechanism was added to allow reading that broken format
> *once*, but there is no code the write the *broken* fi
On 2020-07-16 12:53, Pirate Praveen wrote:
>> Generally speaking, I think it's a mistake to apply the question of
>> "preferred form for modification" to unit test payloads. Unit tests are
>> purely about functionality. The original source to a payload is an
>> arbitrary choice (possibly even rando
On 2020-07-17 18:30, Pirate Praveen wrote:
> On 2020, ജൂലൈ 17 8:14:24 PM IST, Marvin Renich wrote:
>> The intended purpose is to ensure that the recipient has every
>> reasonable opportunity to modify the software in any reasonable way the
>> recipient desires. The sole purpose of the requirement
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: python-xmlschema
Version : 1.2.2
Upstream Author : SISSA (Scuola Internazionale Superiore di Studi Avanzati)
* URL : https://github.com/sissaschool/xmlschema/
* License : MIT
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: python-iniconfig
Version : 1.0.1
Upstream Author : Ronny Pfannschmidt
* URL : https://github.com/RonnyPfannschmidt/iniconfig
* License : MIT
Programming Lang: Python
Description
Unless I'm grievously misremembering something, there was a discussion a
while ago about automatically generating a source package and uploading
it whenever a Debian release is (signed-)tagged in Salsa.
If I did remember correctly: may I kindly inquire what the status on
that is?
On 2020-08-29 01:05, Raphael Hertzog wrote:
> But given that we recommend upstream/latest for the upstream branch, I'm now
> leaning towards using debian/latest as default as well.
I like this! There's a nice symmetry to it that makes it very intuitive,
I think.
It seems that "nocheck" and "nodoc" can be used with both variables.
However, which one is to be used in debian/rules recipes? Or both, as
suggested here [1]?
Looking at random packages, newer packages seem to favor just checking
DEB_BUILD_PROFILES to conditionally build documentation, but that w
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 you do th
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: python-multipledispatch
Version : 0.6.0
Upstream Author : Matthew Rocklin
* URL : https://github.com/mrocklin/multipledispatch/
* License : BSD-3-clause
Programming Lang: Python
On 2020-09-08 08:36, Niels Thykier wrote:
> Fundamentally, the difference between the two are:
>
> * _PROFILES is a "new"[0] thing with a specific purpose to reduce
>build-dependencies (at least in this case). It ends up in d/rules
>for skipping builds of specific packages (e.g. "nopytho
On 2020-09-08 14:34, Peter Pentchev wrote:
> Just as a data point: for some time now I've been checking both
> variables with a single check :)
>
> ifeq (,$(filter nodoc,${DEB_BUILD_OPTIONS} ${DEB_BUILD_PROFILES}))
> ...
> endif
>
> ...does the job, with some possible overkill, but, hey, it works
On 2020-09-08 17:43, Helmut Grohne wrote:
> On Tue, Sep 08, 2020 at 12:33:07PM +0200, Christian Kastner wrote:
>> nocheck
>> ---
>>
>> A recipe such as
>>
>> override_dh_auto_test:
>> ifeq (,$(filter nocheck,$(DEB_BUILD_PROFILES)))
Package: wnpp
Severity: wishlist
Owner: Christian Kastner
* Package name: sktime
Version : 0.4.1
Upstream Author : sktime developers
* URL : https://github.com/alan-turing-institute/sktime
* License : BSD-3-clause
Programming Lang: Python
Description
I happened to stumble over the fact that bullseye Sources files contain
numerous versions of some of the packages.
For example:
$ wget http://ftp.debian.org/debian/dists/bullseye/main/source/Sources.gz
$ zgrep -A 2 'Package: util-linux' Sources.gz | grep -v Binary
Package: util-linux
Ver
Stéphane, thanks for the fast reply!
On 2020-10-02 09:34, Stéphane Glondu wrote:
> Le 02/10/2020 à 08:57, Christian Kastner a écrit :
>> numerous versions of some of the packages.
>>
>> Those three versions happen to be the current versions from stable,
>> testing, and
On 2020-10-02 09:34, Stéphane Glondu wrote:
> 2.33.1-0.1 has "Extra-Source-Only: yes", so one if its binaries is
> mentioned in "Built-Using" of some other package.
>
> Same for 2.34-0.1.
Could this perhaps be a Release-specific attribute that's not present in
every Source index?
I've stumbled a
On 2016-08-06 23:37, Andreas Tille wrote:
> Hi,
>
> On Sat, Aug 06, 2016 at 05:00:09PM +, Thorsten Alteholz wrote:
>> as you somehow add jquery.js to your doc-package, please add its license
>> to your debian/copyright.
>
> The jquery.js is installed by doxygen in the documentation process.
On 2016-05-21 19:32, Theodore Ts'o wrote:
> What is the suggested workaround if you have a package that has both
> executables and shared libraries, and you want to enable pie
> hardening for the executables?
Here's one possible solution:
https://sources.debian.net/src/keyutils/1.5.9-9/debia
On 2024-09-23 13:09, Lukas Märdian wrote:
>> So on desktop installations including NetworkManager, netplan will be
>> configured to do nothing? Why install netplan at all on desktop systems
>> then?
>
> Because it allows to add configuration in a way that is common with
> server, cloud
> and other
1 - 100 of 105 matches
Mail list logo
