Package: wnpp
Severity: wishlist
Owner: Christian Kastner
X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org
* Package name: libggml
* Version : 0.0+git
* Upstream Contact: The ggml authors
* URL : https://github.com/ggml-org/ggml
* License
On 2025-02-15 23:13, Simon McVittie wrote:
> On Sat, 15 Feb 2025 at 21:08:03 +0100, Christian Kastner wrote:
>> I read somewhere that Fedora can do full rollbacks because the make use
>> of "ostree". See [1] for example. We have ostree in our Archive [2].
>>
>&
Hi,
I have not been monitoring this thread but this new Subject popped up,
and then something came to mind:
On 2024-12-28 15:21, Guillem Jover wrote:
> Port-specific or hardware specific optimizations might make sense in
> dpkg, but that depends on the type, semantics, testability and
> intrusive
Hi Mo,
your effort in driving this is much appreciated.
There's a second thread going on ("A different Take on AI") where many
have chimed into the deeper specific issues, so I'll include my specific
replies there, and here will only reply to formalities:
On 2025-02-02 06:56, M. Zhou wrote:
> (2
Hi Otto,
On 2024-09-24 18:18, Otto Kekäläinen wrote:
> We've overhauled the README.md at
> https://salsa.debian.org/salsa-ci-team/pipeline to be as complete as
> possible, yet clear and to the point. If you are not yet using Salsa
> CI for pre-upload quality assurance for your package, you might w
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
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
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
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
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-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 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
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 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
* Package name: composable-kernel
Version : 0+git20230816
Upstream Author : Advanced Micro Devices, Inc.
* URL : https://github.com/ROCmSoftwarePlatform
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
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
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 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-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
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 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-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-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-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-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 *
In case anyone missed it, the most recent release is now distributed
under the Apache 2.0 license:
https://lwn.net/Articles/868536/
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
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 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
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. &
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
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
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 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
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
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
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
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)))
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 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
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-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
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-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.
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?
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
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
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
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-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-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-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
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
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
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
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 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 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
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
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
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: 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
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
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
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
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
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
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 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
(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 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 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
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-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
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-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-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-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 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
(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-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-
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
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: python-cachetools
Version : 0.6.0
Upstream Author : Thomas Kremmer
* URL : https://github.com/tkem/cachetools
* License : Expat
Programming Lang: Python
Description : extensible
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
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-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-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 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 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 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
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 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,
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 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
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 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: 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
1 - 100 of 105 matches
Mail list logo
