Re: Bits from the DPL
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's > fantastic and interesting work, and really more people within the > project and in the outside world should know about it! The AMD GPUs are not part of the official CI yet, as both our official infrastructure (hosting the GPUs) and our policies (expressing hardware relationships) do not permit it. We are running a fork of debci and other packages at https://ci.rocm.debian.net. Our forks have a number of experimental features, notably our architectures are [CPU ISA]+[GPU ISA], for example amd64+gfx1030 (Navi 21) or amd64+gfx1100 (Navi 31). Our fork currently automatically tracks all Debian packages which reverse-depend on any of our libraries. Developers are invited to add ROCm support to their packages if it's supported upstream, and the packages will automatically be tested on over a dozen AMD GPU architectures within our infra. We're finalizing our upgrade to ROCm 5.7+ (also on Ubuntu), and a proper write-up will follow on Debian Planet. Best, Christian PS: Our intention is of course to feed back all our changes to debci, Policy and so on, but some of these are entirely novel and require experimentation first, followed by discussion.
Re: xz backdoor
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 attacker could still simply modify dpkg-buildpackage or any other part of the toolchain to inject malicious code into one's builds that one then signs. As to the benefits, containers can do a lot that you probably couldn't do directly on your host. As an example, setting up/tearing down complex environments emulating multiple hosts. A more obvious example is developing for any environment that is not unstable. With containers, basically all you have to do is swap the name of the base image. Best, Christian (Santiago, sorry for sending it twice)
Re: xz backdoor
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 was discovered, not that it happened. I agree that dogfooding is important for discovering quality issues, but I think it's a poor argument for discovering security issues, especially if it concerns a host which is used for building and signing packages. As I mentioned earlier, I think containers are one good way to have almost the best of both worlds. One can do anything one could do on host, all while being isolated from that host, and with very little overhead but also a ton of useful extra features. Best, Christian
Re: xz backdoor
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 using > unstable for my personal client and development (not server, never > exposing services to the Internet) systems for well over a decade (and, > before, that, testing systems for as long as I've been working on Debian) > and for me it's a much nicer experience than using stable. I've heard many people say that, and I believe them. It might also work for me if I had more time for Debian ($dayjob is unrelated to FOSS) and thus more time to react to/report issues I find, but when I come home from work, I really just want a system where I'm practically never surprised by a significant change, other than security fixes. Also, I don't possess the skill to quickly work around transient issues as you mention below. > It also lets > me directly and practically dogfood Debian, which has resulted in a fair > number of bug reports. I wish I could do that in general. I try to do so during freezes, for contributing polish to a release, but otherwise I (1) just place my faith in upstream's own tests and hope autopkgtests have good coverage so debci catches things, and (2) I rely on the fact that my work in containers is also a form of dog-fooding. For more elaborate projects, I do have complex systems set up based on various environments. They are trivial to set up, tear down, snapshot, "fork", etc. And they can be locked down pretty tightly. And it's actually pretty convenient. Reproducing an issue for some other release, even of a derivative, often only requires trivial changes to a Dockerfile, like simply replacing the base image name. (Actually, now that I think about it, apart from my browser, I probably spend most of my time in terminals within unstable or experimental containers, and/or connected to containers running services...) > (This is an analysis specific to me, not general advice, and relies > heavily on the fact that I'm very good at working around weird problems > that transiently arise in unstable.) Best, Christian
Re: xz backdoor
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 both talking about unstable hosts, or unstable chroots, or...? I do all my development on a stable host, within rootless podman containers which are trivial to set up. I run final sbuilds and autopkgtests in QEMU VMs, also trivial to set up. This is both out of convenience (I want my workstation to be based on stable) and precisely because of the afforded isolation. Best, Christian
Bug#1063673: ITP: llama.cpp -- Inference of Meta's LLaMA model (and others) in pure C/C++
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 : MIT Programming Lang: C++ Description : Inference of Meta's LLaMA model (and others) in pure C/C++ The main goal of llama.cpp is to enable LLM inference with minimal setup and state-of-the-art performance on a wide variety of hardware - locally and in the cloud. * Plain C/C++ implementation without any dependencies * Apple silicon is a first-class citizen - optimized via ARM NEON, Accelerate and Metal frameworks * AVX, AVX2 and AVX512 support for x86 architectures * 2-bit, 3-bit, 4-bit, 5-bit, 6-bit, and 8-bit integer quantization for faster inference and reduced memory use * Custom CUDA kernels for running LLMs on NVIDIA GPUs (support for AMD GPUs via HIP) * Vulkan, SYCL, and (partial) OpenCL backend support * CPU+GPU hybrid inference to partially accelerate models larger than the total VRAM capacity This package will be maintained by the Debian Deep Learning Team.
Re: Issues in the Patch Tagging Guidelines
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 a time where we had (IIRC) 6 VCS supported on alioth, with svn being the dominant one. Today, practically everyone uses git, so the reasonable thing to do would be to optimize for that case. Best, Christian
Bug#1049961: ITP: composable-kernel -- library for writing performance critical kernels for ML workloads
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/composable_kernel * License : MIT Programming Lang: C++ Description : library for writing performance critical kernels for ML workloads Composable Kernel (CK) library aims to provide a programming model for writing performance critical kernels for machine learning workloads across multiple architectures including GPUs, CPUs, etc, through general purpose kernel languages, like HIP C++. CK utilizes two concepts to achieve performance portability and code maintainability: * A tile-based programming model * Algorithm complexity reduction for complex ML operators, using innovative technique we call "Tensor Coordinate Transformation". This is needed by MIOpen, which is also in the process of being packaged. This will be maintained by the Debian ROCm Team.
Bug#1049960: ITP: half -- C++ library for half precision floating point arithmetics
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 : MIT Programming Lang: C++ Description : C++ library for half precision floating point arithmetics This is a C++ header-only library to provide an IEEE-754 conformant half-precision floating point type along with corresponding arithmetic operators, type conversions and common mathematical functions. It aims for both efficiency and ease of use, trying to accurately mimic the behaviour of the builtin floating point types at the best performance possible. It automatically uses and provides C++11 features when possible, but stays completely C++98-compatible when neccessary. This is needed by MIOpen, which is also in the process of being packaged. This will be maintained by the Debian ROCm Team.
Re: snapshot.d.o has been in a bad state for several months
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 work better than it does right now. I second this, snapshot.d.o pas proven to be an invaluable tool for reproducing issues. Is there any way we can help resolve the open issues? Best, Christian
Re: Firmware - what are we going to do about it?
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/microcode blobs. >> >> Because if *we* can't do it, then imposing this stringency on our >> users is outright idealist hypocrisy. >> >> [Spoiler: we can't, unless some open x86_64 silicon has popped up >> somewhere (doubtful, because of the required patents).] > > I certainly like "eat our own dogfood", but our infrastructure currently > runs on _top_ of Debian systems, using non-Debian applications. > > I don't think we should put the bar higher for firmware than we do for > applications, regarding "eat our own dogfood". What would be the point > of that (other than artificially creating an argument for option 5)? I'm sorry, but I don't quite follow your argument? In case my own wasn't clear, what I meant was: (a) all of the x86_64 hosts in our infrastructure use CPUs that utilize non-free microcode, and (b) unless we're crazy, those hosts also use the non-free intel-microcode or amd64-microcode packages to get security fixes. Consequently, expecting our users to forgo non-free entirely is, in my eyes, extremely hypocritical. We make exceptions for these microcode packages because whether we like it or not, it's the only reasonable/secure/sane thing to do. Here's an even more radical thought: shipping any x86_64 installer CD without amd64-microcode and intel-microcode installed by default is a disservice to our users. There's no ideological "Win" when you're paying for it with the user's security, especially when they might be unaware of the problem.
Re: Firmware - what are we going to do about it?
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 promising route to follow - we'd be making it even > harder for users to install our software. While ideologically pure, it's > not going to advance the cause of Free Software. 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/microcode blobs. Because if *we* can't do it, then imposing this stringency on our users is outright idealist hypocrisy. [Spoiler: we can't, unless some open x86_64 silicon has popped up somewhere (doubtful, because of the required patents).] > 3. We could stop pretending that the non-free images are unofficial, and > maybe > move them alongside the normal free images so they're published together. > This would make them easier to find for people that need them, but is > likely to cause users to question why we still make any images without > firmware if they're otherwise identical. > > 4. The images team technically could simply include non-free into the > official > images, and add firmware packages to the input lists for those images. > However, that would still leave us with problem 3 from above (non-free > generally enabled on most installations). > > 5. We could split out the non-free firmware packages into a new > non-free-firmware component in the archive, and allow a specific exception > only to allow inclusion of those packages on our official media. We would > then generate only one set of official media, including those non-free > firmware packages. I'd vote for option 5, and alternatively option 3. Best, Christian
Re: Q: systemd-timer vs cron
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-systemd system, but that should generally be > harmless, because programs are generally expected to ignore unknown > environment variables) I guess I overlooked this at first, because this sounds like a really simple solution, 3 LOC or so. It also shouldn't conflict with anything else out there.
Re: Q: systemd-timer vs cron
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, as are some other perhaps niche features, and I've never >> had the impression that anti-systemd has anything to do with it. > > That was not my intention to say. I think I could have expressed myself better as well. I read "anti-systemd" and "unmaintained", and by addressing the these arguments, I only wanted to point out how conclusions drawn from these might be questionable. I probably could have left out the part where the work stopped and what would be needed to move forward, as that is document in the respective WNPP bugs. > And I didn't want to put your maintenance work in a bad light. I didn't take it as such, actually I simply assumed you were unaware of the maintenance work. > Not being a systemd fanboi myself, for many things I prefer having > mechanisms outside of systemd, but if an alternative is unlikely to > move forward any time soon, I'd seriously consider migrating to > something that IS moving forward, and that is systemd timers. That's the way that I see it, too. cron has this bad luck that basically every Linux and BSD distribution has its own fork of Vixie cron (1993) or its successor ISC cron (2000), so there is no reasonable collaboration / sharing of work between upstreams, so most of them are mainly one-person shows. systemd has not only the benefit of being newer, but also appears to have many eyes on it. It also comes with a large number of security features that may be useful for job execution.
Re: Q: systemd-timer vs cron
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 constructive line of argument. As a former maintainer, it was evident that user crontabs (crontab -e) are still very popular, as are some other perhaps niche features, and I've never had the impression that anti-systemd has anything to do with it. And in all fairness, I did invest a lot of time maintaining it over the years before I stepped down recently. I spent hundreds of hours alone on converting our fork of Vixie cron from source format 1.0 to 3.0 (the cumulative 1.0 diff spanned more than two decades of changes) so that our fork can more easily be compared and merged with other cron forks, such as cronie. I completed that task a while ago, but then lost all motivation to continue further. The cron daemons all originate from the early 90s. systemd timers, being newer, just seem like a much cleaner implementation, and thus the way forward to me. I could no longer muster the time or energy to work on something I wasn't happy with, so I stepped down. In my opinion, the way forward for cron would be for someone to adopt cronie, carry over any Debian patches not already included or equivalent (there aren't too many, last time I checked), and to make cronie the new default cron daemon. Best, Christian
Re: Q: systemd-timer vs cron
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 with metadata that says > "this is redundant when running under systemd", [...] > I personally think I've written those in preference order (best one first), > but it's up to the cron implementors' tastes rather than mine. Unless cron finds a new maintainer (#984736), I don't think either of these are going to happen. Best, Christian
Re: Getting in contact with the i386 porters
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 help you here: # Build image $ sudo sbuild-qemu-create --arch i386 -o i386.img unstable http://deb.debian.org/debian $ sudo chown : i386.img # Boot QEMU VM to console $ sbuild-qemu-boot --arch i386 i386.img Since this seems to be tied to a particular CPU, you might need to hack the sbuild-qemu-boot script to include a '-cpu' option for qemu-system-i386 with a model that is somewhat similar to the Geode LX. Best, Christian
Re: Legal advice regarding the NEW queue
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 I see it is: why do we need another party (ftp-master) to verify that first review. It's a major bottleneck to everyone, a huge burden to the ftp-master team. As far as I can recall, the argument has always been that is necessary for liability reasons. My point is that I don't recall every seeing such a liability materialize with other projects, so perhaps our assumptions about the magnitude of this issue are wrong. (Or I'm just ignorant about such cases.) > I'd much rather that packages were removed in NEW than that they got > installed in unstable and we then had to tell people that they had > gone. > There's a huge amount of software that's undistributable: Debian's good faith > attempt to review this is one of the crucial arguments I have with $DAYJOB > about the benefits of a curated distribution, however fallible we may be. Fair enough.
Re: Legal advice regarding the NEW queue
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 *at all*, and instead rely more on > upstream's assertions, automated tools, and being reactive in solving the > bugs that people actually care about (i.e., notice). If we're honest, that's basically how the rest of the open source world already operates in general. Our level of scrutiny is a burden that I don't see many others sharing. Of course "everybody's doing it" doesn't make something right. However, when things go wrong, they don't seem to go wrong in the dramatic ways we might anticipate them to. If GitHub (a Microsoft-owned entity and thus an attractive target for a lawsuit) is OK with distributing files uploaded by third parties without subjecting them to a manual review process, perhaps we have been overthinking the risks here.
OpenSSL relicensed to Apache 2.0
In case anyone missed it, the most recent release is now distributed under the Apache 2.0 license: https://lwn.net/Articles/868536/
Re: Automated backports based on Janitor work?
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, experimentation with lowered requirements sounds somewhat dangerous. The approach I chose was to just backport any necessary dependencies as well. (...backport any necessary dependencies within reason, that is. For example, some Python packages always have bleeding edge build dependencies in setup.py thanks to dependabot, but a diligent maintainer will downgrade those to whatever the doc say is sufficient, I hope.)
Re: Automated backports based on Janitor work?
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
>
> Jelmer, did you already think about that? Is there a way one could help
> you?
I worked on something like this last fall, which I tentatively named
'apt-derive'.
Given a source package in some origin distribution, apt-derive can
automatically create a derivative of the source package, and of any
necessary dependencies, for a target distribution.
The popular derivation would be the backport type, of course. But other
possibilities exist. For example, I was interested in optimized build
flavors for certain target environments.
Here's sample code for a numpy buster backport, with the following
output reflecting the rebuild chain needed on amd64 circa September
2020, when I ran this:
| from apt_derive import RebuildResolver
|
| # Used to identify Releases in python-apt
| bullseye = dict(origin='Debian', codename='bullseye')
| buster_bpo = dict(origin='Debian Backports', codename='buster backports')
| buster = dict(origin='Debian', codename='buster')
|
| # origin: bullseye
| # target: buster-backports
| # Packages from buster can be used to satisfy build dependencies
| rr = RebuildResolver(wanted_dist=bullseye,
| target=buster_bpo,
| added_dists=[buster])
|
| # Figure out what needs to be rebuilt
| tree = rr.resolve('numpy')
| if tree:
| print(tree.pformat())
python3-numpy_1:1.19.2-2
└─cython_0.29.21-1
└─dvisvgm_2.10.1-1
└─freetype_2.10.2+dfsg-3
└─python-hypothesis_5.32.1-1
└─sphinx_3.2.1-1
└─python-lark_0.9.0-1
└─sphinx_3.2.1-1
So back then, 7 unique packages needed to be backported (numpy and 6
others for newer build dependencies).
That's the resolving part of apt-derive. There's more to it of course,
for example there is a "blocked" list of packages where automatic
derivation would be refused (eg: for libc).
The rebuild part of apt-derive would create backported sources (with
changelog entries, and any other configured extensions) for the
packages.
My plan was to provide such a automated backports service under the name
"autobpo", with package suffix ~autobpo11, and suites
* bullseye-autobpo-dangerous for the immediate build results
* bullseye-autobpo for results that passed CI and rebuilt
reproducibly
As to which packages to automatically backport, my plan was two-fold:
* By popular request
* Maintainers indicating so with X-AutoBPO-Policy:
somewhere in debian/control
What eventually stalled my effort was that I was lacking a reasonably
simple build environment for multiple architectures. I wrote sbuild-qemu
to get local access to many architectures, but in the end, I didn't see
a way around wanna-build etc. for a multi-node build farm. I found
wanna-build overly complicated, and then other stuff came up in $LIFE.
Raphael initiated debusine in the meantime, which seems to be ideal
solution to my build problem.
However, If anyone with wanna-build experience is interested in
collaborating to get this launched sooner, please ping me.
I'll try to finalize the first draft of apt-derive as soon as possible
in the hopes that something can come of it.
Best,
Christian
Re: Realtek RTL8723DE, RTL8821CE, RTL8822BE and RTL8822CE chipsets
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 site in general has interesting stuff): http://en.techinfodepot.shoutwiki.com/wiki/Wireless_Adapters/Chipset_table The page seems to be somewhat up-to-date, too. Best, Christian
Re: Bug#977651: ITP: sphinx-prompt -- Sphinx directive to add unselectable prompt
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. "Sphinx directive", okay. "prompt" still okay, however "command > line prompt" would be more descriptive. > > But "unselectable"? I can't interpret that word and according to > Merriam-Webster, it does not exist in the english language.[1] I'm in agreement with you here. It's the description, verbatim, from setup.py, and since there is very little other documentation for this project, I just went with that. > I really think you should find something that does not throw of users > directly. I'll ping upstream for a clarification.
Bug#977651: ITP: sphinx-prompt -- Sphinx directive to add unselectable prompt
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 : Sphinx directive to add unselectable prompt Sphinx prompt adds a new directive for documentating steps in interactive prompts. Currently, Bash, Python, and Scala syntax are supported. This is a dependency of scikit-learn 0.24. It will be maintained under the umbrella of the Debian Python Team.
Re: Release status of i386 for Bullseye and long term support for 3 years?
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 would probably be helpful. FWIW, most people probably have amd64 hardware around, and can therefore use KVM-accelerated i386 emulation using QEMU. That emulation can be configured with a fine grain, down to CPU models/features. And until at least a few years ago, that emulation was quite realistic. For my bachelor's thesis, I looked into portability of binaries, and I used autopkgtest + QEMU to hunt for bugs where the buildd environment affected the build (for example, by picking up CPU flags of the buildd machine). I found #781998 like that (i386 binary assuming SSE is present), and confirmed it on real hardware. So, technically, I think i386 is quite easy to test. To me, even easier than arm64, where I need to get useful hardware first. Using QEMU, it's trivial to build packages for i386 on amd64 (using sbuild, or the qemu-sbuild-tools wrapper I'm dabbling on, which will be absorbed by sbuild soon), and autopkgtest using QEMU has been trivial since forever.
NEW queue almost empty
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
Re: archive: bullseye Sources files contain multiple versions of packages - why?
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 another case in buster-backports [1], where Sources has the following versions of src:libreoffice. Version: 1:6.3.4-2~bpo10+1 Version: 1:6.4.5-1~bpo10+1 Version: 1:7.0.1-1~bpo10+2 But none of the records have "Extra-Source-Only: yes" set. [1] http://ftp.debian.org/debian/dists/buster-backports/main/source/Sources.xz
Re: archive: bullseye Sources files contain multiple versions of packages - why?
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 unstable. Does anyone know why these are all in this one file? >> The version from unstable is the most surprising. > > > 2.33.1-0.1 has "Extra-Source-Only: yes", so one if its binaries is > mentioned in "Built-Using" of some other package. I wasn't aware of this field, good to know. > Same for 2.34-0.1. > > 2.36-3 is the current version in testing. I compiled the list late last night and could have sworn that 2.36-3 is from unstable, but I guess my eyes were too tired already.
archive: bullseye Sources files contain multiple versions of packages - why?
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 Version: 2.33.1-0.1 -- Package: util-linux Version: 2.34-0.1 -- Package: util-linux Version: 2.36-3 Those three versions happen to be the current versions from stable, testing, and unstable. Does anyone know why these are all in this one file? The version from unstable is the most surprising.
Bug#970708: ITP: sktime -- Python machine learning toolbox for time series
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 : Python machine learning toolbox for time series sktime is a Python machine learning toolbox for time series with a unified interface for multiple learning tasks. It currently supports: * Forecasting, * Time series classification, * Time series regression. sktime provides dedicated time series algorithms and scikit-learn compatible tools for building, tuning, and evaluating composite models. This will be maintained within the Debian AI Team.
Re: debian/rules and DEB_BUILD_PROFILES vs _OPTIONS
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))) >> dh_auto_test >> endif >> >> is sufficient as "dh_auto_test" will honor possibly present _OPTIONS, but > > This one is redundant. Anyone setting nocheck in profiles must also set > it in options. Mattia already pointed this out, but it seems to have slipped my mind again. > >> override_dh_auto_test: >> ifeq (,$(filter nocheck,$(DEB_BUILD_PROFILES))) >> custom-test-command >> endif >> >> is not, as "custom-test-command" will be executed even if >> DEB_BUILD_OPTIONS=nocheck is set. > > Yeah, this is just wrong (at present). > > I do understand that having nocheck both as a profile and an option is > confusing. Being on of the people who made us end up here, I do not > object to transitioning to a less confusing state. A number of people > would like to see nocheck be a profile and not an option. I agree with > that goal in principle, but getting there is a lot of effort. We're > talking about touching 2300 source packages. > > Given that people already started using the profile exclusively, we > could now deprecate nocheck as an option. That would make us enter a > transition period where you must set both and packages should check the > profile. After maybe two stable releases, we could MBF the remaining > packages. > > Contrary to earlier such transitions, we now have a mighty tool to do > the bulk of the work: The Debian Janitor (thank you again Jelmer!). Indeed, both lintian and the Janitor could probably help with a significant share of those cases. > Another aspect that could make it less confusing would be changing > canonical entry point for builds. I know that Niels has been working on > this. The current entry point is debian/rules and that means, we cannot > add any compatibility layer around that. If you'd have to build with > dpkg-buildpackage, it could check for the profile and automatically add > the option. > > In any case, we could change both sbuild and pbuilder to do that today. > Whenever you go sbuild --profiles=nocheck, it could add the option. That also seems like a quick solution, but feels to me like sidestepping the issue instead of addressing it (which can be perfectly acceptable solution, though).
Re: debian/rules and DEB_BUILD_PROFILES vs _OPTIONS
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.
Indeed, I also saw this recipe somewhere else, and I think I'll be using
that now.
Thanks!
Re: debian/rules and DEB_BUILD_PROFILES vs _OPTIONS
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. "nopython") > > * _OPTIONS is the thing that has been here since the "dawn of time" to >enable the builder to tweak the build in a standardized way. > > (Note that their definitions do not overlap) > > Basically, we ended up in the situation like this with nocheck[1]: > > * We had _OPTIONS with nocheck for at least a decade and probably more. >- I.e. _OPTIONS is what everyone wrote in their d/rules file to > implement policy. > > * We invented _PROFILES and supported nocheck to assist cross-builders >and bootstrappers, who generally want as few build-depends as >possible even at the expense of running tests (cross-builders often >cannot run them anyway). >- I.e. _PROFILES is what the dependency resolvers look for when > deciding which build-depends to install. > > And that is how you end up with WET Debian packaging. > > I hope that cleared the relationship between _OPTIONS and _PROFILES and > how we got here. Yes, thank you for the background -- that was really helpful. Coming back to the practical problem from a maintainer's point of view, unless I'm mistaken, that means: nocheck --- A recipe such as override_dh_auto_test: ifeq (,$(filter nocheck,$(DEB_BUILD_PROFILES))) dh_auto_test endif is sufficient as "dh_auto_test" will honor possibly present _OPTIONS, but override_dh_auto_test: ifeq (,$(filter nocheck,$(DEB_BUILD_PROFILES))) custom-test-command endif is not, as "custom-test-command" will be executed even if DEB_BUILD_OPTIONS=nocheck is set. nodoc - As recipes frequently follow the pattern of override_dh_auto_build: dh_auto_build ifeq (,$(filter nodoc,$(DEB_BUILD_PROFILES))) build-docs-command endif DEB_BUILD_OPTIONS=nodoc gets ignored. vice versa --- And the same applies when _OPTIONS is filtered instead of _PROFILES. Did I get that right? Christian
Bug#969766: ITP: python-multipledispatch -- multiple dispatch in Python
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 Description : multiple dispatch in Python This implementation of multiple dispatch is efficient, mostly complete, performs static analysis to avoid conflicts, and provides optional namespace support. It looks good too. What this does: * Dispatches on all non-keyword arguments * Supports inheritance * Supports instance methods * Supports union types, e.g. (int, float) * Supports builtin abstract classes, e.g. Iterator, Number, ... * Caches for fast repeated lookup * Identifies possible ambiguities at function definition time * Provides hints to resolve ambiguities when they occur * Supports namespaces with optional keyword arguments * Supports variadic dispatch What this doesn't do: * Diagonal dispatch * Efficient update: The addition of a new signature requires a full resolve of the whole function. This becomes troublesome after you get to a few hundred type signatures. This will be maintained within the Debian Python Team.
Re: debian/rules and DEB_BUILD_PROFILES vs _OPTIONS
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 the build), so… That's why I find this part odd: >> Looking at random packages, newer packages seem to favor just checking >> DEB_BUILD_PROFILES Given what was said above for the major use cases nodoc and nocheck, _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_PROFILES are both explained, the relationship between them (if any) is not.
debian/rules and DEB_BUILD_PROFILES vs _OPTIONS
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 would mean that DEB_BUILD_OPTIONS as recommended by policy is not honored. Or do dpkg or debhelper apply some kind of mapping logic from _OPTIONS to _PROFILES for the popular options nocheck, nodoc, noopt? Or are we supposed to transition to just _PROFILES in the long term? [1] https://lists.debian.org/debian-devel/2019/01/msg00080.html
Re: Accepting / adopting DEP-14
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.
Tagging in Salsa -> upload: status?
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?
Bug#968152: ITP: python-iniconfig -- brain-dead simple parsing of ini files
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 : brain-dead simple parsing of ini files iniconfig is a small and simple INI-file parser module having a unique set of features: * tested against Python2.4 across to Python3.2, Jython, PyPy * maintains order of sections and entries * supports multi-line values with or without line-continuations * supports "#" comments everywhere * raises errors with proper line-numbers * no bells and whistles like automatic substitutions * iniconfig raises an Error if two sections have the same name. This is a dependency of a newer pytest version and will be maintained under the umbrella of the Debian Python Modules Team.
Bug#968151: ITP: python-xmlschema -- implementation of XML Schema for Python
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 Programming Lang: Python Description : implementation of XML Schema for Python This library includes the following features: * Full XSD 1.0 and XSD 1.1 support * Building of XML schema objects from XSD files * Validation of XML instances against XSD schemas * Decoding of XML data into Python data and to JSON * Encoding of Python data and JSON to XML * Data decoding and encoding ruled by converter classes * An XPath based API for finding schema's elements and attributes * Support of XSD validation modes strict/lax/skip * Remote attacks protection by default using an XMLParser that forbids entities This is a dependency of a newer pytest version and will be maintained under the umbrella of the Debian Python Modules Team.
Re: Preferred form of modification for binary data used in unit testing?
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 for source is to >> protect this freedom, and the requirement should not be applied >> independently from this purpose. >> >> So the question becomes how does the inclusion or exclusion of the >> binary blob, without inclusion of the full source and build process of >> the broken version of the software used to produce the binary blob, >> enhance or detract from the recipient's ability to produce a modified >> version of the current, good, distributed software. > > Very, well put. Many times I see blind application of rules without any other > consideration. The rules serve a purpose, our purpose is not to blindly serve > the rules. If the rules are stopping us, we need to change them, not just > adjust ourselves to the rules once written. I fully concur with your opinions, however I'm not sure that they are universally shared and/or clear. Otherwise, this thread wouldn't exist. Some norms avoid the risk of "blindly serving the rules" by expressly rejecting that, for example Article 11 GDPR [1] holds that the GDPR is not self-serving. [1] https://gdpr.eu/article-11-what-personal-data-can-a-controller-process-without-identification/
Re: Preferred form of modification for binary data used in unit testing?
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 randomly generated), and could be >> replaced with any other appropriate arbitrary choice at no detriment to >> the software or the user. >> > > I think this needs to be clearly documented in policy. I don't think > this interpretation is generally accepted. I have seen many cases where > tests are disabled for this reason. Perhaps I spoke too generally. For example, I can see, as one of probably many counter-examples, the case where the input is not completely arbitrary (eg: input is a captured stream). But to take the other extreme, using completely arbitrary data, as an example: say my code implements a ROT13 function and I create a test for it using a blob of random data as well as the expected output. That random data was generated somehow, eg: using Python's random module, and could therefore be regenerated given the correct program and seed. However, I did not include the code to generate that data. Would we really reasonably expect anyone to act upon that random blob in any way?
Re: Preferred form of modification for binary data used in unit testing?
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* file again. For > *unit testing* the upstream developers added an *example* of such a > broken database to their test data. > What's the preferred form of modification for that data set? > > * Should I include a copy of the *broken code* to generate that data? > * Declare that there in no preferred form for modification, as a > "open-save"-cycle with the current code will not re-create the bit > idencial file again. > * Remove the test data because it is not DFSG conformant and hope the > Debian build will never break the recovery code.> * Include instructions on > how to re-build the broken version and give > instructions on how to maybe rebuild a similar broken file. Personally, I would do nothing at all. At most, I would choose the last of the above options (include instructions). This is about the payload to a particular decoding unit test. It's a common pattern to generate such payloads without storing the original source or even intermediate steps -- which, unless I'm mistaken, would imply that the final result has become the preferred form for modification. The expectation is simply for a particular chunk of data to produce a particular output. I think it is reasonable to assume that upstream generated the broken file with the old code, implemented the unit test, and discarded the broken code. So given the current (shipped) version of the software, even upstream couldn't recreate the broken file. 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 randomly generated), and could be replaced with any other appropriate arbitrary choice at no detriment to the software or the user.
Re: DEP-14: renaming master to main?
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. I might not see the utility of it, but seeing as a lot of thought already went into DEP-14, I can only conclude that a sufficient number of other people see it.
Re: DEP-14: renaming master to main?
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. Speculation is often wrong. >> >> [2]: >> https://mail.gnome.org/archives/desktop-devel-list/2020-June/msg00023.html > > Good to know, but I think it doesn't really change my conclusions. Could you expand on that? I interpreted your conclusions to be necessitated by what was written in the first mail. 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.
Bug#960805: ITP: python-threadpoolctl -- Python helpers for common threading libraries (BLAS, OpenMP)
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 : Python helpers for common threading libraries (BLAS, OpenMP) Thread-pool Controls provides Python helpers to limit the number of threads used in the threadpool-backed of common native libraries used for scientific computing and data science (e.g. BLAS and OpenMP). Fine control of the underlying thread-pool size can be useful in workloads that involve nested parallelism so as to mitigate oversubscription issues. This is a new dependency of src:scikit-learn and will be maintained within the Debian Science Team.
Bug#958123: ITP: pyswarms -- research toolkit for particle swarm optimization in Python
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 toolkit for particle swarm optimization in Python PySwarms is an extensible research toolkit for particle swarm optimization (PSO) in Python. It is intended for swarm intelligence researchers, practitioners, and students who prefer a high-level declarative interface for implementing PSO in their problems. PySwarms enables basic optimization with PSO and interaction with swarm optimizations. Features: * High-level module for Particle Swarm Optimization * Built-in objective functions to test optimization algorithms * Plotting environment for cost histories and particle movement * Hyperparameter search tools to optimize swarm behaviour I intend to maintain this within the Debian Science Team.
Re: What to do when DD considers policy to be optional? [kubernetes]
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 safe to assume that that is a theoretical example.] > > The OSI started ClearlyDefined, which aims to do just that (and more) > for both Debian and other communities, using automated tools > (scanCode) and human curation of the results. > > https://clearlydefined.io/?type=debsrc=releaseDate=true > https://clearlydefined.io/about > https://docs.clearlydefined.io/contributing-data > https://wiki.debian.org/CopyrightReviewTools > https://github.com/nexB/scancode-toolkit/ > https://fosdem.org/2020/schedule/event/rust_license_clearlydefined/ Interesting. While I personally believe this would be insufficient as due diligence [*], it would definitely be a great assistance in carrying out thereof, and help bring "surprises" to light (eg a BSD-licensed software containing some GPL code). One frequent reason why proprietary software wins over FOSS in corporate environments is because the vendor is willing to indemnify the client. So by buying $FOO, you can spare yourself all this legal headache, the problem is simply shifted to the vendor. That's a really hard offer to beat, business-wise. [*] To use extreme examples, in SCO v. IBM and Google v. Oracle cases, they went file-by file. In the first trial to the latter case, a 9-line function was found to be infringing. (This was later reversed, but that's still bad enough).
Re: What to do when DD considers policy to be optional? [kubernetes]
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, and not only fines, but a threat of your product being banned, > and that often means they want only specific licenses in their > products. There is no way whatsoever that a regulator, or a court, will accept checking a single third-party file (debian/copyright), created by an unpaid volunteer one has never even met, much less have a business relation with, as proper due diligence in a copyright infringement case. [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 safe to assume that that is a theoretical example.] Don't get me wrong, debian/copyright is certainly useful in general, but the only value in a legal conflict I can see is for Debian, namely to demonstrate our own compliance when distributing binaries (see Scott's and Sean's replies).
Re: What to do when DD considers policy to be optional? [kubernetes]
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 process of evaluating if Debian would be in compliance > with the upstream license and if the license meets our DFSG requirements, we > detect larger issues. > > When I'm reviewing something for New I take upstream's copyright/license > statements at face value unless there's something too obvious to be ignored. > I certainly don't go hunting for reasons not to like upstream licensing > statements, but sometimes they slap you in the face. > > By far the most common case for rejections is incomplete debian/copyright and > that's unrelated to trusting upstream. Personally, I don't think the problem > is that the bar is too high. Almost all debian/copyright issue I find could > have been located before upload if the maintainer had simply grep -ir > copyright * | less and checked the results before uploading. It's just that this last step frequently turns out to be a very draining rabbit hole. [1] Frustratingly, the smaller the contribution, the deeper the hole. Larger contributions tend to have explicit copyright information, so it's easier to determine and document. Smaller ones sometimes just document only the author. [2] I find the analysis of this to be totally draining work. And while I could see a point to this in the past, I no longer do. FOSS began as a movement where legal and political aspects were on the front line, and distributions like Debian were the primary channel to access FOSS, so it's easy to understand why debian/copyright was initially given so much importance. Today, (IMO most of) "FOSS" is people creating, sharing and contributing stuff on GitHub and similar platforms. GitHub et al. have made hosting and contributing for/to projects so trivial that people /just do it/. It comes naturally. The legal and political aspects are no longer the front line. In many cases, they even have become overhead. There's this expression in German for when one takes a policy too far: "Don't try to be holier than the Pope". But that's how maintaining debian/copyright has come to feel to me. We still apply a level of detail that seems out of place in today's world. It's such an odd position to be in to sit between upstream and contributor and discuss with them the legalities of one contribution you've hunted down, when it is evident that it was just "a contribution", and neither could understand why I have to make such a big deal out of it. [3] So, I ask: what for? Policy for policy's sake? Why not just begin with a simple debian/copyright that documents, in very short form, what upstream documents in LICENSE and COPYING, and only refer to AUTHORS, etc., and only begin to look at further details once somebody actually /complains/ about them. In any case, let's keep in mind that we are just one of the distributors. Now that it has become so easy to file complaints with upstream (again, thanks to GitHub et al.), I'm all but certain that any legal issues with the original source would first be filed upstream, rather than for all downstreams individually. I think we investing far too much time in a problem that no longer exists, and probably wasn't even that big of a problem in the past (unless anyone can provide an example where a detailed debian/copyright has ever paid off the effort it cost). Christian [1] It only starts with 'grep -ir copyright *'. In many jurisdictions, copyright applies regardless of where it is expressly claimed or not, so 'grep -ir author *' is probably just as important as a signal, and people tend to add that a lot. [2] Because why would anyone (who is not Oracle) actually care about a few dozen lines of code. [3] Except, of course, where contributions are legally formalized, for example with a CLA. PS: This is my personal view of the the matter as I originally experienced it when becoming a maintainer, and over time when fixing RC bugs related to policy, resp. observing other bugs. It's quite possible that it is my personal view that is completely off, and that the ftp-master view isn't that strict, at all.
Re: What to do when DD considers policy to be optional? [kubernetes]
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 is that the declared license is up to Debian standards. No such thing can be said about most of the code itself, unless you have an actual audit trail documenting its origin. To use an extreme example: me grabbing code from $EMPLOYER and slapping the GPL onto it, doesn't make it GPL.
Re: What to do when DD considers policy to be optional? [kubernetes]
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. > > The current approach to NEW license review is not a law of nature. It's a > choice. Other choices are possible, such as trusting license declarations > by upstream and then handling upstream mistakes that are later discovered > as RC bugs. The project is much better at sharing the load of handling RC > bugs than it is at sharing the load of NEW license reviews. > > Most of the ecosystems that make extensive use of vendored packages also > make extensive use of license metadata. Sometimes that license metadata > is wrong, and we will have to have a process for dealing with those > errors. But the purpose of Debian is not to be a license checking service > for the entire free software world. It's to build a distribution adhering > to a set of principles but with the understanding that we will sometimes > make errors and fix them later as bugs, not be perfect and error-free at > any of our principles, including our licensing principles. For everything > other than licenses, we accept the risk that we will incorporate upstream > errors in our distribution until someone points them out via a bug report. > > We do not *have* to do a detailed file-by-file review of the correctness > of upstream's license metadata when packaging. This is a choice. By > choosing to do this, we absolutely catch bugs... just like we would catch > bugs if we did a detailed file-by-file review of any other property of > upstream code. For many other types of bugs (including ones that arguably > have a more severe impact on our users than licensing bugs, such as > security bugs), we often make trade-off decisions in favor of accepting a > risk of upstream mistakes and having to fix them later. if I could +1000 just one post, ever, it's this one. The vast majority of people developing Open Source Software nowadays just publish stuff on GitHub and friends. They fork code, they merge other people's contributions, etc. And at no point can I see those people engage in even a fraction of the bureaucracy that we follow when sharing, forking, publishing, and contributing code. This is not to say that licensing is an unimportant issue -- it clearly is. But our analyze-and-document down-to-the-file approach is on the other extreme end of the spectrum, and it causes lots of tiresome work that nobody apart from us seems to care about. > Other choices are possible, such as trusting license declarations > by upstream and then handling upstream mistakes that are later discovered > as RC bugs. This would be fantastic. Just fantastic.
Accepted scoop 0.7.1.1-6 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 23 Jan 2020 22:51:17 +0100 Source: scoop Architecture: source Version: 0.7.1.1-6 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers Changed-By: Christian Kastner Closes: 689211 869224 Changes: scoop (0.7.1.1-6) unstable; urgency=medium . * Adopt package. (Closes: #869224) . * Set Maintainer to Debian Science * Add myself to Uploaders * Bump debhelper compatibility level to 12 * Bump Standards-Version to 4.5.0 (no changes needed) * Point Homepage to GitHub * Set Rules-Requires-Root to no * Use HTTPS in URI in d/copyright * Move from deprecated $ADTTMP to $AUTOPKGTEST_TMP * Drop versioned Depends for ancient python3-sphinx, python3-zmq * Add Patch Call-wait-on-killed-child-processes.patch. (Closes: #689211) Checksums-Sha1: bd07dceb91b77e5191e1b1c6e5383d754a940dc7 2199 scoop_0.7.1.1-6.dsc a1f022a7abf9cd2f55bdf07dd13f7715c386b76b 7512 scoop_0.7.1.1-6.debian.tar.xz 7dd778fb1e72bfecc2851bc1dfa5f31c1830d91c 9983 scoop_0.7.1.1-6_source.buildinfo Checksums-Sha256: 73887afcc4421a41beae889bbbd845789fc315653d256d65dd40b80be8332ae8 2199 scoop_0.7.1.1-6.dsc 01ae9162f39101a3d16e77080abeb086294c0e07394665773107ff460ddbe918 7512 scoop_0.7.1.1-6.debian.tar.xz 621336150be0f73fd9e73a28abaa7dc7a3946ea6d57fe4f403a6c6b267d7b9e8 9983 scoop_0.7.1.1-6_source.buildinfo Files: ad1463a4ce5d6f888c2886c7d3fe4c09 2199 science optional scoop_0.7.1.1-6.dsc d67fd8367c56bd9417c8f2b363d629d5 7512 science optional scoop_0.7.1.1-6.debian.tar.xz e0ea4b044d4d0a844f9003d4d0d5b99c 9983 science optional scoop_0.7.1.1-6_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl4qtRgPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrHroP/iLO/4V00d8gDYXix6CCkURG06pDWhaSLLTp BgFXkKK0Ay2EzJuSj5zxNrOqpJD3JhReaDUmWlAj9ZbkGBbUUc4bvorZqP0J3EBE mlC+ukxQa+ZsDuRHcESCjraIKHdWOisHO/0FXfiV8moUIPCngJDE70AnvyJqggaT 6AO2IRgOfZdSwcX/BFFq39inY+VT8vUaZAaq7Dqls6qLYsVAPzSs0qTXzAmUXw/r 3tQ19bVYKe7oFuCZlWJqa8kuBVlownTVCbCBMNgGM3BCuXutYUOFvJ++fHOa8vww lQcTHr94FtNuflAF305dI78ruZ6xesViRnMHtgBUqwfC5ivSxtXApu2oPe1LwixS QATk4GGj+cmI0N3zbAJNL2mSAUwqlZ1pRE8JKtJyqgtIKeZvqijEPNEHe2suvkr5 Ugcb2dLIAhKBu8bn36ewhfYNtbL2A7T3jL9I7nIZuHuSlhPmf/JrmIwEwZOiZZ5M l1KCsoT2nmC+9irYqfWdSdt8gu7FMkqsV+UVTNffDpVANQD8K7a4Ujy0pGQqZTHa a6q7OOKtXjXg+TLBFi0JyT8rkOLuQfSgP0Rs2xduL8SXT9oWPcYxOHcqA9temmiE h+cKbIH1PcHhIYDfER/ri2oEFeD3S3M+QaYwji0GasM+IQZ/DyoEaxgz8c15eH16 Tak7K3RM =rMYj -END PGP SIGNATURE-
Bug#949692: ITP: tpot -- Automated Machine Learning built on top of scikit-learn
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 Description : Automated Machine Learning built on top of scikit-learn Consider TPOT your Data Science Assistant. TPOT is a Python Automated Machine Learning tool that optimizes machine learning pipelines using genetic programming. TPOT will automate the most tedious part of machine learning by intelligently exploring thousands of possible pipelines to find the best one for your data. Once TPOT is finished searching (or you get tired of waiting), it provides you with the Python code for the best pipeline it found so you can tinker with the pipeline from there. TPOT is built on top of scikit-learn, so all of the code it generates should look familiar... if you're familiar with scikit-learn, anyway. I intend to maintain this within the Debian Science Team.
Accepted liac-arff 2.4.0-1 (source all) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 08 Jan 2020 08:14:02 +0100 Source: liac-arff Binary: python3-liac-arff Architecture: source all Version: 2.4.0-1 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers Changed-By: Christian Kastner Description: python3-liac-arff - library for reading and writing ARFF files in Python Closes: 949594 Changes: liac-arff (2.4.0-1) unstable; urgency=medium . * Initial release. (Closes: #949594) Checksums-Sha1: 69e1fc2315d06190bf9cf0fb4153e3b951024867 2091 liac-arff_2.4.0-1.dsc b0d2274fe3ffb37ef048d81c7a89466498167b10 31228 liac-arff_2.4.0.orig.tar.gz 13358517d1c5a933c716ea8df7aa0cd114aa031f 2380 liac-arff_2.4.0-1.debian.tar.xz cd3efef4341ff00dddb0c2d66d664a7cdb2a4fac 6513 liac-arff_2.4.0-1_amd64.buildinfo 9a87d88578077d9a169c1c0dfd18674fcedb5f3e 14464 python3-liac-arff_2.4.0-1_all.deb Checksums-Sha256: a15fc5675e7e63456882181d30f4fd3b867707343f4182a97bcb88fca9f8f40f 2091 liac-arff_2.4.0-1.dsc 22cfd899ff6fda431984e9d9fe01dddba3dbe923f9c9779a84dede5e4f30 31228 liac-arff_2.4.0.orig.tar.gz fd41fb80ea966aece6a4ae2a5b66bf5ea87dc9f4b32b7a9d021e804fad0cac8a 2380 liac-arff_2.4.0-1.debian.tar.xz e9221d73fbf376802dcc15943e6f70093eff6470d92b778493232eff14418dba 6513 liac-arff_2.4.0-1_amd64.buildinfo 825f00e9ec8896526d016b2be7719d8ef9c516eadfec7bed89916cb87a28060a 14464 python3-liac-arff_2.4.0-1_all.deb Files: e8513b727ea2329bf2cdf1837bac85dc 2091 python optional liac-arff_2.4.0-1.dsc bbc671a8b96d802e117f59ce80ce21c0 31228 python optional liac-arff_2.4.0.orig.tar.gz 6de962f22e0c56e5a8a8c9f3b309ad73 2380 python optional liac-arff_2.4.0-1.debian.tar.xz c6c913a3d392efa7fe14ec98f082d844 6513 python optional liac-arff_2.4.0-1_amd64.buildinfo e7c3a189e62226a9f3aa4a3f8af85358 14464 python optional python3-liac-arff_2.4.0-1_all.deb -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl4ooicPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrPYwP/1kqixMzYW/F8KjJ4Tw/a/h8HMjX1GfoqDEp XV4n53HQnUZFbB/7btyLifrY1kY5Kxa+e8PHWUSZKtUszn1R37Y/ZYUlybk6clph 4gCjdx1MIAaDCEbc/V5QnbqFchGsHNZfBp0TAmMGSmmH4yQRxd2pocLVmnf7y36G Ex2jA/sb1ghV0Srff5Fak+ai+WUwPWXm0DZ4hPlmhTPWOnhJnB+fuDUYwamXpzA3 8GLrLBmNitdqhnvkHX4FuNpU6GW1djoxOWEcOkscCrd0+DU1l2GmTp1aq6UEFBlG owB2mWhns6vAaJdbq+svk4ntEs55HBVCy7MqfpaQ9WfV6zA+p1biUhQowig8kHv6 VmDhO+nk9cQS/nB1kRPchP0fbyUTiqUcZkYP/qL6q+ylDMHpuPvmoqo6JTC3hr8w zeX9e3d924JCTFjaxlQWfXKjMEwc10B8GcoYwv94nuCgw9qnStDyDDxsGo38jo0B 6l7+X4rncCkeBFFasjUo5L2djOWS6sbYygyeLuh4+NOQVjSU9eAZlacFtSMl6zPt j1ONaHkGXJc+67n1q3wip5/h789f/vnJuVMC15xe8f4cM/fj8yKm19ikNCpTHBw7 DBJEHN4r8eHAEvmJLGph5RGG3G36djABETtBz1+DIXyEt1V8HEOZqWDCQkPtJNBV LTXa9h7y =o/C+ -END PGP SIGNATURE-
Bug#949628: ITP: python-configspace -- module to manage configuration spaces
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 Description : module to manage configuration spaces ConfigSpace is a simple Python module to manage configuration spaces for algorithm configuration and hyperparameter optimization tasks. Includes various scripts to translate between different text formats for configuration space description. ConfigSpace is often used in AutoML tools such as SMAC3, BOHB or auto-sklearn. I plan on packaging auto-sklearn, and this is a dependency of it. But the solution it provides is generally useful for algorithm configuration tasks. I intend to maintain this within the Debian Science Team.
Bug#949594: ITP: liac-arff -- library for reading and writing ARFF files in 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 : library for reading and writing ARFF files in Python The liac-arff module implements functions to read and write ARFF files in Python. It was created in the Connectionist Artificial Intelligence Laboratory (LIAC), which takes place at the Federal University of Rio Grande do Sul (UFRGS), in Brazil. ARFF (Attribute-Relation File Format) is an file format specially created for describing datasets which are used commonly for machine learning experiments and softwares. This file format was created to be used in WEKA, the best representative software for machine learning automated experiments. I intend to maintain this within the Debian Science Team.
Accepted libsvm 3.24+ds-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 20 Jan 2020 08:36:36 +0100 Source: libsvm Architecture: source Version: 3.24+ds-2 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers Changed-By: Christian Kastner Closes: 936924 Changes: libsvm (3.24+ds-2) unstable; urgency=medium . * Set shebang when installing tools/. Really (Closes: #936924) Checksums-Sha1: f5a5504cbb16140500c22042271718d731d04ea4 2399 libsvm_3.24+ds-2.dsc d2d6335ca5be4dfa496e5407a4c1affea9d711b3 13596 libsvm_3.24+ds-2.debian.tar.xz d4e7fe4c384e27d3dddbcdd53efc10de6c1e05f4 6106 libsvm_3.24+ds-2_source.buildinfo Checksums-Sha256: 100240634b3d17545cdd24104eafbf1d3b9a66b1949754289489afe548157932 2399 libsvm_3.24+ds-2.dsc ffe8fec53a98edd89ff4c0172a00c4eb29989dce4532fbd365c1a752810d1a5e 13596 libsvm_3.24+ds-2.debian.tar.xz 4888b809d5afae39f801ca7c93c1a53e56a1036f01a21d2d3a9c046ae194ef5a 6106 libsvm_3.24+ds-2_source.buildinfo Files: 2f75b058870e6500bbbc77fbe74221fb 2399 devel optional libsvm_3.24+ds-2.dsc 2ca72fb5f3e4d65522501bafae2c721f 13596 devel optional libsvm_3.24+ds-2.debian.tar.xz 3c906007e4af17bde17e27b5b94e1c02 6106 devel optional libsvm_3.24+ds-2_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl4nF8kPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrVewP/jW897F0aZ/6BlJu7g17BGtRFY0QPlwI19a+ zpCepNMSu+L5zkg+482G41QGWWtyOcRzhaP2F8FcGGsXJkBDrcUBYX1v0YlvlxzA i2hz4n2Eb3sDz9GPS8zmA8FAC9ofnqMTCNvZo5Pu/vVPw1Jwgomxw3heFK964ur1 OFLB48CH4bnFUI3oLIShImkeVpzJCXPBf7c30NGoWugHOYWkTNE9+H2rSIvk5q9v lv/NIS/wRFBT4/FtiqnH/FGtrOu4GCiU8SlTAmhHkLU8MQZXZsvmi7gyeH/CkZ1A 2nOK61msGkygx8E8mtNRq8tImuTaqUAetzxBN7SaARWMOeRqq2I6D2cVneKzwfic Gf/VsFhNdc7u/lJTtXTUBEDiyUIQPhrGSDQ1L+sFnS11QHzQz7sT8DyY8bREfXv/ JwyaiImDpziEUBDS988KxuENJi/NwSS0lzvn1gkL8Jh22GVEtUpgJOJun1lnWKa9 rI9/j+vM/VTnvUD3Msx9CzgWq7t+6CLWq3n9nkBV/XBDAYWVDssvLQolvMTjx46o gsybmVIElw5/HQQ3tJVUbbpZWe80OBkNWM3Ehiby7WwLCCxwMnyt/gygfgBzHOCr mRFoxISFOnIxwK8qfKjWBMdsLSMMiLKckFFdVz1IX8LFIq2nkvO8Xwo9HDBsYY9Q 9R2PVtOq =vaGN -END PGP SIGNATURE-
Accepted libsvm 3.24+ds-1 (source amd64 all) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 10 Jan 2020 22:15:03 +0100 Source: libsvm Binary: libsvm-dev libsvm-java libsvm-tools libsvm-tools-dbgsym libsvm3 libsvm3-dbgsym libsvm3-java python3-libsvm Architecture: source amd64 all Version: 3.24+ds-1 Distribution: sid Urgency: medium Maintainer: Debian Science Maintainers Changed-By: Christian Kastner Description: libsvm-dev - LIBSVM header files libsvm-java - Java API to support vector machine library (libsvm.jar) libsvm-tools - LIBSVM binary tools libsvm3- library implementing support vector machines libsvm3-java - Java API to support vector machine library (libsvm3.jar) python3-libsvm - Python interface for support vector machine library Closes: 862234 936924 Changes: libsvm (3.24+ds-1) unstable; urgency=medium . [ Andreas Tille ] * Move to Debian Science Team maintenance . [ Chen-Tse Tsai ] * Acknowledge NMUs. Thanks, Olly Betts and Adrian Bunk! * Drop dependency on cdbs. Use dh instead. * Drop Python2 package. Create Python3 package (Closes: #936924) * Add patch build-libraries.patch to simplify proper shared library building. * Bump debhelper compatibility level to 12. * Let dh_install install from debian/tmp, instead of source. * Add lintian overrides for no-upstream-changelog. * Include man pages in libsvm-tools package. * Drop obsolete dpkg trigger. . [ Helmut Grohne ] * Fix FTCBFS: (Closes: #862234) + Move default-jdk to Build-Depends-Indep + Annotate python-all dependency with :native + Use a triplet-prefixed CXX . [ Andreas Tille ] * Secure URI in copyright format * Remove trailing whitespace in debian/changelog * Remove trailing whitespace in debian/control * Remove trailing whitespace in debian/copyright * Trim trailing whitespace. * Use secure URI in Homepage field. * Fix day-of-week for changelog entry 2.91-1. * Use Files-Excluded to exclude Windows binaries . [ Christian Kastner ] * Add symbols file based on version 3.21 * Set Rules-Requires-Root to no to declare that libsvm does not need (fake)root for building its debs * Also install tools svm-checkdata, svm-easy, svm-grid, svm-subset * Add autopkgtest smoke-test for the executables * Add myself to Uploaders * Use secure URI in d/watch * Add Comment to d/copyright documenting the precompiled binaries removal * Bump copyrights * Add lintian override for possible-documentation-but-no-doc-base-registration Checksums-Sha1: 946824781bccf027fd89da60c227131abccb1709 2399 libsvm_3.24+ds-1.dsc 3c74b7e72d115972d952ff03daa65ab733ad2f22 145976 libsvm_3.24+ds.orig.tar.xz b28c3e874fa3248cde8f68bb04698993835d0eca 13556 libsvm_3.24+ds-1.debian.tar.xz 7ba4fe57c42771dfeda7627b3f9054cc27d1deda 63416 libsvm-dev_3.24+ds-1_amd64.deb 16ea17fbc5d3389478c95bbaf4d3c9ad39769e1a 6152 libsvm-java_3.24+ds-1_all.deb d7cf9ac9d85fe8916f58fff6f213b06dd4b8fef9 33596 libsvm-tools-dbgsym_3.24+ds-1_amd64.deb 82110cf80cf25254e64f54fffb5c8cadd1b6df23 51428 libsvm-tools_3.24+ds-1_amd64.deb 1a3776c3471471db34ab2af4d258a1db9815ffde 71496 libsvm3-dbgsym_3.24+ds-1_amd64.deb ae2bcd0a9c06ef63166a78d5fc042a2e4cd7e4e9 58164 libsvm3-java_3.24+ds-1_all.deb e678fe56563e04005d1ab021ac98f012466cdd91 43280 libsvm3_3.24+ds-1_amd64.deb dccfed2f829e154d001631562be84b5155a18f17 10516 libsvm_3.24+ds-1_amd64.buildinfo f234e54458803042cb43d98eea4c607d75b672e1 17672 python3-libsvm_3.24+ds-1_all.deb Checksums-Sha256: 1661cfdf46a2c357e7fe2c89072596275bf2a60c9decb32b1a774c36aa5cf139 2399 libsvm_3.24+ds-1.dsc fd8fbf3179765dfcfdf949184b4b2c3c1a3a03834549ce48d42cd0269858f8c3 145976 libsvm_3.24+ds.orig.tar.xz 8d8727dbd891deded35ea1a88201d348003eec5ade88b11b35a717a36629dbec 13556 libsvm_3.24+ds-1.debian.tar.xz 6ef402c3cc8292096484002e25a6cb69b69306f459e8dd01b3b1c80b4f789b49 63416 libsvm-dev_3.24+ds-1_amd64.deb d2478a3dedfc1f3d056d2a01917162a797c9f721271cb87d51deb0f0d284044a 6152 libsvm-java_3.24+ds-1_all.deb 7b47c5869389489b27b889e73c472e1e52949fe0f3469e8ea260a99c047bf0c7 33596 libsvm-tools-dbgsym_3.24+ds-1_amd64.deb 52af314df7ad9b567a441434262fbde6131621d087db62df7e32d3c20abb38fa 51428 libsvm-tools_3.24+ds-1_amd64.deb 2c83194f70f302ec15354af47de5b8219ebbc45b0bdd8c2063bb48afb5e5b5e9 71496 libsvm3-dbgsym_3.24+ds-1_amd64.deb 06551b6382b9ba94e74aded87ab90747834e870e1afeda940579603f23af2f82 58164 libsvm3-java_3.24+ds-1_all.deb 1b6c6d69a8967ae550f230aeecde45cfa5e6beefcaddf33c7c5d11e859fc5265 43280 libsvm3_3.24+ds-1_amd64.deb dc80a4cf6bf58da42f56ed26211adb215dd3937bf99bb52f148f0cea56872331 10516 libsvm_3.24+ds-1_amd64.buildinfo 9bac77d32e80108e6ff656170980a0496aeb9187ea858f99e981b96a574c249e 17672 python3-libsvm_3.24+ds-1_all.deb Files: 4925d8adbfd1388897896c9bda59b2c4 2399 devel optional libsvm_3.24+ds-1.dsc 7e7216a934ec2850c26d26c59b449a2b 145976 devel optional libsvm_3.24+ds.orig.tar.xz fa95702d0ada698609e31269472e0cc6 13556 devel optional
Bug#948483: RFP: broot -- an interactive CLI directory browser
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 Description : an interactive CLI directory browser broot is an interactive CLI directory browser that * can provide overviews of large directories * can navigate directories * enables shortcut operations This package is similar to tree(1), with some helpful improvements.
Accepted python-cachetools 4.0.0-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 08 Jan 2020 08:14:02 +0100 Source: python-cachetools Architecture: source Version: 4.0.0-1 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Christian Kastner Changes: python-cachetools (4.0.0-1) unstable; urgency=medium . * New upstream version 4.0.0 * Create d/clean to remove .egg-info Checksums-Sha1: 2b665a7b3ce12d4040715477c2603d38544c6d42 2123 python-cachetools_4.0.0-1.dsc bc434a682b1ea3e87cad864d066071a2620d 20173 python-cachetools_4.0.0.orig.tar.gz 385c235c42aded15b02965060f0f6f78de4d1434 3508 python-cachetools_4.0.0-1.debian.tar.xz c10d8ce0f70865d8dee8cafcede59c3a1cc3b81d 6018 python-cachetools_4.0.0-1_source.buildinfo Checksums-Sha256: 5b70764d7e57879259238747b13a31b4df352ad80b24460f976fa1110d441cac 2123 python-cachetools_4.0.0-1.dsc 43a2a978e883a0085a4494346045027587095edc7957af07a0866e0b2e06fa76 20173 python-cachetools_4.0.0.orig.tar.gz a4b5527d54b6d710997feca2551341ec42b24c1bafa23eb83831f60330f9efec 3508 python-cachetools_4.0.0-1.debian.tar.xz 736519e5dfde6b4d9ba47d081b194f42c363b4b2d612aee39b07a948063cab62 6018 python-cachetools_4.0.0-1_source.buildinfo Files: b94cd2cd4171d9bccb84084c2737eed5 2123 python optional python-cachetools_4.0.0-1.dsc bf67fa898f9887350de0905a25da1f2c 20173 python optional python-cachetools_4.0.0.orig.tar.gz 962fac7705641a239dabd9e7c97e9a8b 3508 python optional python-cachetools_4.0.0-1.debian.tar.xz 7e09125e1e938c01ca6cfaa47dd95518 6018 python optional python-cachetools_4.0.0-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl4VgZAPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrnrEQAKDnnOmsqnZBa0rBh7SZgM9IOC6BvgH92pLw PEHj1ODvmx7N9ihUga5wEEAcBfFtvKBRJnOG44T8hZ3gj08coFNCcmoKFQw7XCCX k1HHVLeRo5BTozOxTYjDgigpMI0Uw52dj97/tJ0Q2TD5buAN+bZRMKYrbQmQ8VTU Ul2HF1PZaum//c04ocZ7/WUMOxUezxXjT+eIQvLj/2mKKujyUhmsxuizUP/JiJg3 y5/GbFtp4hFHva/ypf3T3nzJUgpYtB95LKVh8PzcfIXWm6jJykwUQloTuU9Yqn+f /sx1coEKtP58qalHzrFyGDpXPwCS5koSHaxkZd9c7LcKePmeIa2vyFWVLNg6yzcS NumJIA6hJAD5d0qExqquDxIWEo8ROfBK7NTr6dbSCnNGObTJ3ZO2uU5InDvvD8FS EEp7XSuu6kSfwFeOKgHyRTGq9/cPIMj9qHrFEDqGpwHkMA2ToV+TF/iUQq4Hq9KF B4clrdAsv5GNjRywx8E+Ga7HsfR5z2GWJtBpnm324R5PB2JXmJSqG7RQT8CYgbFr EV88yb/lx+29hxqDFS4HWEK5ZWxocV+/zCokdPYPeq4jlmaG8/iCgbzK/S3k2rt0 JPoPy6qEyiAcRWRGzyIr8Mm6+VYikKcd/cnG6w30MqOeXFxHBUIGzl9uH2rgKsKK Z6plFFzT =C3le -END PGP SIGNATURE-
Re: GPU-ready (with free driver) buildd/CI/porterbox?
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.
Bug#944261: ITB: python-seaborn -- Python data visualization library
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://seaborn.pydata.org * License : BSD-3-clause Programming Lang: Python3 Description : Python data visualization library Seaborn is a Python data visualization library based on matplotlib. It provides a high-level interface for drawing attractive and informative statistical graphics. This will be maintained within the Debian Science Team.
Accepted libcap2 1:2.27-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 28 Oct 2019 10:39:04 +0100 Source: libcap2 Architecture: source Version: 1:2.27-1 Distribution: unstable Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Closes: 911509 935921 Changes: libcap2 (1:2.27-1) unstable; urgency=medium . * New upstream release. (Closes: #911509) . [ Kevin Locke ] * d/rules: Conditionalize tests on DEB_GAIN_ROOT_COMMAND Unfortunately, for the tests, fakeroot does not suffice * d/libcap2.symbols: Add new symbols in 2.26 * d/patches: - Add Use-DEB_GAIN_ROOT_CMD-for-make-test.patch Use $DEB_GAIN_ROOT_CMD for make test - Add Make.Rules-Allow-overriding-DYNAMIC.patch Always build using dynamic linking. Upstream builds statically when building in a git repo, which conflicts with git-buildpackage. . [ Christian Kastner ] * d/gbp.conf: Move branches to debian/master and upstream/latest (DEP-14) * d/control: Bump Standards-Version to 4.4.1. No changes were needed from 4.3.0 to 4.4.1, but Kevin Locke noticed that previously, in going to 4.3.0, the Root-Requires-Root field had not been set * Add Build-Depends-Package field to libcap2.symbols * Bump shlibs version to 2.26 (new symbols) * Add pam_cap-Honor-PAM_REINITIALIZE_CRED.patch. Thanks, for the report and analysis, Daniel Gröber! (Closes: #935921) * Refresh patches Checksums-Sha1: 6232327ca6029317c4239ad9d68de80223a99194 2197 libcap2_2.27-1.dsc f2419ebf19b7bf682d346f28c2faf4635450c6fd 67780 libcap2_2.27.orig.tar.xz 4fb7bc1703b42a4e3d3668c39e2e6c291207e291 26476 libcap2_2.27-1.debian.tar.xz 078e6dbad112e846132755363334f4ef8934a009 5341 libcap2_2.27-1_source.buildinfo Checksums-Sha256: 4bb4eec00b2378bd1b534ddc1028ce7257166b8970d18b58bbc2717d2dc72905 2197 libcap2_2.27-1.dsc dac1792d0118bee6aae6ba7fb93ff1602c6a9bda812fd63916eee1435b9c486a 67780 libcap2_2.27.orig.tar.xz b8988a52b96a4e7de2ae2b4afcb108fc441c5f016d5f6bcc470e8b4534826d2a 26476 libcap2_2.27-1.debian.tar.xz 0b3d5b8650bddba0ffa6728b43ae060371483c6fb221a141fde46ba2db25081f 5341 libcap2_2.27-1_source.buildinfo Files: 9015d60584244225e0c24d50268ddc25 2197 libs optional libcap2_2.27-1.dsc 2e8f9fab32eb5ccb37969fe317fd17aa 67780 libs optional libcap2_2.27.orig.tar.xz 449ec23eb3e8bdbc2944fd64dd2bc79e 26476 libs optional libcap2_2.27-1.debian.tar.xz 26d72979ebf89b1242a97e8f3c0b4a5c 5341 libs optional libcap2_2.27-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl3CgY4PHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNr/WAP/3t2AnjxMWx75TIkFNj4EsxyWqFVIDY5oKW2 FIaBntirp+CIw5AJRzjmfycHlmA+Utu0s0FMFVhRH1sHZZNUQoqdMV60doQlz4by lVUYJmlwWGfQa+g+QMO6/kdUJfEV4ZPAXwGBw1B4uZNv40cGd7eFV/eK/U70eMXu GAf8BFdtz4U1QMCaFhdTtt5Owh7mIZzf7IbggEbvtqCVMNMGpiOGkYA+PcFvYfAc L0sNTcUNuRE8BhwoFA4RQ3O49JxtwCUef5o1b2QbRYjUCQ5QfEp5eSZmIbkMPc+7 tAZZ8j67sEbNl/mmPFlzTXAs9cx4OmIqab1pmjFs66NNqeF4ViNuHyTC6CQp+a/G npRHpIxDbpJm/UpgmbfQM860kmtwvo8n5SIMtDwXf4ZJktpMjuiha3KIundgc7L3 ltp00SbgvcfOmbsJUNvxx6V2yE2A0Lx6+yfZGar9wXVNhc/VuOeCn0O0tnvs9G2b +FuR/NEPpDEKvqXCc0dOIL+O0m6J5Lg3Tt9ewGHE6eQweZgWhsC4AjUuatLBoqKy uww99J+n+ganKNG4oaVmS5ERfTE8MGWiiyu0+fbPBbhb8S1N76kp6JbO2k4gT+x4 nK0kautyhlVzIlR0gw/A65KUoL/zgL5hH4MPBEQzMh8gSwlkUyf428aOVp2SuH4f Wn7QQLwt =KA3l -END PGP SIGNATURE-
Accepted cronie 1.5.5-3 (source) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 05 Nov 2019 08:04:37 +0100 Source: cronie Architecture: source Version: 1.5.5-3 Distribution: experimental Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Closes: 638048 Changes: cronie (1.5.5-3) experimental; urgency=medium . * Add Hurd-workaround-for-PATH_MAX.patch (Closes: #638048) * Fix spelling error in previous changelog entry Checksums-Sha1: db3c8127ef57bea9fd1b8b75ce7c7820c3312851 1898 cronie_1.5.5-3.dsc d10152a51b1b8230f7624999056178a19262aaa9 11988 cronie_1.5.5-3.debian.tar.xz ab07989a500d4d97a2c9ee2cd580ad1b58859e2c 5520 cronie_1.5.5-3_source.buildinfo Checksums-Sha256: 3fb916091d6c58de30f84bf23efde1bcd5c483d8259ae7db7d2fa5ce84c08405 1898 cronie_1.5.5-3.dsc 16a4b2db759115629508bee3807bedf2eb79eebab4db38ca5aae75d1a6ad5082 11988 cronie_1.5.5-3.debian.tar.xz 085df161ea24f0eaec96d61402d1e1f40504862a44d6a738fc6adf414ee6b0a2 5520 cronie_1.5.5-3_source.buildinfo Files: 51e32d91af85ac645cd58c5172a666ae 1898 admin optional cronie_1.5.5-3.dsc 6c197be5475335bb8599f4bddc658162 11988 admin optional cronie_1.5.5-3.debian.tar.xz 80779814e160ee7b174b0e6649ad8502 5520 admin optional cronie_1.5.5-3_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl3BHywPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNr+RgQAL6on6DtOyAti81QK7hXQWxFJVfqqP1xnjrQ 7xgT8HfUCg3xT6lyHZ/PcfCbOrxIHfhnmRCaRc5YV86iouJXhWdcxG3R7C+cTlxQ Fwm3LjMlc8wpt+LGkJGJ8De88DkJ/63kelNXnDFLI5xpO0t8h/9+NhG+2q3BEHh4 32sl+juZPSDhVBd29OGbxhIKn7nsPYqt/CapixME6Wr8E84os1nvaIbG95iELlk8 IUa7OOuoZtnOL0PFQAo79HFf1cZ03RtRmM3U1hXY/ngFgqt432x25+qm+KZ/rGGA 2SNjqA07wunww5QANNHnIVhPSbppuZZ45r7BOMuQM4YdpQydLpRK4Gk0Qv6sSK4e B8b/uWprurBcB9Bgf4CisY90YFOfq90Zul3k9VL7aufxlWBFy5ssh6ZoJlGBuxe/ o+ikjUo6sSjI93Nk1C/KzSXX9unI6TFwc0x3UMknb8IPc0fN4mP+0wIPgCnAcvDp C8dvv8E9LMZeFDCSuzLcg8UEPtq97tWzA+EK/Rg6Ydbjl9hs7q0d5SuKYyozbTOk AZ+tT5rIuQDFCBIQ2BQlOnu9dussl/IjCyM5l9E4Hd90yUtc27zSo23n4irKKqoj oiNUAXeC20/ecBDtNONq7O+7pBvp1DZZZihdPgYD5ErVu2pDQJcW/2FIkj0xOxnj f40hoD0N =S2X9 -END PGP SIGNATURE-
Accepted cronie 1.5.5-2 (source) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 03 Nov 2019 11:12:33 +0100 Source: cronie Architecture: source Version: 1.5.5-2 Distribution: experimental Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Closes: 944024 Changes: cronie (1.5.5-2) experimental; urgency=medium . * Dont' build /usr/sbin/anacron /usr/sbin/anacron is still provided by src:anacron. Thanks, Andreas Beckmann, for catching this! (Closes: #944024) Checksums-Sha1: 039258021814db69807b1eb9a321be4ee870f4a7 1898 cronie_1.5.5-2.dsc f078c0e72fe4786d89e8bb5966d9a5fe21df728b 11604 cronie_1.5.5-2.debian.tar.xz c7bac90dd9e31f09e1d5e450fad12156bb3c9f64 5520 cronie_1.5.5-2_source.buildinfo Checksums-Sha256: f47643ac22ad7cf3dad168580c7ccafd105cef2b6fac27cc39159c6347155ba6 1898 cronie_1.5.5-2.dsc 87798a533fd526fa593e7d74cdeaa582dfdd337b8e918dbaec3fd158bc2cc898 11604 cronie_1.5.5-2.debian.tar.xz a8c2fffb31c8d2c833274761bcd08b4a5154bc0d6830fd99e0911df57d73593b 5520 cronie_1.5.5-2_source.buildinfo Files: f931a7d71a0530737c2358836bdd832e 1898 admin optional cronie_1.5.5-2.dsc becfb53617a78cdacb52deef740bbeed 11604 admin optional cronie_1.5.5-2.debian.tar.xz 6d5005fa2c3c64b6f691ef0d2869c525 5520 admin optional cronie_1.5.5-2_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl2+qDgPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrqZoP/iY0AGYZww1P7fSWnMJQl506b4k+JaIdSEjU JGXWVIzmI3B5JQWDs1himHRaV2h5R906CsA4v0P+xDv2SkY1gFO+oIQTR4Csc6jr m2LGG3+PhKngEZC22flvagEGaXbVgdXpT64cZtZkzrRsFdFAcMYklnJngRQGOWhj gEICr1TXZZrgRr6dIjx6xsEWvFeRlXlM0tT9KSI4fHu8Urfn0YZ/o/uGPTA/KDxc r0Mobjk05J6sTKUIx/ptxNrlchyrlygWmLlrzEwFd6TPAFYrvsjV5LpilG5XYb74 BmcOhSrnLTU3r/jfk/z8k8PpQug38/SD/WiGKeDfRtGh2mYv668YlxsaHT04ZAPP BKMCtsE1p2PmB3bu5VtZs7mrRlTPtjrMeJ6wWoUDD7uFiimzSc+xvsWF5TRrInFf GRTmhMbXkR164GyJqMchDe1eUZmMZ/ZkVHHjdavRfI2Cg1pVyzDmhfF9pHxL5EVR +7a+s3ixhv68skEpPSV4o4mibXyVxBS4lHQfSrzSe2SUK7wM6M6wAROEDtS8LkMt QLIz+zpw0WyRVkqwsZaXvzg32ZkQXTOSIEspCIZsF0GCMgtMynrAc8Lkcou8ZYVQ LLxH1Y7Lvi1BBZvYLeNGuMr1VmYccVgNJCFKh29FkPrXzBYRGj0LLW7/Yqtra9d+ 60a+OPvw =P8cc -END PGP SIGNATURE-
Accepted cronie 1.5.5-1 (source) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 31 Oct 2019 22:20:05 +0100 Source: cronie Architecture: source Version: 1.5.5-1 Distribution: experimental Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Changes: cronie (1.5.5-1) experimental; urgency=medium . * New upstream version 1.5.5 * Drop patches (included upstream): - crond-report-missing-newline-before-EOF.patch - crontab-Add-Y-N-to-retry-prompt.patch - crontab-fsync-to-check-for-full-disk.patch - crontab.1-Various-fixes-and-improvements.patch - entries-Explicitly-validate-upper-ranges-and-steps.patch * Refresh patches - debian/patches/Manpage-and-typo-fixes.patch - debian/patches/Rename-PAM-service-to-cronie.patch + Split out Unbundle-upstream-PAM-config.patch from this one Checksums-Sha1: e28a5e7b17f2867687c0cb810cb65332dec361f6 1898 cronie_1.5.5-1.dsc 1e616d6d119b3b313f05edb381436e45f98477be 244045 cronie_1.5.5.orig.tar.gz 66882ae7196723caf918754d0c6218cf98dc5173 11516 cronie_1.5.5-1.debian.tar.xz 8183283b08a4293a13d38c620a4630b15a953654 5520 cronie_1.5.5-1_source.buildinfo Checksums-Sha256: 2e057340aa84c7576ed6de1724803a024625aa86c4e175f41c9bf33bbafc6ab7 1898 cronie_1.5.5-1.dsc be34c79505e5544323281854744b9955ff16b160ee569f9df7c0dddae5720eac 244045 cronie_1.5.5.orig.tar.gz a0b8693ffce2e5e531ba7bdea25081c5ce49227c64beaafa59e241cf01193df7 11516 cronie_1.5.5-1.debian.tar.xz 96397b43fee4f1f54af6e643b1733c5d7a03831dd63ee5c0f9589a37c15df9d6 5520 cronie_1.5.5-1_source.buildinfo Files: 15707169f8521abb523a10268da65ca1 1898 admin optional cronie_1.5.5-1.dsc 351a37d0b5bd0144816724b4482747ad 244045 admin optional cronie_1.5.5.orig.tar.gz a164569bfb61ebcf5e533a684e0a2d56 11516 admin optional cronie_1.5.5-1.debian.tar.xz 334e14bfdc7c42b25d9103b8b38de332 5520 admin optional cronie_1.5.5-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl29Nc4PHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrFlIQAKZaUfUWXPkw7lq+xlTadB+NTpk7K+FkQobF Xe8GDnVDBii7KFSpm2HfDlF+9b01B2/JWParACrA+whXP8uNmWzEZhwtMSiFDqiF e0xR7fqwdn8XFEn1FDrunl2s05Q+WBGFBfhV9HPOK/mhwoNxJ2phuI/honPziY0n znivtH4Ll4FF96dnbeHFD1JYBQOFAmUrPRkrFQeEd1xBQpzoWNgw74sl68XF0U+F 0SK4mqLYaoT79OspVmUlK+2+mIAQGIyEvaZNTWl8eATjb9fpg3cMKiSB+Len3H9B bM2A9ek6D3sJulhJqvVva6pf3aAFWQYybFjieJYzD3erqY0K0KyYz6wwHrHW82mh 5f2F/JpKiZfQqktkmJjQHACoHXDBeH97N7Pshnf2HNCz716wuwl4Y4kbjrhwakM8 NQo34DYJpDF6Eo2a+BtjeJIs0o43URyW+OLJACVMyu7sRoe5YDu8bn64zwq4DWvW dOVjsNSFX+CdWrrS6HVWnKmJspLLY4e6q6ct+V8hZX9yh2XwziYP/B0bMefVxCTy iTFR2GBFTojkym6WMnUQa2S7+9GAk9pf6O3mXhUdmvp0Fzj8cqY1a3/kyKju68Fi 3URcQkJv4YjwY/nMuTs/k+ruWpbbKb2J+5IVx7WkbwPZinD2h2yw7owc4kwGqBdC FfI29f9V =1pot -END PGP SIGNATURE-
Accepted liblinear 2.3.0+dfsg-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 31 Oct 2019 10:57:42 +0100 Source: liblinear Architecture: source Version: 2.3.0+dfsg-2 Distribution: unstable Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Changes: liblinear (2.3.0+dfsg-2) unstable; urgency=medium . * gbp.conf: Drop upstream-tag remnant from earlier setup Checksums-Sha1: fe5ad0758edcdb1dfae3308a3433a01664910f03 2328 liblinear_2.3.0+dfsg-2.dsc f26d0125705c5ba786fb04b68f3abf2c86763720 13528 liblinear_2.3.0+dfsg-2.debian.tar.xz 3d73b62de7d026c015b7164e23b3e533ee844a3b 5374 liblinear_2.3.0+dfsg-2_source.buildinfo Checksums-Sha256: 1205b51817c9ea46a7c74863699f1e4a02cc3000ec8e9544e971029cac1f696b 2328 liblinear_2.3.0+dfsg-2.dsc 613060019df37d424c420ca96bb27c41532d12602f0446aa913bd20b3fa8e83a 13528 liblinear_2.3.0+dfsg-2.debian.tar.xz 0db38ac6a087d6732b666a37c196862a21ec878583ef772f34423ac66302fec6 5374 liblinear_2.3.0+dfsg-2_source.buildinfo Files: 7041b8db32a2180d79f3dc9c9a6b4244 2328 libs optional liblinear_2.3.0+dfsg-2.dsc 09f118ef8a4012a23a55ce537711acc6 13528 libs optional liblinear_2.3.0+dfsg-2.debian.tar.xz 8a921137748c6738eac88d56631e542e 5374 libs optional liblinear_2.3.0+dfsg-2_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl26sQUPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNr/PUP/jK79BgUp81CKHKP34lxa5ZAJBp5EAkITeSh U30YxnQU/58I3RRK3lJmfFCxAMjE7zbKm0wEfegd5RC7/lO9oo3YWUpdJXiWal7m 2pYRnHs0Pj77Kt1/XeSR5kzExaNTT8KQevrU0yJiX/JXiFaFz56WTj5nwc2/1giy AF0om+p0Zc8zbxhb4I8q6wG2BWKMQE6B9kDkr37cz4dVGQuVck0ITcTAyXD/uSp8 tzSE+nHB/glBgsx7muayF6qS8QCCge9K1th8wPiH9dncpO+Qx6VrxqMd19P0Z5qo 4gLtxcn0QG3yu2z2XD+bc8freB3ES35yH5+NWxI50YTuoxq3BKOdmL0fbDO3jX9E B4O5qmVftXh8kXlsuKUuFDbO2r0MiwmG+TYm/jo5IfbWDevC8x8vJDNrsDNDBkX1 9paU3ogWonSkze5hl8KKJpyQ3RoLJh98bJXGlucCtL2ueQU2B/FtHcczQOuXgPJD sdBVJYE9aymy6KcfWuDV2KYejf5xldxdSoRqOx+WmNS39+RldtHGlbJFEKdV6MJM J55u7fLbciBZ6X8HFmalP808mnXkTQom59mt9fHLg87ophGS/m4ZA8m4/i9YuK8z yLx+E7psWsJrLvmb+MF83u7VUH3H/xlL9+LCmI0LLXfoEURyRcKNdDg56ZSqQHMN VJNcE4M8 =eg7X -END PGP SIGNATURE-
Accepted cronie 1.5.4-final-2 (source) into experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 30 Oct 2019 21:12:01 +0100 Source: cronie Architecture: source Version: 1.5.4-final-2 Distribution: experimental Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Changes: cronie (1.5.4-final-2) experimental; urgency=medium . * build: Set default EDITOR to /usr/bin/sensible-editor * d/patches (added): - crond-report-missing-newline-before-EOF.patch - entries-Explicitly-validate-upper-ranges-and-steps.patch - crontab.1-Various-fixes-and-improvements.patch - crontab-Add-Y-N-to-retry-prompt.patch - crontab-fsync-to-check-for-full-disk.patch Checksums-Sha1: bab03863ea6b2c2787939bd1c3a0aabc9bce0122 1940 cronie_1.5.4-final-2.dsc dd3da91f3e59bc99f7b769d4c56b0b754dda46fb 14316 cronie_1.5.4-final-2.debian.tar.xz a2fb7f9d51c1efc7fed66d3acb4a97e8b3bad43d 5544 cronie_1.5.4-final-2_source.buildinfo Checksums-Sha256: c6e44c31beaeacc7a364b79cf6ef254425bd0321fc7da75a04924466b41b9bff 1940 cronie_1.5.4-final-2.dsc 9d02c3eca902352585c0842e5fad315e52718edfd36f270570a2ae09d926fff1 14316 cronie_1.5.4-final-2.debian.tar.xz b61e5ccea1ff760e361fb4104e55d39fdd0953a63d00dae7a65f15f9ce519f7c 5544 cronie_1.5.4-final-2_source.buildinfo Files: 1402b2f82ac73ff3f32a5e582f398958 1940 admin optional cronie_1.5.4-final-2.dsc f9520e5d5be9881a1fcc062651119412 14316 admin optional cronie_1.5.4-final-2.debian.tar.xz 769d72ba0747b9b7b61d0a18d1c9c98e 5544 admin optional cronie_1.5.4-final-2_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl257tQPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNr7kIQALRGlGnvJQN7D0pG08J2D3n7V7j//iBkbSAQ RbUZ1VLYIOx1xT7Jo2qVwoHr5CcqSksoWU1fE1+5pQtI3Udb3CnYqaAF23IdniqH sTlOtzef2Vo7nclHqLm/BKwB1wfuS+7k97KW04bXifEvsqaP6ac4SWP7GWRsaCkD tgPGhAjdV+h00GKSY+NRqYQxZmJIUYm732hHDaBcsONaPJ3/6XadrLfzsDHj5Jcv KmxupOsehxzrK0pbKRk3M0ZFU2QDJiDUZv6XzJrOfQYsmF75wgLm496QPrnx1qdZ 9dho6IRywydE6R5zNV2BDZIfbMWBxNX1YR0an2pkOXDVS/jyYqHd/exEVtiDV5c9 /8fAcJJhlkJk8NwmPaTMlgn78D5Rx6H3krjr84EtiPhfTsX7Ns2DCTrk09ETnAAZ xAJ1VayOVdAUa626GWEF8KkTSkg6Tc7nB9OscnTzAqqSJv2aZVe10NgNBYrkxoA/ offj4qfiKvrN6Len9eShk31CM3pSgSJjZWb6JJQEvY6U2t0wPu7QYkYsIazh0Zd/ cBTtYpvPQax5JGzIVkPBq2QLcOrF2rVFbyIhA8mCJeamhRxjJcGCQraVbbUX6SRV GVs2jg0riOYL/O/DJ+MHfK02FnV2LvMsuzbcPWylGKaE5snmzq9vr87cI4HeOPn3 1th8c040 =/sKZ -END PGP SIGNATURE-
Accepted cronie 1.5.4-final-1 (source) into experimental
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Mon, 28 Oct 2019 19:35:38 +0100
Source: cronie
Architecture: source
Version: 1.5.4-final-1
Distribution: experimental
Urgency: medium
Maintainer: Christian Kastner
Changed-By: Christian Kastner
Closes: 697811 783856
Changes:
cronie (1.5.4-final-1) experimental; urgency=medium
.
* New upstream release. (Closes: #697811, #783856)
.
[ Andreas Henriksson ]
* debian/watch: update for cronie move to github
* Modify patches to apply against new upstream release
* Add debian/gbp.conf
* Adjust and ship the cronie.service file
* Use debian/clean to remove src/cron-paths.h
* Fix lintian warning about not using default-mta
* Fix typo in patch tagging meta-header
.
[ Christian Kastner ]
* d/control:
- Switch Build-Depends from debhelper to debhelper-compat
- Bump debhelper compatibility level to 12
- Bump Standards-Version to 4.4.1 (no changes needed)
- Remove now obsolete d/compat file
- Set Rules-Requires-Root: no
We don't need (fake)root for building the package.
- Point Homepage to GitHub
- Set Vcs-* URLs for Salsa
- Mark package cronie as Multi-Arch: foreign
- Add Pre-Depends: ${misc:Pre-Depends} to binary package
As recommended by lintian's skip-systemd-native-flag-missing-pre-depends
* d/cronie.default: Add new daemon flag "-P"
* d/rules:
- Add hardening flags
- Stop passing actions to dh_installinit
This has been obsoleted by dependency-based booting in Wheezy, see
https://lists.debian.org/debian-devel/2013/05/msg01109.html
- Use DEB_HOST_ARCH_OS from /usr/share/dpkg/architecture.mk
- Proper passing of CFLAGS through DEB_CFLAGS_MAINT_APPEND
* d/copyright:
- Fix syntax errors
- Switch URL to official policy URL
- Point Source to GitHub
fedorahosted.org has been retired
- Bump copyrights
* d/clean: Remove generated files for (non-enabled) anacron build
* Sync maintscripts with src:cron
Checksums-Sha1:
d144060ccef947af419a95362ec76a2811d91924 1940 cronie_1.5.4-final-1.dsc
d7bc078ca4974da528de8f1e99b9b65e0d9bbb3c 122469 cronie_1.5.4-final.orig.tar.gz
97794325ae138f88a5ce3e234d109886cdd37fbc 11148
cronie_1.5.4-final-1.debian.tar.xz
2b24b96573901ece2907baacb00bbef3796d07c0 5544
cronie_1.5.4-final-1_source.buildinfo
Checksums-Sha256:
032e40f3248c0423b8b236a8f3d21f6165507e3618faa324dcd18968eb750694 1940
cronie_1.5.4-final-1.dsc
9cf561fc165579e3109ad331b49208e374f8ccd0c3e1f165113c6dea5394681a 122469
cronie_1.5.4-final.orig.tar.gz
8083d4071e1c2338387c5edc1af1ce553e8cc1021eb081241f4ad0d4b77f9be7 11148
cronie_1.5.4-final-1.debian.tar.xz
891b133d8477cb672fa10ec023c692d5e934457a4823f04263215634064c6655 5544
cronie_1.5.4-final-1_source.buildinfo
Files:
d4dea6511c41cfe275cc14c99fb9a89e 1940 admin optional cronie_1.5.4-final-1.dsc
3fa192920139052f324ed10911f13617 122469 admin optional
cronie_1.5.4-final.orig.tar.gz
9e22982ffc177e2f3ae6e805a018da27 11148 admin optional
cronie_1.5.4-final-1.debian.tar.xz
1e8ea20bacb5a94f7b8742f3a6b772af 5544 admin optional
cronie_1.5.4-final-1_source.buildinfo
-BEGIN PGP SIGNATURE-
iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl24n5EPHGNra0BkZWJp
YW4ub3JnAAoJEDmVOjfeTrNrpREP/1wCysifjjRFn+x8HsK8OpG9f9P+Vd+PTqJ4
l4wn/OrwAfvIM6xFzZEeLdiGLJb72J+seAh5j80wUR0uFIovEcwnxXZgbp0H2wil
28ingVKwEtESJHREinR67Yw0dbR3EuhxLCKeE58is3WYbpw8Sd2yz8i6cZ0H6gux
+fR8/E6ToY/hq4QbbBxaLuepjI7jeL6J+8Y9B0uGEb+/NX/1QV3d/jTbYL2C5OoM
Mi8A4Ar3OYkt2mS7cSkiQWg1UyEKMMqzhe5d2a5cgkz/egj9oWYsbkJzrUzVAND3
krzWkAonF9CSAjeGm6YcpOgmkzyRE+cOQPAioltmoqkoDXsjUBlQkIFFxQWkS3Wx
MLLTyHx/xtEXcvxOhwvmz1f78T7T28b44wtylQsGm26z2ps/6uaC8YeYsqJVAUt5
RKKdOhpnTnZRwrSVBjp6nifYQW4ZtcayPHMBTO6Wi9Z9gRRr/FvZL99mFyROLIGQ
ZhlWrGwADNEt8z5wRCgMq9Zs9MBAU5u5bVy4bVwF8/NtOUTfFkgaPJrw3KF65M8/
CUjIlIb+KmCn0J2DizoEPePXJSR0nlzm9trRo4iqhTkmqGjQOUsdDK0Wol92PzzK
qBl0cpwcwxRp2caJfgxLGZ8wWvnNw6IuJvrpEbmHMVZd4px+5PM7KErnzxYvgvRM
1y1g4FKV
=M717
-END PGP SIGNATURE-
Accepted python-cachetools 3.1.1-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 29 Oct 2019 18:48:41 +0100 Source: python-cachetools Architecture: source Version: 3.1.1-2 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Christian Kastner Changes: python-cachetools (3.1.1-2) unstable; urgency=medium . * autopkgtest: Move from python to python2 Fixes a debci regression, in assumed connection to the py2removal efforts. Checksums-Sha1: d3b445ab776573483e9446ee6fbcedd8482752f1 2221 python-cachetools_3.1.1-2.dsc a8e3c5aeaaa8b90f2b427da8024539edb4991bc8 3516 python-cachetools_3.1.1-2.debian.tar.xz 2dca2a60ac2e1d7d9bfe16a9b615f345efe069a2 6266 python-cachetools_3.1.1-2_source.buildinfo Checksums-Sha256: 4afac3410415b615fe2e642c63ac857d65bec6901773eacf1991e04f5df7b9bd 2221 python-cachetools_3.1.1-2.dsc 866a2113c5c62b7680ea5b5c2707ee89d5f654ccf0a6d1a001489ed86aad0a5a 3516 python-cachetools_3.1.1-2.debian.tar.xz e426f10e1b8228b761fcea58445c2a5b977a70788f2ef68731e16ffd3360c571 6266 python-cachetools_3.1.1-2_source.buildinfo Files: 54df568eba42b2f562b24dbea99cef93 2221 python optional python-cachetools_3.1.1-2.dsc a395ae1001a7f767ee95f52e7cc0517a 3516 python optional python-cachetools_3.1.1-2.debian.tar.xz 21b18673bfeba7cf550e333566b82c8e 6266 python optional python-cachetools_3.1.1-2_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl24e8sPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrJIoP/iBEC5Ou5vwqWnpymR5u+m/eViqEw72Z3CuI VViF6S2DfbDtzNxpPz/HjPf5a2E0Nh8lOlAeqKmQFwNxnQVF5YSLCkyzv0RE7ccq 6N5Mfo0Oyqmb5XZ+qf+gcHaLGn+mq1f2OXtpZWfSEnT5t6mA5d9BEShsQIVyXBmr J0Wu7Zrt8Uxrx6EFB7uVPsc+3PG9O1lXn6Kz6+aZn0gevSgAsFeIyE1z3n4/IbvP sCR9bfSrWkFgoEDsIXcHP4SqOjbn4hRh4fXv2koS6FrRDk51tI4xP063MOiPjekU 1DRWviyEJgLI+rkSizQvuRvtalbZR89EVLFeD2T430Tkj1jBjcvjLJ5ctH5kLmJg 0DAfGul7Ts+qNv4elWi2hQocYfc0yroL0oGChWndSqrnnbAY5bI5gg3ThZzm2JjZ xbhU5HnzJWWaZbS7jxx28T/uug45PXIWLpHIUXa4FZCLZZqbf7sQbGljgGAzLHe6 c3epFCCIGE8bshRZfhie+GjFkKLaTTiwwN/rtXh5ovbh8cibJXHzxtPdXrBcLv1S 8Z3ypULuOWOLtW9i4uuvT7tbT/Mt6AA+76c1Y/uLg9axmW4Bf8f0PkITo7Uo8Z2e 4gFmitluUUhobT6eHDj/8esACeU3ceJewElncljhlj1eqYwJJEhkhLqkgU8eCS+G EXJHsK7Y =eaMq -END PGP SIGNATURE-
Accepted libfann 2.2.0+ds-6 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 23 Oct 2019 15:17:15 +0200 Source: libfann Architecture: source Version: 2.2.0+ds-6 Distribution: unstable Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Changes: libfann (2.2.0+ds-6) unstable; urgency=medium . * d/control: Bump Standards-Version to 4.4.1 (no changes needed) * Add Build-Depends-Package to symbols file Checksums-Sha1: 8a2b146f2be3b7d7b0bedee044198e6fc0dd343c 2089 libfann_2.2.0+ds-6.dsc 29e65aea921cbbf3ad672e2f96bacfd4758a5e70 12624 libfann_2.2.0+ds-6.debian.tar.xz 9fdbc9f6aa7337ed8ac35089f9afb0f937822fe0 6182 libfann_2.2.0+ds-6_source.buildinfo Checksums-Sha256: fbfcf9fd3df2016a8d94d0217b0996bbe382cd230b6c738b67f11bdc4d06911d 2089 libfann_2.2.0+ds-6.dsc 41a7de2b3a9d1afe82356108f73eee46f7c6a8e0ebbd7b50effbd0177236ee91 12624 libfann_2.2.0+ds-6.debian.tar.xz 8eb33d703f053ee3eb315b4a2f8102c63961d3cb9400713ac2b21c32cae7b4c4 6182 libfann_2.2.0+ds-6_source.buildinfo Files: ed2f041c041e58028f3e2c453ff3999c 2089 libs optional libfann_2.2.0+ds-6.dsc ef491769fa0165f37ef72defd59e5e06 12624 libs optional libfann_2.2.0+ds-6.debian.tar.xz 3b441e21086592a8f6302a0a16432bc7 6182 libs optional libfann_2.2.0+ds-6_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl24QncPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrG/kQAMHBsddUnr1yolauLOS+vp/l77mDzBv6Ej1Y XbeGA/qUGxOke8zi+kN8ZikFPFQ67akwgWmlDhlAFatiGsR/RIWcc4xk3QDTXiGs kQsxDJCrw+1TJOEL551OqS7/oBiXDsavNoBZGoFH5Jo/HTFGvl7XDyaCJsL2YzXY p254fBuSsWV6gSyUooL/WyheQcg2s17c6bNwSMNSy2RoF/cB8mP2sZa8ylA/J/Z4 94dYMCn38QKc6ZFuh9xq7m3pay9rWRT1FVYXeqK237QhOqtCVbB1GXSG3LF1B0vZ Zwo60c+6JGOvA7t5Gu7g1PJjxGDJed/qY4Ghl9T9cuAFzMet2gigECHvU23CN0Ur KopZiswTKc70gMF9Zql8Ih9t7h7PHXMgb+muD33edKThM5QG+WHM2UskQJS2qL1R Z6KrUchODCW6KPPxyrd9P1Bgcgd3GlhV8xdSweubTN35E7BKditRVtGMN4WjqO+C MFCP7oc5UivZfa3aNvyebeg8tpLpZBe2dtyD+ioatndXKcqMoX5a/sHE+TTL4VS8 3CMxd5yLRguXvy7bdF+DGy+27JP5+Mb0Q8qqAcmPyFCGRyC5zJrM9OaoRCYIFqwn gnOgpcmqD8HmhHY+j2J+sAnTCqbAgM82EUvAVz00FAAhE/crWCtDVwAmURemTT2H akF/2Xn1 =Gx21 -END PGP SIGNATURE-
Accepted liblinear 2.3.0+dfsg-1 (source amd64 all) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 22 Oct 2019 13:00:10 +0200 Source: liblinear Binary: liblinear-dev liblinear-tools liblinear-tools-dbgsym liblinear4 liblinear4-dbgsym python-liblinear python3-liblinear Architecture: source amd64 all Version: 2.3.0+dfsg-1 Distribution: sid Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Description: liblinear-dev - Development libraries and header files for LIBLINEAR liblinear-tools - Standalone applications for LIBLINEAR liblinear4 - Library for Large Linear Classification python-liblinear - Python bindings for LIBLINEAR python3-liblinear - Python 3 bindings for LIBLINEAR Changes: liblinear (2.3.0+dfsg-1) experimental; urgency=medium . * New upstream release. - Bump SONAME from 3 to 4 The new release contains backwards-incompatible changes to the API - Refresh manpages . * d/control: Bump Standards-Version to 4.4.1 (no changes needed) * d/copyright: - Improve DFSG note in Comments - Add Files-Excluded for generating DFSG-cleaned sources - Bump copyrights * d/rules: - Override_dh_missing for --fail-missing - Drop now superfluous get-orig-source target * Update symbols file * d/patches: - Add Bump-SONAME.patch - Refresh patch Improve-option-parsing.patch - Add patch Get-rid-of-bundled-BLAS.patch * d/watch: Add repacksuffix=+dfsg * Drop now superfluous d/source/lintian-overrides * gbp.conf: Get rid of "dfsg" branch; use "upstream" directly * Let dh_install install from debian/tmp, instead of source. Resolves a warning from dh_missing. Thanks, Niels Thykier, for the analysis and resolution! Checksums-Sha1: 9ba31fafb10c1e526685a9b18c285b958391d665 2328 liblinear_2.3.0+dfsg-1.dsc 1c8ef5c89b2753c8bdf0f2c57310754f23f9f004 49504 liblinear_2.3.0+dfsg.orig.tar.xz 267a8bef417f416000b5b6bf11938497fff200ed 13520 liblinear_2.3.0+dfsg-1.debian.tar.xz 52207840c7d58f6bdf952ddb7400904e46fab2c1 35448 liblinear-dev_2.3.0+dfsg-1_amd64.deb 9f324889bfcd51ba90857f1f17f78225563b1e21 27820 liblinear-tools-dbgsym_2.3.0+dfsg-1_amd64.deb 00f4d0e148faee995b8df7d7918a2f1d687637ad 23004 liblinear-tools_2.3.0+dfsg-1_amd64.deb 9ab376aa3baad15565d96510c6582118bf3441df 76096 liblinear4-dbgsym_2.3.0+dfsg-1_amd64.deb 88af112ab07af42003696da01c13650d9249bd1b 43380 liblinear4_2.3.0+dfsg-1_amd64.deb 0de11b108eab9caa87cdfdaf9ccdff456d4c9bb9 8183 liblinear_2.3.0+dfsg-1_amd64.buildinfo 53f69c4282b26c0baa8b15f65671f2bd9a638515 19100 python-liblinear_2.3.0+dfsg-1_all.deb 3c88d89e78cfd05da65ae9d80179142e1e7f1fa9 19000 python3-liblinear_2.3.0+dfsg-1_all.deb Checksums-Sha256: 8a594855372201a3f76aff445b34dc4202764383813ea2cb36ba5b4a8a28b86b 2328 liblinear_2.3.0+dfsg-1.dsc 8e3b935fdf638c6269111f0c9f3da6a8074b2b34c640f24108f38a13322d9039 49504 liblinear_2.3.0+dfsg.orig.tar.xz e3c7b655d3366b22fa8f4d41cf60066ff09624636ec4c5ba818e0e85eb6d3bf1 13520 liblinear_2.3.0+dfsg-1.debian.tar.xz 785af58bb2d4c87dac5aac525c8ab4cd17690d2ca4b4093ab15ba982711492f8 35448 liblinear-dev_2.3.0+dfsg-1_amd64.deb f36c5cf1e664187e461258be0b40853405891a23410eafa516eef45d279dd319 27820 liblinear-tools-dbgsym_2.3.0+dfsg-1_amd64.deb 6018fdfe103d5976092fcb1868be0aa6d04b075d30398434181e048187f1b307 23004 liblinear-tools_2.3.0+dfsg-1_amd64.deb ee4e86650955ac7247d5eb42d6d14d4087c2481d86a8088538b01219aae49113 76096 liblinear4-dbgsym_2.3.0+dfsg-1_amd64.deb e3c3d77b44b13a11cfa272b686cb707f7e22baa140a2f3f2991649434d43f290 43380 liblinear4_2.3.0+dfsg-1_amd64.deb d8e779610a8a4d3d882cc13a3aa03410652bd392b8c821a68bd363ad3f753e11 8183 liblinear_2.3.0+dfsg-1_amd64.buildinfo 1530871db25da857b10369cf4b34c7634f3b4270fc458e018d0160bc0df0e204 19100 python-liblinear_2.3.0+dfsg-1_all.deb 817a0053403969a3f27843828b4b089b2f523b8502250e71941e9205e1776ec4 19000 python3-liblinear_2.3.0+dfsg-1_all.deb Files: 499cafe4412430a8b62f75a161f27087 2328 libs optional liblinear_2.3.0+dfsg-1.dsc 828f90a02b4dcfe0d92db1260b4b205c 49504 libs optional liblinear_2.3.0+dfsg.orig.tar.xz fe91bdc99f6f27798526719b86bbe97d 13520 libs optional liblinear_2.3.0+dfsg-1.debian.tar.xz 5b272b1255a58eb2102d1fc149c0aa59 35448 libdevel optional liblinear-dev_2.3.0+dfsg-1_amd64.deb 37a547be95d2b749d227e250ccff7491 27820 debug optional liblinear-tools-dbgsym_2.3.0+dfsg-1_amd64.deb a0c5322492eb9f6487880e70d25d25f2 23004 science optional liblinear-tools_2.3.0+dfsg-1_amd64.deb 9943b8050d1a0ba5036aff49b03f691d 76096 debug optional liblinear4-dbgsym_2.3.0+dfsg-1_amd64.deb 72563621b076119a20e70042c348ce96 43380 libs optional liblinear4_2.3.0+dfsg-1_amd64.deb 68b2902960a49be4c153a43e39d91c1b 8183 libs optional liblinear_2.3.0+dfsg-1_amd64.buildinfo 0c5080be50cad2d1883d6795422a5670 19100 python optional python-liblinear_2.3.0+dfsg-1_all.deb 427d736b6a9e205f5cbea0aa608435a7 19000 python optional python3-liblinear_2.3.0+dfsg-1_all.deb -BEGIN PGP SIGNATURE-
Accepted python-cachetools 3.1.1-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 15 Oct 2019 15:18:52 +0200 Source: python-cachetools Architecture: source Version: 3.1.1-1 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Christian Kastner Changes: python-cachetools (3.1.1-1) unstable; urgency=medium . * New upstream release. . [ Christian Kastner ] * d/control: Bump Standards-Version to 4.4.1 (no changes needed) Checksums-Sha1: d7d5c5fcd9e7f7edc3e6c48b3b49de3625c39aba 2221 python-cachetools_3.1.1-1.dsc a31438ff0139d8283eda16aeae2b09a839f40dff 20452 python-cachetools_3.1.1.orig.tar.gz 547f62993d6d1cbdc27849e2920ad344d748d12c 3460 python-cachetools_3.1.1-1.debian.tar.xz 91ce4dc544c77f390af5f9c31a383c9126cdcb91 6275 python-cachetools_3.1.1-1_source.buildinfo Checksums-Sha256: ae5e12dbb6ff775a243667244df6988375b8ed255b1380598d89bf4fb651be22 2221 python-cachetools_3.1.1-1.dsc 01ee1c1a94ece91cd18f5b2175156fd9089830e78f7c4241ab84cd3315bd60d1 20452 python-cachetools_3.1.1.orig.tar.gz 40285545eb2560e62dd724cbe6033092e1914abbb90e8f164ef570a51f3769ca 3460 python-cachetools_3.1.1-1.debian.tar.xz 323547591989ee1824d9ed65309cb343aa836513e953a7a0b65757a6be2ed5c3 6275 python-cachetools_3.1.1-1_source.buildinfo Files: 18606741a8e87bca208b186ee3e0e187 2221 python optional python-cachetools_3.1.1-1.dsc 9e2c19eddaea0c4e8c64ddef2abe4fc0 20452 python optional python-cachetools_3.1.1.orig.tar.gz d9063ceb84506322dd6ac73427a7f563 3460 python optional python-cachetools_3.1.1-1.debian.tar.xz dff3b59156e80443174dbe2f30b013dc 6275 python optional python-cachetools_3.1.1-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl2wVEQPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrRnQP/244+E0TV1qcWZ0m6LfscO4Z7ZfS46Oe+qhO My8bknVQxhhAGBiaNQe5iwQXu3XGfuvjXAE7P5aYwyaoCaDVz4GpnLZcCcwFxaov pvdeM2482XtSxvfBEEJ71LrizPl9mgsLDeGr6fiz15zZIx88OrRiCusSnPKauS34 iOLT4rqebig7P8LGsRpx/daqtvw3BSiH0WH8XLdTbuQwjnp1vpuL+04y3TStKMy3 OzDZfp617u9j/T+daSVuOsRxGFwGNBpwZyacICp4lnOJDhISNm4XfOeMdukGTpxZ lWjb3wzyRTh3jzUG8R/T8x/0M7kkc82jjlkcTazmLpHPR00E7c2majjpl4b2/exc gtzvONJyNlxPDLYIPclRfHctvbu/PCX4sDgRoyXtujkOxouSOPGFQEDc3heepXAv 8bh2apxJIRRax82vAqVBBoTKF+oxjysSu1maooGZ1mlypzApE4IVYPg0YGPmiCrO YuxUJKl2JtyFSSRvveyS4v3bS/WDnO6dknWQ6kRsEuS1WDCNVtNmq6kKhq0fQb9G iDfKeOOX/6PYV4YLpaoz6gCX/eE58Cn8KPUGhfAL8oSme7sRHmpkXh8xPIKRw7Dr fBV+tp5kZsQVZU7SJtUMa6H3yEyaUqfxTG7siWZTijP9P0qawF0HZRxFjTWQvVfD Vq3EzCLs =K6Ro -END PGP SIGNATURE-
Accepted pyevolve 0.6+git20151103.589b6a9-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 15 Oct 2019 15:47:22 +0200 Source: pyevolve Architecture: source Version: 0.6+git20151103.589b6a9-2 Distribution: unstable Urgency: medium Maintainer: Debian Science Team Changed-By: Christian Kastner Changes: pyevolve (0.6+git20151103.589b6a9-2) unstable; urgency=medium . [ Andreas Tille ] * Set Debian Science Team mailing list as Maintainer as per Debian Science policy . [ Christian Kastner ] * Bump Standards-Version to 4.4.1 (no changes needed) * Add patch Fix-spelling-error.patch Checksums-Sha1: b99918e1df791ff53bc76723a752ea0196ca80ce 2353 pyevolve_0.6+git20151103.589b6a9-2.dsc f6fd9ffc69793db16525aa333e2b9b9594bd3253 11448 pyevolve_0.6+git20151103.589b6a9-2.debian.tar.xz 7fc377feed1c1730f9f7852289088c8cb423a463 9282 pyevolve_0.6+git20151103.589b6a9-2_source.buildinfo Checksums-Sha256: b06a7c7af71f6476ee371f34cc586c9101ad3d0ec08805e0237bce035a30f1c1 2353 pyevolve_0.6+git20151103.589b6a9-2.dsc 6712f54dda848d02147e0338c49b5be9f68776fd236740803c656a68b43c49ef 11448 pyevolve_0.6+git20151103.589b6a9-2.debian.tar.xz 420cf7f5909bec213a600af0202ef806387445c9420c770b2a4c4ba3c43fffd6 9282 pyevolve_0.6+git20151103.589b6a9-2_source.buildinfo Files: b1b423b0cb881b9ef064c9af8b7fdcc0 2353 python optional pyevolve_0.6+git20151103.589b6a9-2.dsc 90b0b77f4728487392851a479a505089 11448 python optional pyevolve_0.6+git20151103.589b6a9-2.debian.tar.xz c99d4ebb09b8ef1a27828b6e134668d4 9282 python optional pyevolve_0.6+git20151103.589b6a9-2_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl2lznAPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrn9sQAJo4maYhTTrak7PwjghVyygEbwZIIZITQp2h n2iCaVvNruvw9wjMmXkqOzS75kBWKlvpYHDkBXdFdTlXco8MbBS11DRbgU9OeU6o eQRRuyJ4fnZBDbwhhw9KDXtLV003KM/bNjGlKNbe83IXYoHOhEyfOznRyM0eB4xm i2r7TDmCkq8TFz6CKUTT1rCt4iotBSgQ8DIc3G+CNdnOoVQ9+2kGeQa9O1gtppmW y5AekYGHuETWrOGjaxAkmmK0JTYJW9kbHUAkMWYJYjsHYL/MpzwvMcx4CqlLzb7I e7gJYpln/LdU+HnJeSe0nKnXNgQM6IS4+mvWkR+QOUxjfuYlL4kqghUhlr5EBVow uSUHQWiehw9Zhi/fGIWVfP8uG82A/iFhZ6g6Mfp41lOAV5dYefUBCvUylKHFvvav Y9NnHQ74hg+5t6wIGqUWicOHC88jK11DVjB54yI4+xfghpAQV16ofjMvxuj9pMDV Itw2Fmafy5Mvgkzxog0oYH5AJPvlZiQ8jVfxtf+rfNk8No9c+oqLTF18uFCz3OZ9 G6hbymSR2skQCN5wqG7mdjj/Fvx+9jfdenZQ3cyUtMcPgRJSz2a3uRG3ESaYusGS U3BW3kMnUNkIR4cNsJQTNwJz2zsiTEcKBR5ukuqnuMW+Xv/0LuodHvpne7yc7I7W pyawgDn8 =OwQj -END PGP SIGNATURE-
Accepted libmpikmeans 1.5+dfsg-8 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 14 Oct 2019 21:39:18 +0200 Source: libmpikmeans Architecture: source Version: 1.5+dfsg-8 Distribution: unstable Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Changes: libmpikmeans (1.5+dfsg-8) unstable; urgency=medium . * d/rules: override_dh_missing for --fail-missing * d/control: - Bump Standards-Version to 4.4.1 (no changes needed) - Set Rules-Requires-Root to no to declare that libfann does not need (fake)root for building its debs * Let dh_install install from debian/tmp, instead of source Resolves a warning from dh_missing. Thanks, Niels Thykier, for the analysis and resolution! Checksums-Sha1: 81e2eb3a2a9e7d382a5d8f5ea38097ad762bd63a 2268 libmpikmeans_1.5+dfsg-8.dsc 225b34b08c38a0165894184cea7f6847b20c1147 8808 libmpikmeans_1.5+dfsg-8.debian.tar.xz da555225657fd7f1bf375ab9780ff46deb74a341 7046 libmpikmeans_1.5+dfsg-8_source.buildinfo Checksums-Sha256: d0e134e69f397b596bcb49ecad70a93dd204ead5c4581ab291bb2d2028a4e503 2268 libmpikmeans_1.5+dfsg-8.dsc 1c609b8d9050a0817f7928117e5c70112a6d51dfba399bee38da02d685c5bc70 8808 libmpikmeans_1.5+dfsg-8.debian.tar.xz 8cbc06147ab39cc9f7cf60e80bc3c551c4108c8abddd6beb679319ccc0b0e870 7046 libmpikmeans_1.5+dfsg-8_source.buildinfo Files: e4743d445e10350002e932ee7640ab88 2268 libs optional libmpikmeans_1.5+dfsg-8.dsc 7689376fe85fe01dc8d36c847c457b47 8808 libs optional libmpikmeans_1.5+dfsg-8.debian.tar.xz 56c64dd66898ebe0de14cdfe83cd0099 7046 libs optional libmpikmeans_1.5+dfsg-8_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl2kz8wPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrpPgP/00xnkyhU1ZS5XkboWXxawDdZM5rcqyGMmGg uJDjw8qMUxE0dc/d6f4RLMbbGDqG0P/URF2YWuAzdCbdYwVssZdcASmujHW0Sfca rcEu2N3a+4KaAUMPfczSd10yY49jEZ+5ZhqAn8iJL1GnDEOGY58iG0ajc3d9ZLSi uNrw77zslKQbuF4KX0rE8877rEL4ppG++E7prmdAaaDAvkJi85DCrYnvKu6NCEeK cD9mYqlfPvyE/SsFI6AQcFSQ/y/7VOpyFspUbxMfYOmW7BAtvvt+v+B1nU4FD34O kh6xtWGYM/q6WXJ+AsGAGOSkZs6JfeSEVWHaxck6Rkcx16itffhQszDhyqvpBjr0 DoK5idGsUkY1OvOVASU48Np3MTMUI3qapG+qs3S7R4i8m8p6+T3jzO4SJl3QipUU YWok351q+RzLH0/syEyUvai6FRW7SRXftSyaPjXAXOqvCu1wtmTRxCC4bBSyWF1b 0uoYdqOSYoD67eJDeZXd794QqhRgVbjSa3Z3INutM/eD/HKJ3S/NfDClZiByzIua rnt6HiS19mO6IgZ7V+iWcQf0h+fZCl7ob88SbdFLcujxh5Cy0dtT0hMBSNoiGoWW RRJw3WSYJMiXE7Uk/80ZCVEj6HBaipDSzzkLCVgqdUesIaGCQwoCj9qeoZiKKeD/ /9wH/aKn =3hPB -END PGP SIGNATURE-
Accepted libocas 0.97+dfsg-6 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 13 Oct 2019 21:10:13 +0200 Source: libocas Architecture: source Version: 0.97+dfsg-6 Distribution: unstable Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Changes: libocas (0.97+dfsg-6) unstable; urgency=medium . * d/source/lintian-overrides: Fix syntax issue * d/rules: override_dh_missing for --fail-missing * d/control: Bump Standards-Version to 4.4.1 (no changes needed) * Let dh_install install from debian/tmp, instead of source. Resolves a warning from dh_missing. Thanks, Niels Thykier, for the analysis and resolution! * Add Build-Depends-Package to symbols file * Add Fix-spelling-error.patch Checksums-Sha1: c61dfab435ca6efd597c2ce4deeeb592e70d1ead 2026 libocas_0.97+dfsg-6.dsc 30e01aa8a8e8ba7b2638a383b65d1b974ee55afc 8612 libocas_0.97+dfsg-6.debian.tar.xz ff0c5728865542804a20439f12d69b7aafc14b9d 5257 libocas_0.97+dfsg-6_source.buildinfo Checksums-Sha256: 3e06068c10947d0d6f92f1461d426b0eda9970eb142c73ecbe1b0f592ba8f2e8 2026 libocas_0.97+dfsg-6.dsc 09761d4ffeaa57770c448ca4b9efb2b7db5d60a9318213c43dbd6c55544a6016 8612 libocas_0.97+dfsg-6.debian.tar.xz f155a9ae714de5fd896fda010cca0772bcd66e7260ebe76b9e7538a34d1c6748 5257 libocas_0.97+dfsg-6_source.buildinfo Files: d700c0b88d2e161702f5655309834ec7 2026 libs optional libocas_0.97+dfsg-6.dsc 93d9121a34ad37f45a0c14d1446f385e 8612 libs optional libocas_0.97+dfsg-6.debian.tar.xz f4c1333089dd74318e15c92462a16b0b 5257 libs optional libocas_0.97+dfsg-6_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl2jdy8PHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrh/gP/3hNlBj5voSLjpaEPTXl3ogSQEgEApEePax1 O+lvjx48CovVceF2VNIMwudrxI7o75LQwen7XgE//F0Ko/w4i7/7+3iSrNGkkVb2 wJbPhy/aT92J0LHa/DcTS+xDe1r3JlydbAZD7me9wrbd0637eK54qs+SnrpkbzH7 T/kVeeJoTc+ddraGSPIbAT123d4iM0QR29WJcFkAqMNn4CpMtkolxK4n2Rvh7jmt 3ARh2oUHJURFKWqmTbJ0uWiEw1z/ELLYnfuHY7cLdH5bIc0uoZIxy2NGK/hke2Vw R8yXUmgi/CcuP9rV6AbhimV7S6Kn2Jj782IALMkfI+/n7e3bKvNIS+8yK07QwgtE s7KZS42TvOHYCAfq16V6V/KnKdqWSKeTsPWpP+o9jKbi+JLfegZMU5H7tzptrPKJ ZdWGvfECnuGw85GtmmuUBNRGAwae9lA5e95++QkcrjntQf4rTaU9q3HNZkUNvcAb zTOaVyWmabuZvOp3+Th+YE0VcF8gUQ1uXjHnvqb1EXlfbgjv+l5Hdhkvp8OnmUPm zt7JzCIsrKll66eqqUwMMO2DSmPZYofoF3KFzwJUhU0fiWKslEf1wDML+W4zw87c B2ewGFwh9pA9u2P7cp+L4Lt7o5Sr/TB8k1h6R2rs5Zud/A/CTWYu872L8trnYuF6 v/tJg6Gf =mXwh -END PGP SIGNATURE-
Accepted zd1211-firmware 1:1.5-7 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 13 Oct 2019 14:18:36 +0200 Source: zd1211-firmware Binary: firmware-zd1211 Architecture: source all Version: 1:1.5-7 Distribution: sid Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Description: firmware-zd1211 - binary firmware for the zd1211rw wireless driver Changes: zd1211-firmware (1:1.5-7) unstable; urgency=medium . * d/source/lintian-overrides: Fix syntax issue * d/control: Bump Standards-Version to 4.4.1 (no changes needed) * Add binary firmware extraction script. This script takes the byte-encoded C headers and generates binaries from it. This is merely included for validation purposes. The original upstream source hasn't changed in over a decade, and it is highly unlikely that it ever will again in future. Checksums-Sha1: a30225350e598b48147a259b5ec73f11d383f68f 1937 zd1211-firmware_1.5-7.dsc 1b374cf7e7eec2c0787ebc4579d0f8d7f0e4f0dc 4952 zd1211-firmware_1.5-7.debian.tar.xz 052c915e3155259c594d03d483122dd505e2ffc2 14924 firmware-zd1211_1.5-7_all.deb 530e00c6db6c422faf9e7ce94921fe85cc63b35a 5556 zd1211-firmware_1.5-7_amd64.buildinfo Checksums-Sha256: f0ca59644197951d2adca5ec0e4c0b01d0b095c98fffb65dda512b7850d6d3d6 1937 zd1211-firmware_1.5-7.dsc dc449451ee12512ddbb28e99d3ec3df78e4ee4c450e0d40e0c3d763ee7c1 4952 zd1211-firmware_1.5-7.debian.tar.xz fa51f2b943ba51bf533dfa7239c0775d2ad5fdd28e32fddcc6e1214131db381b 14924 firmware-zd1211_1.5-7_all.deb 1134895acbfcbe1229401783a28dbc6680185c5a1d6d0222d7b72afe0cbfc28b 5556 zd1211-firmware_1.5-7_amd64.buildinfo Files: 0ac29287b42dbad764df4d9f850b9586 1937 non-free/kernel optional zd1211-firmware_1.5-7.dsc 25c439c89dd0a10f86f0035bc9f05be9 4952 non-free/kernel optional zd1211-firmware_1.5-7.debian.tar.xz ece14972989cc81bf58a3c8fcd6c282a 14924 non-free/kernel optional firmware-zd1211_1.5-7_all.deb 62181afb6804c8646753b41687e86306 5556 non-free/kernel optional zd1211-firmware_1.5-7_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl2jGasPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNr404QAMHiLxwtXsB+r+MHJ+PmKjpMZTbJhQawHcAO XFgP8D6K6X0VoYF3FK0l5kVypZhyAc1tG1/ttaCwC+kfaY9g8dFbBpbrNI3tMwkn SU6h4Xf7uFh70zlWOuAr77WuPGavef883ojhYCWnnZs9OwiFKl2Q78T2L+eI87HD FG/gzBt2JauqBEEfVjOKrrw0USHxxjdcjR8pz1do0bp9IcC+eFoSRz2OKCW3cRxq A2q8lgps1Talyv/lQa3giorSEWzEKNs88Kzc/ypATmoWV7vuyj2ZBEcqH5fj9qUo h3g0tSl8c2ZJ/rcpx0XfdhMdu4LHggcnfuAtzgDKsClYJj3KoVuxHZA4Sr0tt5u2 iYjLe+thLkiWeV/UJLdfPmiVTWKQVfVd2zADR9MJ/I41S7HKwg5RMx6OekwsCwT0 eBy5JKb69QEnjAD4U4xtwJpBC6rnsHIuEOFx7RRNVEPJV/+IFNHcIrEJfdujaAlS DsozU7oIzcHZuI44oN0BVycY6mTnuw8da05u9Os9yELVXg6i0qrBRSZbQL674rjx 777l7lsZtOUfXrzqb+pR9stogOCyK4IvT0Sy/yA4gR7dT0KGGw/dC98QKKbqk9D1 8YQl9wuYDL98WkRgT6hool6bw+JFQnkZ2rwaknvzGAEU/V+6eC6VP7v5TrFZnKEl /3eb1uOM =ig0u -END PGP SIGNATURE-
Accepted python-fann2 1:1.1.2+ds-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 11 Oct 2019 17:50:26 +0200 Source: python-fann2 Architecture: source Version: 1:1.1.2+ds-2 Distribution: unstable Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Closes: 937746 Changes: python-fann2 (1:1.1.2+ds-2) unstable; urgency=medium . * Drop Python 2 packages python-pyfann and python-fann2. (Closes: #937746) * d/source/lintian-overrides: Fix syntax issue * d/control: Bump Standards-Version to 4.4.1 (no changes needed) Checksums-Sha1: a91cd3424f4b3299f8df7018a0f5b8ae02d5c4c1 2050 python-fann2_1.1.2+ds-2.dsc 484343a7e97f9581b26a940de4d4eff29b879bbf 5100 python-fann2_1.1.2+ds-2.debian.tar.xz 2994cda8ea09f0c384f8ef2252a1c953b243ba49 6197 python-fann2_1.1.2+ds-2_source.buildinfo Checksums-Sha256: b315795d19c7b9fcb95c09dbb1ac83ec8b21feab8104148d613292f05e4df27e 2050 python-fann2_1.1.2+ds-2.dsc 2b6f35fddd13b0f10c60f4a3973222f80c6d031e422f227aff363123e1784eee 5100 python-fann2_1.1.2+ds-2.debian.tar.xz 87c08d01e6e6ce319e70f8474af2e122e090e62e3589a051857f0f9beb808553 6197 python-fann2_1.1.2+ds-2_source.buildinfo Files: 725484d93c6b42b71718f94a2f255ab8 2050 python optional python-fann2_1.1.2+ds-2.dsc 79223b192311090183833783526a571c 5100 python optional python-fann2_1.1.2+ds-2.debian.tar.xz 8784330327834b3df7041202cf6770e4 6197 python optional python-fann2_1.1.2+ds-2_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl2grjAPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNr+iwQAL1fZoipshj224/aTsmJBa1cG4poqv5hEkEq doerzMlQ/L8uTk3Hcmu+CTuI4SmCokeXd1Z0qCWgaDwJknj7nKe4+bso3T1SAcaM yNRKw/Wi2BknMF3XMQPpBzisDGivQfsOp6H82Of32bmlTGy+U5oOUfRMxDmq5SMu M0L3XE46dPNAJHG+NCqDbLk4+24cFniF0U6NCqyObv7m7g1ESHQE3cezbmy+xia+ ks8nYM3M5ZLuYhrGV9hbaA0en4Ts56eN0eQ4/B/OnX1iHe16OUmwUSqh9v2h1Ef7 f0GkSmlPXsMfAvj/x49ECaXkd044QYRsfg6qeVRafaQvWCSdfjusMFqC4f8LZ1mQ L9EMcm/ZbJFliPFFj87k1hRHhfahoOY2tHMF5c9YWNk4n5IDLrmPlYSm7r8kUxZV Az0Gu1V0mTwV7FCIYG4ZhvHFosMzwtHDngOSeQ+/vDGJVtf4f6Qp81vfVPHfp/gf jpMqAHEWrRjZj5+T2sm6Dx37f7zWtsCJ/PnnfaYjQDvrj0azEsD/h1JWDpXoF9Ta QOF8Wo6C49f6VNgrp5612wJA993qw81T51+Kf5SAVP52YTl+z+nzR98dQR4T4llr FGWcvu7MbWAVMqZeFtotoiYfWfNUjVRC/Lr82PkF9yM0+X6smr4P7AdptRiOzi7p /mKD1Du3 =ZbH8 -END PGP SIGNATURE-
Re: Cron, anacron, cronie, systemd-timers
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 the original tarball. So the result is clean. I'm calling it "release candidate" because it did result in dozens of patches (extracted from decades of commits), and I cannot rule out the possibility that I screwed up one or the other. I'd like to give a chance for review. I'm quite confident that they are OK though, as I've been through this process three times now (after dropping the ball twice). On 24.07.19 21:01, Marc Haber wrote: > I have also created a Wiki page in the cron salsa project outlining > what needs to be done. https://salsa.debian.org/debian/cron/wikis/home I updated the page with a more detailed motivation as to why I think the switch to cronie is necessary, and also slightly updated the TODOs. > Would it be possible that you push your changes to cron and cronie to > branches on salsa or fork the projects so that your work becomes > visible? The branch has been pushed, so the work is public now. I plan to merge these branches into master in a month or so, to give time for public review (there have been offers in the past). The next step would be to set up a mailing list (I need to read up on that), and to start pushing our fixes to cronie upstream. Christian
Accepted cron 3.0pl1-135 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 15 Sep 2019 09:13:43 +0200 Source: cron Architecture: source Version: 3.0pl1-135 Distribution: unstable Urgency: medium Maintainer: Javier Fernández-Sanguino Peña Changed-By: Christian Kastner Closes: 924716 926713 934543 Changes: cron (3.0pl1-135) unstable; urgency=medium . [ Laurent Bigonville ] * Stop using obsolete SELinux API (Closes: #924716) . [ Christian Kastner ] * d/control: Bump Standards-Version to 4.4.0 (no changes needed) * cron.8: Add missing reference to .dpkg-old. Thanks, Vincent Lefevre! (Closes: #926713) . [ Jakub Wilk ] * crontab.5: Fix misuse of en-dash in examples, and remove stray character from the LIMITATIONS example. (Closes: #934543) Checksums-Sha1: f489a0e73699df84ca2c78ecec6f33800e3b59f5 1918 cron_3.0pl1-135.dsc aa6dbe904a50220a5b0615bd07be647e0571da6e 101178 cron_3.0pl1-135.diff.gz d03a0be65b15be0d72cca85892f8e2d5ebd2e760 5524 cron_3.0pl1-135_source.buildinfo Checksums-Sha256: bbfae4bd49e17064fe5a08f1a07cc409c35f2b13b370563e489749c149222c9d 1918 cron_3.0pl1-135.dsc 5fad2474e045a6b333ac50603ae55269719bdb9aefd36f330fdfdd6e920e9a32 101178 cron_3.0pl1-135.diff.gz 7cb53fe5e52da09e143a16f4a4fa0d54c1781d034c32a06e24ed58457964ef48 5524 cron_3.0pl1-135_source.buildinfo Files: 62990470821deb7fec11fa444bf3b446 1918 admin important cron_3.0pl1-135.dsc 3cc3b96a30387933c263c1e9900f626f 101178 admin important cron_3.0pl1-135.diff.gz 6bd6eeffd4506601c4761886865af3f0 5524 admin important cron_3.0pl1-135_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl1963UPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrNPsQAKiqvO49XHXITiDg81PcnpGulFpSIBm7l7Bl X9LeFKcGKbtBbcFgoYFeN8kBz/UFlxx5egrTEVmg0J0upaX6FZey1/CpfK8DeHNP pweAMn+DMBJE9kF4aROHMCqepIbQphqcy1dKrvZdaNZ6L7r5ztzM/6GEGjKgXd5W fKmK6Ykerg3+BsE2tKkJLsC+rTWc5jH9gBCbAj7RGtUtW0drIclgLuujc9yGYcY8 zZq2Gak6O9BxppvuAM18C8Setpdhrs7loRe5D+epUuT/fMBvf9C1zG2YCbxkiLGj 5yYR4XpqSMBm6J0AouUZ7b1VerpZLAlRTRXsr6DpF0/lC/ywJDChRbiKE9y67ttv /AaNi5vpaNWYHvdH4u6/ESeLNcB/mDUFgvkG21YkHAMbWe4HczDAEoxZUFOkTVn1 xdfqq8TkVbWdazqNbpHrvFi388bevzlKCYyncfh9/fwZCo0wA+b3oFP3xcgaQmM3 VpTliNVNr7I/kvTDQmpc3F5C1Ihj8nuJ++hR/4Q34Tn6pjSTarwdvs6E1mGnWhZK ffWiVFZ/6Cjut6IMaplDRpLhc/W9EUO+u/2ky+8GojDPURhp8Ij+DmeZEB5or/i4 lJmRZNsgQqNgujMJnlmcDJNDhP3kjSAPP/abjDqJqVQQrL7/SjaIz9hxWG39V98q jjfG3tlS =g6LP -END PGP SIGNATURE-
Re: Cron, anacron, cronie, systemd-timers
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 could find > the time to cross-read it and add omissions and point out factual > errors. Of course. >> Over the past couple of years, I've spent a considerable amount of >> effort in converting the format to source format 3.0 (quilt), but I >> never quite finished and got distracted with other stuff. Nevertheless, >> I completed this conversion in February. I'll push it over the next few >> days (I was just waiting for buster to be released before doing anything >> drastic). > > \o/ > > It is good to know that there is considerable work going on, most of > it being on the source code level, which is unfortunately something I > cannot be helpful because I'm not a sufficiently good C programmer. I > was not even aware that vixie cron and cronie share a common code base > that makes such a migration feasible. There's a lot of non-C stuff that needs to be done, too, in case you're interested in that? For example, I'm almost certain by now that the system crontab file and dirs (/etc/crontab, /etc/cron.*) need to be moved out into a separate config package so that alternative cron implementations can use them. Currently, each implementation ships its own crontabs, and switching between them (eg: switching from cron to bcron) is a pain. >> My current plan it to move from vixie cron 3.0pl1-134 directly to a >> (patched) cronie as soon as possible, so that the default daemon can be >> switched to cronie in time the next release. > > Great! That is good to know. Are you using a mailing list for this > effort that I can subscribe to and see where I can be helpful? Or is > this mainly a one-man show anyway? There used to be one until the move to salsa, and I'm ashamed to say I forgot to opt-in to the migration. I'll set one up for cronie and then report back to this list. Regards, Christian
Re: Cron, anacron, cronie, systemd-timers
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 old package in experimental on > the Debian side. [...] > Without having a closer look at cronie (it basically works noiselessly > on CentOS systems with me not noticing for months that it's not vixie > cron), my gut feeling says that moving over to systemd timers completly > might not be a good solution, but using cronie in the future might be > helpful. Christian, the cronie maintainer, also being an uploader for > vixie cron, will probably help to make necessary adaptions for a > seamless migration. > > What is the issue that keeps cronie out of unstable? If it just a matter > of personpower, or are there technical reasons? If it's just a matter of > personpower, I'd like to help. It's mainly been personpower; however, that is improving. Any additional help is welcome, of course. cronie was uploaded to experimental ages ago, but it's been rotting there ever since. My goal for it was to patch is so that it is as compatible with our vixie cron (which has quite a few extensions!), to make a transition from cron to cronie as the main cron daemon as painless as possible. This goal was unattainable with the current vixie cron -134, which is still source format 1.0, because it's really hard to carry over features properly from a single huge diff. Over the past couple of years, I've spent a considerable amount of effort in converting the format to source format 3.0 (quilt), but I never quite finished and got distracted with other stuff. Nevertheless, I completed this conversion in February. I'll push it over the next few days (I was just waiting for buster to be released before doing anything drastic). My current plan it to move from vixie cron 3.0pl1-134 directly to a (patched) cronie as soon as possible, so that the default daemon can be switched to cronie in time the next release. I've abandoned the plan of "upgrading" from 3.0pl1-134 to 4.1-1 before switching to cronie (which is based on 4.1): it's just too much work, and I've come to realized that this would just be a waited effort. Regards, Christian
Accepted cron 3.0pl1-134 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 23 Jun 2019 19:49:01 +0200 Source: cron Architecture: source Version: 3.0pl1-134 Distribution: unstable Urgency: medium Maintainer: Javier Fernández-Sanguino Peña Changed-By: Christian Kastner Closes: 925276 Changes: cron (3.0pl1-134) unstable; urgency=medium . * Increase maximum crontab length to 10,000 lines. The previous limit proved to be too low for users with edge cases. (Closes: #925276) * Add NEWS entry for crontab line limit increase. Checksums-Sha1: 9967c02540a1e5e5c392123901f478a1b8f40b96 1918 cron_3.0pl1-134.dsc 9e133212eda6ba927d37dfb896499f2728333dba 100895 cron_3.0pl1-134.diff.gz 68651a0edcb0bff92f63c92477f5e111713d8c21 5268 cron_3.0pl1-134_source.buildinfo Checksums-Sha256: 3e50c354c6bb60dd28c3b8589b1e04c6308f2487646cd8b76f25ee180f301a3f 1918 cron_3.0pl1-134.dsc 574fc3e730e7b6aca09e759855845f34c77b5dffc5db3e8ae55682ddf3296a18 100895 cron_3.0pl1-134.diff.gz c6903f27977b5ae4b1f8e9cadccdcf5b6be0dd7e0710c55c922c3faf2bb6fb15 5268 cron_3.0pl1-134_source.buildinfo Files: 71d28ce699257fe6a542df132169ac0f 1918 admin important cron_3.0pl1-134.dsc 5f94ffd6ea8dbf70a7623c79aa14cff6 100895 admin important cron_3.0pl1-134.diff.gz 5879bcd8a8ae51225b20e9bb1340c55e 5268 admin important cron_3.0pl1-134_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAl0PvLsPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNr+hAP/ApSqqMoIKgEoHSyBDNSShTnwRdSssoKuBda PClheuQ2cO0sLJUCBC1UsrTP5ZQPQ1DVCGOXhRS8uuMlCBVVvIKxB4HPGYOz29hZ 0CkRFwrxsLSU2VmPmlEbh8bHqj7TlIjxTGnRhZUc9OkStolFImdm9EKRHw3JOT4H p05SI1mpzcka4zYmLscvocIubbBzGG/zn1iwYh6wN0RqShoHGidMh2W8haxj534D CE2cADqN8fT7FWPaJVYxmC9oCA1+0NrvG6AleB2gxNEOHvaFSlt1Ihp3kDyrPSUD r5wTYvOGiy1dmFqMfAMpVEXi5a8yjkwbqPGBztTT79NfwOkozxFvoJnbReuV7S6O caELi5AmJQD+/aRYrdPTtQ/WQyz/oWJTGIu+NqGzrtyDPsPAiTlfcwimYJmlPXFU 7cLN6t7eBze94u8nxGPGtDqLwh1WOFHZ3cz3VHh1Msclqak1qXeWtPm+w0VRlnkM vcvji1Phsq6tsyEMZ2vyXSmk7mq6DXRHfrMBzm+q3aWOFnrYfS0pfpOOCGhoNafk 33LloKz1iX168LoW+MPKLHD3unJd7G3eeo0XMIarGSW/743n/NvU6yWagMk63KsP APt1/fLqlWovL+w+6AnruPAlbq6EM77gfbgGw8ILdo5nyrw+8c3HjdYdYUkZOngU eieT8fQm =7ybd -END PGP SIGNATURE-
Accepted cron 3.0pl1-133 (source) into unstable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 10 Mar 2019 17:49:18 +0100
Source: cron
Architecture: source
Version: 3.0pl1-133
Distribution: unstable
Urgency: medium
Maintainer: Javier Fernández-Sanguino Peña
Changed-By: Christian Kastner
Closes: 801328 809167 893575 893579
Changes:
cron (3.0pl1-133) unstable; urgency=medium
.
* SECURITY: Fix bypass of /etc/cron.{allow,deny} on failure to open
If these files exist, then they must be readable by the user executing
crontab(1). Users will now be denied by default if they aren't.
(LP: #1813833)
* SECURITY: Fix for possible DoS by use-after-free
A user reported a use-after-free condition in the cron daemon, leading to a
possible Denial-of-Service scenario by crashing the daemon.
(Closes: #809167)
* SECURITY: DoS: Fix unchecked return of calloc()
Florian Weimer discovered that a missing check for the return value of
calloc() could crash the daemon, which could be triggered by a very
large crontab created by a user.
* Enforce maximum crontab line count of 1000 to prevent a malicious user
from creating an excessivly large crontab. The daemon will log a warning
for existing files, and crontab(1) will refuse to create new ones.
* Add d/NEWS altering to the new 1000 lines limit.
* Move /var/run/crond.reboot to /run/crond.reboot.
* crontab.5: Reverse the info on tilde expansion. When setting PATH, most
shells will not expand a tilde. Thanks, Tim Landscheidt, for the analysis.
(Closes: #801328)
* Fixes for numerous man page issues. Remove trailing whitespace, use proper
escapes, etc. Thanks, Bjarni Ingi Gislason! (Closes: #893575, #893579)
* crontab.1: Drop duplicate DIAGNOSTICS header.
* daemon: Only support the 'x' debug option in debug builds.
Checksums-Sha1:
ce0b9188ce385fdf5659da9a464c62ce6ce4a139 1918 cron_3.0pl1-133.dsc
8fa1c0e52853a2b538bac04a1ccbf49d5679eb49 100791 cron_3.0pl1-133.diff.gz
d461692639bfbd73ef67c4f2e40edf2a61ee6862 5264 cron_3.0pl1-133_source.buildinfo
Checksums-Sha256:
d8a4fb0343d028e24d90079c82427439b65e2ed4ae90fca572e10d9984ed5934 1918
cron_3.0pl1-133.dsc
dd542caabd039da1b3f1bbe8da271c20995e3c32caea26c058ac1d4236896506 100791
cron_3.0pl1-133.diff.gz
761f490f47d059910df1d3c192f264433047ce8c3ac61e38da68ed3ce48dc3e0 5264
cron_3.0pl1-133_source.buildinfo
Files:
6e4f310dad6071990f3339c82d313b24 1918 admin important cron_3.0pl1-133.dsc
d6542f4bdf4b3b3d7601384af994f720 100791 admin important cron_3.0pl1-133.diff.gz
df833dc4a0568c4c3390b062373b79ef 5264 admin important
cron_3.0pl1-133_source.buildinfo
-BEGIN PGP SIGNATURE-
iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAlyFRCAPHGNra0BkZWJp
YW4ub3JnAAoJEDmVOjfeTrNrxLcP/3H/ATbpLbXB49yPOZE9glbdSk2ngHWYh+ic
n2pEdmEq0yUA0g6DSwsOSWfSClPMabrU3+YiFRwk8L9uKBK5MD3HDEui3FFYcpEP
CuPSvY7b3ytWOUVjYlGWPkRidox+RA5qd43iDewHRyY3P6lIUB3l4MHiUurI1jBY
MQ/myllbNyMHTpXgJyr83rbJWz9GiUm+3nCoux0N2tfvpnYUvNd7ViNJeb+EBV2g
YAB0NiPel5/92KLkGI/rrSmtat+s2IJ3B80qn5lgM+BKqd3/Fk/wt3BUZQBZvrGE
Qf+Yvf4wMPdCMrdWjJF05SsXeI9aEr4Sa6gHlrjnZwK7JvwkGkoOShzVkqLqTj5l
qIK8J+NnDiXOfeNqpyadrLbxE9tV41xkPGNTcOSzfr8lBr/AvabK39UIkUIFiLiW
Ud6By3RJ8sgWgwtFS7WGaV+5KM9lWvvhilVUjZb4hSb+WPG/2UIntc83ZiPGQVvn
gQC35ZUMwMjVmLDe8n/3bPd5fjFL+m5Yl8W3hhUZa2MrHvf4None+f8cSj2sjJs2
qGiDEWqzH2Gb+QuYsZka8HflKKAg+BzG4qPOG09VqNNJx0btPWi1k6EyWKMAOmpY
lWcX+/BzaOeVjICcqw6bQ0hGr4C0INMs4ucynJOilPaqt+8eO185l+4cnYqUsTr6
11YWkMCF
=itJI
-END PGP SIGNATURE-
Re: Please drop anacron from task-desktop
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 cronie than maintaining our old fork. > > One question worth asking is which distributions plan to maintain cron > moving forward--will some of the systemd-focused ones start dropping it > in favor of timers? (No point in migrating to fedora's cronie, for > example, if they stop using it in a year or two.) Indeed. I wouldn't be surprised if that happened for bullseye+1, I'm almost counting on it. OpenBSD and FreeBSD maintain their own forks, so we can probably count them out WRT a systemd replacement. I've looked at the cronie codebase and Fedora has put in a really considerable amount effort, as RedHat needs something robust enough for the enterprise market, I guess. IMO, that shows long-term commitment. Christian
Re: Please drop anacron from task-desktop
(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 seems like a reasonable feature to add. True, although each distribution seems to maintain their own fork, and each of those forks has grown quite organically over the past 25 years. > The other feature is randomizing a field's value, to avoid load spikes > across a bunch of machines. That's the reason for the vast majority of > wanting to use a .timer over a cronjob. This is a feature supported by Fedora's fork, cronie. cronie also supports a number of other features currently requested in our BTS. Incidentally, for bullseye, I will be proposing to switch the default cron implementation from our own Vixie cron fork to cronie. This proposal follows my completion this week of converting our cron's source, which itself has also grown organically, to source format 3.0 (quilt), resulting in almost 70 patches [reviewers welcome; I'd love to have independent eyes look over this before I upload it]. Carrying these forward just isn't worth the effort. We're missing out on features provided by other forks, and I'd rather focus on getting our Debian features upstreamed in eg. cronie than "upgrading" these 70 patches to ISC cron 4.1, and then pulling in whatever fixes other distros did. I uploaded cronie to experimental ages ago, but let it rot there -- that was really bad of me. I will be uploading an updated version (based on Andreas Henriksson's work, see Salsa) as soon as I can, but before I upload to unstable, I need to make sure that cron and cronie are swappable without issue. At the least, I believe /etc/crontab and /etc/cron.d should be moved to their own source package. 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 cronie than maintaining our old fork. Christian
Accepted keyutils 1.6-6 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 06 Mar 2019 17:18:19 +0100 Source: keyutils Architecture: source Version: 1.6-6 Distribution: unstable Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Closes: 923156 Changes: keyutils (1.6-6) unstable; urgency=medium . * d/tests: - Use set -e only for test setup - upstream-runtime-tests + Skip tests requiring root They don't work with some container solutions due to their close interaction with the kernel. These tests are moved to upstream-runtime-test-isolation. (Closes: #923156) + Drop needs-root restriction - upstream-runtime-tests-isolation + Drop redundant tests Clean out tests not requiring machine-isolation, as these are performed by the test upstream-runtime-tests. Checksums-Sha1: 745b580f4c59cccdf7fc9501d06c0cc976d891f4 2062 keyutils_1.6-6.dsc 4ccce4669decd850d49ef2528dd7f5c02eb5d7ee 12828 keyutils_1.6-6.debian.tar.xz d5c01962048e4cee99aea77b266c71653011efb0 5460 keyutils_1.6-6_source.buildinfo Checksums-Sha256: 1da6a0f50759b4eefe210e351558a854e28d312213d5528792af6938f106f183 2062 keyutils_1.6-6.dsc 063876d377aad5e632b013bb8fd85bef85b2285ba7d6c8ab5ac7492ca245 12828 keyutils_1.6-6.debian.tar.xz 630bcb3deca65351d370b698d273ca602dc5d08952183ad58da75c2dff6b38f8 5460 keyutils_1.6-6_source.buildinfo Files: 8cb7a43eed2eac722a4dba8fa017eaf4 2062 admin optional keyutils_1.6-6.dsc 3976fedc48391621fed308e81836a59c 12828 admin optional keyutils_1.6-6.debian.tar.xz db5adf1004a179e71f1d38fcfb150834 5460 admin optional keyutils_1.6-6_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAlx/+voPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrLSYP/08mUMzwQQv4kj1l81CCeb9TZITgzgxWbePM cHd3oQxdUF7eta7J+azHcLdqONHTwaNW2TasCFdrJSTKnnX/bGleOwgYCbq4Po6a LdKNzv+amJoSHlXJuT9iimlBfHk31C8jx4VBeAYR73RrQM5DrvEeCsRWYGP60MXK vzbhYy1kEkdCzIIKdWKYRLMfQYFWyxtG9LwnaR1QRv3Q59zDHx7WHo8qYYP/IbZ9 BayDyagzLcguUZ5au93GEHxfcbLmdEj4QmtFAB8PRQTjlDGg6FEvSzh5W1LSjllU aub6JKAHULfYPsdIkSYLPL5vAogoYw1tvl21iNlzrzhs5Gzwy/837JuWy39mcxs7 z6MvrCEttFvjgiHychbn0qNQN7KbmnK4LLA9ae5T/S1Vfw/Ixix4GKDdRzcBrqf1 WS/8WwcZT6VgeGr8u1OWd440y/g1NLO3QS3H98c5v1ZWH1enLdpdRGXmR0w1ey+h saYxBfZW8dXZsYRc8QIVguXNkcNV98rPXsyxvh4/V4ObfPm3+r4hX+OvM7tUbeN6 Cn6wFokS3TaY4ZSXjPq/E+UdXLnD4rWI5qM+86OM2Fna4b4l1PrIIu7h3RLPnNQT yd9a+yuRmTvSJLnMAVoksX9CZ7G+y3ks5bH1E0yneXkEl79E//cFLII1AWTUnhQq mhP51ZI1 =euCo -END PGP SIGNATURE-
Accepted keyutils 1.6-5 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 01 Mar 2019 15:47:59 +0100 Source: keyutils Architecture: source Version: 1.6-5 Distribution: unstable Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Changes: keyutils (1.6-5) unstable; urgency=medium . * d/tests: - Save all output to $AUTOPKGTEST_ARTIFACTS * d/tests: - Run individual tests in AUTOPKGTEST_TMP subdirs, just in case Checksums-Sha1: 3dc952252d54140985a021f317187e659de3b4df 2062 keyutils_1.6-5.dsc 323173b32e3e1083418a3527c91996f52a900dc7 12452 keyutils_1.6-5.debian.tar.xz 7d60c0ae9fdf213035d604eec4e4119376d80c0b 5478 keyutils_1.6-5_source.buildinfo Checksums-Sha256: 558ad163d017d1571b81514594dfc48202316e70a563288df732d55543c36908 2062 keyutils_1.6-5.dsc 014a2f188079a66bab5e8f9941485315f850b26cff2e4429c98a0dbba5da21d3 12452 keyutils_1.6-5.debian.tar.xz 00c0828b994d0eb4befff9b5afaf982668b70ccf126f8ef7300061902aefdfea 5478 keyutils_1.6-5_source.buildinfo Files: e3978f46388248ecc44d7cd9580ce897 2062 admin optional keyutils_1.6-5.dsc 8a24468235eeaa27f8f14b8cc500adca 12452 admin optional keyutils_1.6-5.debian.tar.xz 6a18d798b2aa10be42c1120f117926d5 5478 admin optional keyutils_1.6-5_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAlx5RoAPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrf00P/Av3wGfwyTbYEX8aR04Ccn0VYp2YUSzog4Nh ONGTFDlSR1nZs7m9kXPOUAvm1zTEAZC/JH1GngyemnOdsaGpubjCgs/tvMCO9Y6X M0e7wxYYRmhOqLrABmTXl+bUBOx6vXhGXP/34hMpKQRW/25DHysFbWWzIlI04ME9 46P4Hp70J+CEhjh5CXQ+BU76gDa6C7KIOEjj2LoGU/U9elYsOwV6ZJcd8kLP9DpA qNeDbw+YGf6m/tuDks2uzhY2/Gl2kqYqwkriFHJaT+w8sk3PPSmc6BE7scPgk83A WGawQvZx9SPGNdFaATNnnqA9ikul+awlM2JNOKNbhJgINmzdW2TvVb4EVmakaKil y4kW+3JQ5Q09ktvWF4yG7OTI9VnbCkYJYybAG6SKGv5nrp+FS6HpuVhYi67+Xr5+ cOfIF+pFbHiqdHh8g3Z4iNJ5Kd/cEMGXiEbjmeQzxYd3gKxXTvoU338CcqohJX52 iwlAsr+N4QdOPMqIzyXNSaWwaFY3f42OIaoAwRe5lRJOJbigVajSLWDCLeICFcV+ 5eKXYJ6PvbX/rgEimf8SIOgm+yuDPShmJQvOL59a/0KQLi6OtnAYAJKoatn9ih6I cuN11d2BakN9wqaH5ZY0pmVfHsO7JAuKVzj4jCzgaQIw/B9zHjWFeQeITGpzCFXv DcsXS5Eb =9WnK -END PGP SIGNATURE-
Accepted libcgroup 0.41-10 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 25 Feb 2019 20:04:27 +0100 Source: libcgroup Architecture: source Version: 0.41-10 Distribution: unstable Urgency: medium Maintainer: Debian QA Group Changed-By: Christian Kastner Changes: libcgroup (0.41-10) unstable; urgency=medium . * Orphan package. Set Maintainer to Debian QA Group. Checksums-Sha1: 79a3fba49fef557483200fc11ed144f1094cf0cf 2087 libcgroup_0.41-10.dsc 7c4534a9763f4806af101118a8d4f098223640db 17456 libcgroup_0.41-10.debian.tar.xz 4ca58921274e00ee442a2bcf97391e5241599e7d 5166 libcgroup_0.41-10_source.buildinfo Checksums-Sha256: b4ac6fd23ca0848dc9b072bfbaf34eb2ce20bb46f22463963ad6139549b55635 2087 libcgroup_0.41-10.dsc d167ec6a9c55eb0bceddcaf4a5765cc5341450038bf055e79f00df3607b168af 17456 libcgroup_0.41-10.debian.tar.xz 3717e7f1dc8ad17d61288598729aabc596bad20c4a4c71b4f5421dd920fa5727 5166 libcgroup_0.41-10_source.buildinfo Files: 349828406de42beecbdde39f4757dd72 2087 libs optional libcgroup_0.41-10.dsc 1c1c95cff500b501825a6b1e837c282c 17456 libs optional libcgroup_0.41-10.debian.tar.xz bb21777af43f75eed19957a937459a18 5166 libs optional libcgroup_0.41-10_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAlx0PI8PHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrX+UP/RLyLxEIw+c/EG3Z+Z7KwEXrpmZ99mUgMuEE mGFDWkTAzlGQnQCYzfCGrd6s5sRwiE56Fk9aU3/482UD7eTNMavh7CerVOz4ejfa 6eC+11mAdG0Wk05XF6BaZWXPUhf56nZHm4mYDnDHAQlG5Is4hN+rzT/HUJj9z3uE 4jgD3jRDZcEHPjLJS0nve6T/vjCTgaNWbIbYqkn7LAGRncWVNJ0cXZWfrDhCIKX0 fb8E3asLdn97Wim3gt96Yyg4748Io4vX/D/FT+MmkS9Tiatnc3sbfEbY14oXDiLC WHPSzLTa7vLrTuSjRnxlwBxoxu3R1VaD8M5cAqAgWMcc8XvHDl8MS1HY+b9wElS8 2VFhKMKdIh3b1QUGEEUv0LTX893p8yq9ogAxBcs7MGn4fxNFpmWAEMr/RCiNwxM6 vk1UsRkj7tuHucBPPPLtdU0PGFy9ovebkfY/7hBk/DJtKQO/k2qc0OrE0TrotvFd reoLDa0n0Y8/xHzDtKHBcUa16B/XKrhkafm4Opgn/OnFX+Xj5fQ5iZgmF/XsHs9x W65TFEyKzIAvc3Rzwq8vktEdLf93yE4rB7QC22MQG24PiBE4lzMhIz5U/83bLWNs 0JWp4S1k0b1JIXEN2YPKBPaUucoglp3DfKnx/lAENsNMbrgfR4V6hLsAn291+PAg 0YdiZ2vq =9wLT -END PGP SIGNATURE-
Accepted cron 3.0pl1-132 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 24 Feb 2019 21:56:40 +0100 Source: cron Architecture: source Version: 3.0pl1-132 Distribution: unstable Urgency: medium Maintainer: Javier Fernández-Sanguino Peña Changed-By: Christian Kastner Closes: 878363 898119 Changes: cron (3.0pl1-132) unstable; urgency=medium . [ Christian Kastner ] * postinst: Properly test for regular file cron.postinst checked for a regular file by parsing the stat output, instead of simply relying on test(1) * Mark package cron as Multi-Arch: foreign (Closes: #878363) . [ Stéphane Blondon ] * Add forgotten '\n' to a line in the crontab header (Closes: #898119) Checksums-Sha1: a2b05b1d8026233d847a3123d922d3d1e815e8e8 1918 cron_3.0pl1-132.dsc 9470e5d4a01df8d29c8508e62b3fe71b3974df79 100678 cron_3.0pl1-132.diff.gz f1a96a29af41eca5e901f5659f9ebae696ff22b7 5280 cron_3.0pl1-132_source.buildinfo Checksums-Sha256: 3e3bc71cfdb575d8502c3e1d5f04eeaf0ab9800386900d17390749ab1b7f5648 1918 cron_3.0pl1-132.dsc ee28319c2d9928f71784649082394c0b322f3f4936830aa7603fca8d5415e85f 100678 cron_3.0pl1-132.diff.gz f6a403ef4331c717f573d2596f9e9acb22ca7ea4da78dc7f290e546b4cb86ad9 5280 cron_3.0pl1-132_source.buildinfo Files: 13a1c2d9cc6fabc4e948bdbb1a18bf9c 1918 admin important cron_3.0pl1-132.dsc 4fc305bf314a3d5c95b86478cb7ce174 100678 admin important cron_3.0pl1-132.diff.gz 4c2cf8dcc5d8474c9525df1549e11f78 5280 admin important cron_3.0pl1-132_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAlxzBY0PHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrPgkQALdKse060fozk6OiJPpeTBS3gnpscifmHWeX f1vmgKGkGWVmPbaH2Hfh9Kl8Whj/RkhQW1gUHH/v8ijnXeft2y90YrlEOTgBwhp6 NnYiul7KmZzbDDlWJ1KG6l0o1uQWYgAzqVR/CfjdNSczi7r1KeO83bNuvapbWM0d LQbryOEqpH7YFn4A1wA5eZTx0mp01M0hRSmS5mlz3gIbZTJyuoQC5L/raDyI+j0f N8NzD5KE/xD4+JLvZB4LIrXNqGPAXULH7gKmLy7pdoMJCiOC8TCwk2ECy+Fd1ubE qtPkuKbn4wHm24cbNOU8I1qosyfkODjqPreyRA7eTvYZuzhoGDl53qsA+jSc/Nr3 0FUQLKyB5l+RIKOi/R+e4FPOaFNZK3kLZuZnrfTf677HJOCbV2cxSvG02zja1kvS dt7aG5ZYKIGW910u83sUfoyAPY2ei/ki+qbSDBT/8F8BMuOhELNgit4GE9uBNvGz ZphtQgPl3+v0PzZlP6KM+nbehyZ1OKGzQ+r/A9cKkj2ki4JCC2A58cHRXZqI84AR NZ2JGNPdclcM6LQKIK17oFD1ifi5LO7dL2qWRvdY0rGw6LMHEuvXDzbEbRuLKEmi IU4RXqedMYvmj1PcCJgW+NqstDCHzhuCJgZ3dJH0i34aQd/Fe3IFAu9HseEKoFw7 827uP//9 =e86E -END PGP SIGNATURE-
Accepted keyutils 1.6-4 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 22 Feb 2019 16:49:41 +0100 Source: keyutils Architecture: source Version: 1.6-4 Distribution: unstable Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Changes: keyutils (1.6-4) unstable; urgency=medium . * d/tests: upstream-runtime-tests: Fix broken option value SKIPINSTALLREQ expects "yes", not "1". This led to debci tests failing. * d/changelog: Fix line too long in 1.6.0-3 Checksums-Sha1: 1a6d320091a162fab76b6ca6b9fa01b65a851df7 2062 keyutils_1.6-4.dsc 827e5a46a07e00810adbf12af881aadc3e0dda19 12348 keyutils_1.6-4.debian.tar.xz 48c838bef735971d3f756b909b77d8c1f582c95a 5433 keyutils_1.6-4_source.buildinfo Checksums-Sha256: 1e2ef2cb761c7f2ef087fd65abe07df9f9cd54d8b82f95f20f8c48535965198f 2062 keyutils_1.6-4.dsc 81829e84894fb98ac07cd5cfcac91a93d736aedf36cecd13af0f95636f9435c0 12348 keyutils_1.6-4.debian.tar.xz 530e61f8194cda07e37a8fa96b419571c1e1de5deabf0d5783f411dcce2e196f 5433 keyutils_1.6-4_source.buildinfo Files: d6159c951562c456cf8a620aa52ec95b 2062 admin optional keyutils_1.6-4.dsc 043f45c58d91b44395da57396c176c65 12348 admin optional keyutils_1.6-4.debian.tar.xz aed1cd3258d0680122d40ba4575c293e 5433 admin optional keyutils_1.6-4_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAlxwGxMPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrPBwP/iLA3gA4HGVjj9LDg5GzH6WIX8XBb3e6wpwZ nFIr7wbiBUgvUjvKzGHHxwA7zIwYQE+O7dunkTpGwCQrjzUoIZojDaiDDTGDASUw AiPJz9QDDYITesQR/3mXQscJbVKf9ANP8SxTLTjP8z8k0gztNOpSAIsh63qnq/kc 5BpaB07Gl7kKSwADvtUUCFQ32yWnE3HOck7pgoChphczCNVmJHA7eIWkLuBgd59e iFNST5IfwXoqQfQh5V/Vl2bcn3GG18tbyFbrTPloXYY9g7ltPRYYc/+HsUEbElco EKN6lNRU5gGIexsCrGZ+hBoJLNoa4FYj1PTumg1Ksf9L1U6qf1PJORAk+EH0Sfcf HYZYOBaPxvsL01YtTA66C5tOUwoqsybhdV4EIAuYpZPh4IsSCFVxxTLq1aPpu1wo TsEZ3Q4h8AdzT8pbcHiLhGkTGiyuVyXkublkQBCDiSvZ2mPn6Ao7DrsPqLAdSy8/ GMqBSnY62Ksb6wybkWRdUOauQ0b+I19dJIzAjUsdl0AfxvIQlTwXs63xBfRXwA97 HWDzMax4kZFiTtop7BXND5KnMyDH0vvSKqOs2JMJXq+2+UgqNopqdMs09pbAH0rI nexCTB+PMz4aNgfWiukjPYwnBBBQiAwCrEqPNFWmQ6fhsnihNPy6QhfOWoVgHYuR r093l5Yc =bhIU -END PGP SIGNATURE-
Accepted keyutils 1.6-3 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 21 Feb 2019 20:49:14 +0100 Source: keyutils Architecture: source Version: 1.6-3 Distribution: unstable Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Changes: keyutils (1.6-3) unstable; urgency=medium . * d/patches: - Add Debian-specific-kernel-feature-tests.patch Fold various Debian kernel feature test patches into one, dropping all the other patches - Drop Disable-some-tests.patch The test is guarded by a kernel feature test for CONFIG_BIG_KEYS, which we disable in another patch anyway * d/tests: Split tests in two: isolation-machine required, or not * d/control: Add Rules-Requires-Root: no We don't need (fake)root to build the packages * d/rules: Re-enable tests on MIPS Bug #881830 blocking this has been fixed in stable in 2017, and the fix should have propagated to the buildds by now Checksums-Sha1: 4eaad366a8745de8c481a08ec4b1d1dba580a70b 2062 keyutils_1.6-3.dsc a55ce155d0725c6b0ea054befc30a8466c2041e8 12256 keyutils_1.6-3.debian.tar.xz d5f1f25e364f9962d7d627e273276a478e0543ea 5433 keyutils_1.6-3_source.buildinfo Checksums-Sha256: a51041dba072af27e7ff5775d7dd21842857ceab8674b27958e4ece5be8e546a 2062 keyutils_1.6-3.dsc d2a872558943dbb31376ac788544eb9e8e3e3b98010192afe134137fc4bb38cf 12256 keyutils_1.6-3.debian.tar.xz 7512d8e21c9fb6ddf1d032238269df9e262b1ce7c2f9f1321a1db4edd28cf096 5433 keyutils_1.6-3_source.buildinfo Files: 20d57b1ee7395154358d6730f8fd2d61 2062 admin optional keyutils_1.6-3.dsc 16b4a3e78419e5590884db32b5635967 12256 admin optional keyutils_1.6-3.debian.tar.xz 52cc150bddbcdc0dc851dc6f7ec92230 5433 admin optional keyutils_1.6-3_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAlxvAk0PHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrQd8QAIepLVWW7nqv3UIcyHox9yfbmEafkoTL6eBC k/avzJ2M6rqEj/DWzgVlgOSNx9VSbc6Int9J/mQw0oHShAg5VX2TIug4GwugM6pM AzaYN4UsN/39jp173VLIDMxK5emRLc/EyQfIQnkBTm6aEE62DP8KOX7VzYnSsTeC Tho57BcM+nDnNSNB3j+HTiLjz2WBEcjdUzJlj30LIYAnQN+sqp3HnDOC3OrM/nTB J+4wqCDks5cQOhMSpg93ETjFmLaKavwjBcbpDTcbPYfzS383DWPYbbl/sX6AoX8f SnbYusbdhM59P0+3BYzbFhaNMJV2PLJISEgPt/x2iYMFnjH964BQW+rZo3+lbc8n eg4EOsdMvUgQJRUYuuoO58bS5P19Dw61HHBp0zYXh0MA/BO3gSBB5Gph5Cwl5o5b 2Cyp635FoPHI7dgJkfMKV5M+m66Jg3f6t778GOMvdS7OI9hknM9xQw37+u+UlupX rftqIZuj87FOIbg6mqZCIZHaH4lOnGvkJZWWeVoF6KmYF/ulufm5iWFmiywr73gG fIFvJyE07xezlxve29gL/Lt9N65oh2l6OM4hggDBXy5RXJMgmy2BksJTCqCSQvZI lcAJuEIknuM66lCkkwc1cNt46l8i5WmdSA0Cf9Rk5GuzTkEyt+7pJgVmVoBfqQ4W /dx1watO =PJD8 -END PGP SIGNATURE-
Accepted libcgroup 0.41-9 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 21 Feb 2019 21:34:30 +0100 Source: libcgroup Architecture: source Version: 0.41-9 Distribution: unstable Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Closes: 886744 Changes: libcgroup (0.41-9) unstable; urgency=medium . * Acknowledge NMU. Thanks, Markus Koschany! . * d/watch: - Update to format version 4 - Switch to https * d/control: - Point Vcs-* fields to Salsa - Switch Build-Depends from debhelper to debhelper-compat - Bump debhelper compatibility level to 12 - Add Rules-Requires-Root: no We don't need (fake)root to build the packages - Drop transitional package cgroup-bin - Drop Build-Depends on dh-autoreconf debhelper enables the sequence by default since compatibility level 10. - Bump Standards-Version to 4.3.0 * Remove now obsolete d/compat * d/copyright: - Switch to https in Format field - Fix broken Source URL (libcg, not fuse) * gbp.conf: Set pristine-tar and sign-tags options * d/rules: - Drop override_dh_strip It was only needed for the dbgsym migration - Switch from dh_install to dh_missing for --fail-missing - Drop --parallel and --with=autoreconf They are enabled by default in compatibility level 10. * Add patch cgrulesengd-_GNU_SOURCE.patch. Fixes a FTBFS on ia64. Thanks, James Clarke! Closes: #886744 Checksums-Sha1: ed0d56b6765f5eefefcf0816b358db97dbd6714a 2077 libcgroup_0.41-9.dsc 199fca8de059162b8b3277a802dc3616969f7cac 17412 libcgroup_0.41-9.debian.tar.xz 551b3537544089a915cd7b32a0f34f590da2d252 5117 libcgroup_0.41-9_source.buildinfo Checksums-Sha256: 503a217c06f569ca50ad501744851eaf4631793232f267f4410ce1221ccb5ba4 2077 libcgroup_0.41-9.dsc 31c9ec7b27deb5c0042e1be093f3b80350966ac6c163498cd0173966f2ddc957 17412 libcgroup_0.41-9.debian.tar.xz a1b008e32c84959c87870773e7a880683d454ab41f6e6f5ccd3ede660fb38a85 5117 libcgroup_0.41-9_source.buildinfo Files: e27fce58ff49edbe5d166be8e9ddff6c 2077 libs optional libcgroup_0.41-9.dsc e1b4acb6dbbc85ccfa3e9ee318c87d04 17412 libs optional libcgroup_0.41-9.debian.tar.xz 27597622f5b7d40e02bc097df6786e52 5117 libs optional libcgroup_0.41-9_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAlxvDMMPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNr26YQAIVQ8wW/2hycQOJjvGvD2dZwLgjJQGtLbSzE pcENtd0y6rj8hctSDFfn1rXj2A2jUYzRwbHCI+jsPN1iEd4Ey2bftak4vKdd8b7T w+GCYuncw93lLXwXoxoeoGQcf2XHGDGHwYVNiYsPy3Qfsib7jP6jSyAZcT008dY4 ILOlDkdmEfeXqWAWL+Rs0TkzoauEGWDz+QXB0bMjRNl39MRgnk5x56M1ZTvchFWg cYKDfmGjNc+QR9kMm7fUJ/aRFX7FDoo6IoaFcn409rGL34WhcO5vxI4wFWZWZpWN e5Ua5TzBxpDEkhThY/4cYW6P/ZRHfg0fwTqtmvafuu74XRN7TUtTjmxEhjpwyyer AKlAkbrilpPTFnI+1bKddyejvno5vjMx/O5bglj1BvlZ5UP/922/2vaIJLQp+afT O+5ZmYKk+Z723XZuqx/KDX3Q6tNevS1d0eR3ZSIqJ2CzH9an2nClZ5GToOuXI2Os stQzXWsPNSohWWoIvdhdcO+fyz8wEA8Z613YgQQPnMVLN4HyWx0lKNl/XdD6yirZ u/2YZfOKLlIk7aw0Ob7Egh3SN5mWx1tcoWwArV5z0v7wTio1sqXt+u+8h7cmpKYZ ks4SGFSOl8/5F3IadDvpuYLwKf7LKOg58toXQu63PHldpMAi3N70ivi05CQwRFob rNyMG2kB =HHb9 -END PGP SIGNATURE-
Accepted libfann 2.2.0+ds-5 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 20 Feb 2019 20:29:30 +0100 Source: libfann Architecture: source Version: 2.2.0+ds-5 Distribution: unstable Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Changes: libfann (2.2.0+ds-5) unstable; urgency=medium . * Fix broken paths in examples The examples moved from the -doc to the -dev package in -4, but this was overlooked in the examples' Makefile, docs, and dataset paths * d/rules: Drop excluding .js from dh_compress, it's the default in compat 12 * gbp.conf: Set pristine-tar, sign-tags options * d/control: Switch to https in Homepage field * Remove cruft references to former binary package libfann-dbg Checksums-Sha1: 9fd98656f7a92a10fe84a1d1226926a2510a53e2 2089 libfann_2.2.0+ds-5.dsc 1abda2eda8e77f8cd84f8dd6bb8a712ef8ffc165 12504 libfann_2.2.0+ds-5.debian.tar.xz 5cbd72e2010eee3abfe69337b5296aa337a53cf0 5896 libfann_2.2.0+ds-5_source.buildinfo Checksums-Sha256: 5fcbaf8061ccf459f57ded352be3efc2351d735c01ae6c4e1b71ae13455a6457 2089 libfann_2.2.0+ds-5.dsc a1677f04f9bf42511131f278e0948016a5b0b3df671b13b5c2283fe1e768eb3a 12504 libfann_2.2.0+ds-5.debian.tar.xz 58722933658c1f940367651b009d475e76acd0bd78d7d6a06c3f03ec9c15409b 5896 libfann_2.2.0+ds-5_source.buildinfo Files: 2b0ba594184befa2cd174355f93d5866 2089 libs optional libfann_2.2.0+ds-5.dsc fbbbdaa8ec326b2343c1c63162c72702 12504 libs optional libfann_2.2.0+ds-5.debian.tar.xz 92582c59ea84ffbb447d09f547ffe1fa 5896 libs optional libfann_2.2.0+ds-5_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAlxtq+4PHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrqakP/ihyW5wr6M5GpjLL5vwne50ReH4Hh/+y0LwG MHapLo+skT8VGhDxGr9YBi2DIkAqR7BW1aPT3ZZUfrjLZVR6QPUhS1QPFtQjD/YN F9hPUCCutKUC8tMq2kPad4QFE/xyIBVMy/vGcNSzYqca0M90RWsrwB17xQsuGKki mpM5uSZlaS0mkg7GTCJU1f0rl+9oSuCAxel8nSkvPnapKn0ii2vVGwMn9vHyCMLn H7M9FhSucRWVJHbGswGUcODJu25AP0LYGbs1Zt56l4IRo7k13jN3DBS5k8Ryt9iA /yoBP69R6bnyT27CRKiNe+8oz6f0ZhGFOpa9pvCaOr516KZh2nVmUf1UNlB/eStV GZo/mIR2RImryz7wM7I5b4OlTlqDr4wce/E7VjbDabAo0tQ4lqAQMDVn4GzoHsZ+ ODmIebsA/DEy5SO8Bn6UDeDmGC/isZmj5Y7801nwnzaA/pRlW4eALU/nyCeeapV0 KV+QCvTL+0NlKfQgJQwclsovA19VYzcEk7oNHevCJI10U9iUDCXsU5UNXQFb/pIe De8nlivLeoDkhzE5n9TCy+U0BXFzJ+Cr+2H5vAB/hmwA75q2SLsAkAIAFdzZnUmd qvnRSek/NJhk5xCP5yXLrtFsDGXr4SVuS02XjGZO+8n7nDM8OKEhlUqu6YbSdeo5 9ok27XLL =UgJS -END PGP SIGNATURE-
Accepted cron 3.0pl1-131 (source) into unstable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Wed, 20 Feb 2019 17:44:49 +0100
Source: cron
Architecture: source
Version: 3.0pl1-131
Distribution: unstable
Urgency: medium
Maintainer: Javier Fernández-Sanguino Peña
Changed-By: Christian Kastner
Closes: 893576 913483 913484
Changes:
cron (3.0pl1-131) unstable; urgency=medium
.
[ Boyuan Yang ]
* debian/control:
- Merge duplicated build-dependency entry for debhelper
- Update Vcs-* fields and use git repo under Salsa Debian group
(Closes: #913484)
- Add dependency to sensible-utils (Closes: #913483)
* debian/rules: Do not explicitly invoke dpkg-architecture for architecture
variables. Instead we are now using /usr/share/dpkg/architecture.mk to
provide them
.
[ Bjarni Ingi Gislason ]
* crontab.1: Some format fixes in the manual. (Closes: #893576)
.
[ Christian Kastner ]
* d/control:
- Switch Build-Depends from debhelper to debhelper-compat
- Add Rules-Requires-Root: no
We don't need (fake)root for building the package
- Drop ancient dpkg Pre-Depends and Breaks
The versioned dependencies are older than oldoldstable
- Bump debhelper compatibility level to 12
- Switch to https in Homepage field
- Bump Standards-Version to 4.3.0
- binary package cron:
+ Add Pre-Depends: ${misc:Pre-Depends} for init-system-helpers
+ Switch cron MTA Recommends to default-mta | mail-transport-agent
Recommend these virtual packages rather than specific MTAs
+ Move unqualified debhelper control files to from * to cron.*
* Remove now obsolete d/compat
* d/rules:
- systemd sequence has been removed in compatibility level 11
- Drop override_dh_compress
Examples are no longer compressed in compatibility level 12
* d/copyright:
- Switch URL to official MRCF 1.0 policy
- Ustream-Contact -> Upstream-Contact
* Remove ancient cruft from maintainer scripts
This cruft dealt with conffile tasks from before oldoldstable. As we don't
provide a direct upgrade path from older releases, this is just maintenance
overhead
* Drop empty preinst maintainer script, as a result of the cruft removal
* d/watch
- Update to format version 4
- Switch to https
* Remove trailing whitespace from changelog
* Remove trailing whitespace from debian/control
Checksums-Sha1:
7782843ab6567a4a3b0d51127fef42ad0524155e 1918 cron_3.0pl1-131.dsc
a7fa1b13b28be34f328b3edcccd7d6df9e412b24 100554 cron_3.0pl1-131.diff.gz
e0c0200a43e19eff89e408d05f1c3d8b37694fb7 5234 cron_3.0pl1-131_source.buildinfo
Checksums-Sha256:
6471d1a41d9450f1968568792ba5f7cce14a372a1ebc381d8a7365ce65b84614 1918
cron_3.0pl1-131.dsc
21b1489b3d28bfcadfdb53adef07a3c77d28ae3446ce49d1a2eb9f2b52ce9218 100554
cron_3.0pl1-131.diff.gz
dd02ba0bb527bf304470fa2858129369d6e2eb1340c143493a5f1221ac39909d 5234
cron_3.0pl1-131_source.buildinfo
Files:
0e0a3b635335249d3da6f04643d93130 1918 admin important cron_3.0pl1-131.dsc
0bcf529a7b8bde5e6d837e759551d2d6 100554 admin important cron_3.0pl1-131.diff.gz
4c5a0e837b4584a0f745e447ce960cc7 5234 admin important
cron_3.0pl1-131_source.buildinfo
-BEGIN PGP SIGNATURE-
iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAlxth7APHGNra0BkZWJp
YW4ub3JnAAoJEDmVOjfeTrNrhzcP/RcKO/mNx4/4M8BBO921uQipBGeeFvy3Dsh5
7dt8p5lGhsXscFgkn/WvVIb1kr73xwDmEK+kGneOOhnZDJiIzOfIp+U5XnupBH5j
r+/Y+to6t/aX6qgvhp36aqJ7YS2UG1dURchM1qgi9+Kxmv5gRWpi8o6YL3SCSe6b
NFneFR+FGox6AYEbbniFv0AkrQEoj+43Iu9uwEWZi8T0CDKjGxl/jJq8gh+l0OvA
B43zGzw0o8cc6O7f1PiHY6mIOJ+S1+fuZdeiuxocvzQG72vJvJ3gvntMERNQ0cJO
wtuDKcalcc5UjA3x8dy10+pINx59pFiVJpE8GLxiXyyA4s4CDuqftRcY44morzKp
KXXM9v+EVaNLjgiE7+pK1awpDfsegXDLkw7m6JvnieATVgptKSG2zk+kFYjQBMkb
cNV+l9MwbjoN5MOUMt652BvXmNk3Kuv95yCcZ1Qulm2xEKJklnV5QbGksBDAmRFA
CMTR1iz9yB6w8npekMb+lRiNNR+o4BNFZSpGf9hIJqjJI4EeR/rA3Fo1A9ni1VaI
ShqXjynrKg0dSNxGIA/67KNhHPPz7fdmf6iErF7rGQD5sl9XzyfNUxb1MWJSgG6S
K4CyprE6AkKS+V5K2Qs3+Je7mGWsiJ7w5HtIWUdmV2p5YPcKi5R1MrJBZRc2xqqr
EWDL2rhB
=dxml
-END PGP SIGNATURE-
Accepted pyevolve 0.6+git20151103.589b6a9-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 18 Feb 2019 21:54:45 +0100 Source: pyevolve Architecture: source Version: 0.6+git20151103.589b6a9-1 Distribution: unstable Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Closes: 896625 Changes: pyevolve (0.6+git20151103.589b6a9-1) unstable; urgency=medium . * New upstream version 0.6+git20151103.589b6a9 - Upstream has moved from SourceForge to GitHub * Move Files-Excluded patterns from standalone file to d/copyright * Update d/watch to check GitHub HEAD - Upstream hasn't tagged or released yet * d/patches: - Refresh 0002-Fix-broken-example-12.patch - Add patch Switch-away-from-deprecated-sphinx-interface.patch Closes: #896625 * d/tests: Rename ADTTMP to AUTOPKGTEST_TMP * d/control: - Point Vcs-* to Salsa - Switch Build-Depends from debhelper to debhelper-compat - Bump debhelper to compatibility level 12 - Drop ancient X-Python-Version - Bump Standards-Version to 4.3.0 - Add Rules-Requires-Root: no We don't need (fake)root for building the packages - Mark python-pyevolve-doc as Multi-Arch: foreign As per the Multiarch hinter's suggestion - Switch Build-Depends from python-sphinx to python3-sphinx * Remove now obsolete d/compat * gbp.conf: - Set pristine-tar and sign-tags options Drop upstream-tag option We got rid of the custom dfsg branch, everything is on upstream now * Get rid of patch numbers (also set that in gbp.conf) * d/source/lintian-overrides: - Add python-foo-but-no-python3-foo Upstream does not provide Python 3 packages - Drop debian-watch-may-check-gpg-signature Tag has ben re-classified as experimental * d/rules: - Use SOURCE_DATE_EPOCH instead of dpkg-parsechangelog - Drop override_dh_compress Examples are excluded in debhelper compatibility 12 * doc-base: debhelper compat >= 11 installs documentation to main package * d/copyright: - Switch to https in Format field - Bump copyrights Checksums-Sha1: af6dd023329aa7eb45725e87c2f784928808aa64 2269 pyevolve_0.6+git20151103.589b6a9-1.dsc d71f0f35d864a1e57439f302cdcf7db30265f993 2034472 pyevolve_0.6+git20151103.589b6a9.orig.tar.xz cf633fb777f504ef11a1cbaa9f0db085c729d019 11080 pyevolve_0.6+git20151103.589b6a9-1.debian.tar.xz fd67080a3efda362534831ac73c7078f03d73ac6 8967 pyevolve_0.6+git20151103.589b6a9-1_source.buildinfo Checksums-Sha256: 973dfcd14e5c51ecf75abf45da6515a8a807b4f1e7af6048280e05735dcef03a 2269 pyevolve_0.6+git20151103.589b6a9-1.dsc 609ef42c29143bda560334fd4044c7d1100f78a1354a8583e78f0562e3808523 2034472 pyevolve_0.6+git20151103.589b6a9.orig.tar.xz 4aa607935d6593088ddb85afa9aaf16670c9d06d6b9e74da8753be6d5e9d67ef 11080 pyevolve_0.6+git20151103.589b6a9-1.debian.tar.xz c2c5c5e025c80b66ab651d750b49819e735ec3e0f020d81b4a6eaab0c53b9f42 8967 pyevolve_0.6+git20151103.589b6a9-1_source.buildinfo Files: 6e0455baf5859e5ec0d198703fc55d93 2269 python optional pyevolve_0.6+git20151103.589b6a9-1.dsc 69301c3fd5c82250a9fce7e2ccc46d93 2034472 python optional pyevolve_0.6+git20151103.589b6a9.orig.tar.xz 1103c66ffd780363042bf55a01d4dae3 11080 python optional pyevolve_0.6+git20151103.589b6a9-1.debian.tar.xz 841bdcad3c866ccf9ad75832de70148e 8967 python optional pyevolve_0.6+git20151103.589b6a9-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAlxrImMPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrz/QP/2JAKyPRIq/9te9ySwVIMFar09fF/6my/lby TNsDnaxyutA918LSVKt2f695Mqez3AHIAS1FN8IM2PTaEbP3Clfgyb5cipZg5PHT qbINJKSnOeQi2jLJ2VQy9BWQd0gIhx21EFRP6wWUGY80KDJaCIMYbrhf0sL6R6ez A8sxAf1ThRx/rrEW/K66DWufK6jmxl3Mae+bAJugmpYe/YN86gmqJmlZtsJdVOfo i9xDsu4eErtk6eaUTRW4d01KaLdOWd0Tfj5rrQD28lsOsLxvYdxNLj7i5hQ16H2P M7yI/ANWsudv+nhrHiotyyQgGqKGzW/rccVOKs9nIr1z3XYZBlBf7ubbwfOclRf/ hMydxJsYksNsKaYphJG/SUso9z3t0hZEurjv0Lmh+0e5clZW6HNuhTR9duQvmERp Cur7+01c7/uMA596wvwOs69VWJcGrMRm1FMeEoICm5DMH9r1a7BgJ0DlVhm7+uAu c6UWXL7x1OsLEOKOSGQBczheBYW9rfyKHFOqnf8xsULjfjnXAIoz/xC7bqlixjfA kOmHYYkmD/LxgnbDS5PivXQ2BFcEqpuzkcbTsWCoAEQIb6/bGJxtH5v3MmdxcMW/ oE4onGXlyBb+B2WG9bLbfIhyuSRe1HbfR+mwimsEZo3OB5EKmLNlY3ATmjm5uTiT 1+mcjDOl =irMg -END PGP SIGNATURE-
Accepted libmpikmeans 1.5+dfsg-7 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 18 Feb 2019 19:47:28 +0100 Source: libmpikmeans Architecture: source Version: 1.5+dfsg-7 Distribution: unstable Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Changes: libmpikmeans (1.5+dfsg-7) unstable; urgency=medium . * Correct broken Vcs-* fields (copy-pasta) * Drop d/*.dirs, the dh_* helpers create directories as needed * Move our custom manpages from d/ to d/man/ * d/source/lintian-overrides: - Fix syntax issue - Add tag debian-watch-file-is-missing Upstream only provides a link to the current, unversioned download * gbp.conf: Get rid of the 'dfsg' branch Until now, the original upstream source was on branch 'upstream' and the DFSG-cleaned source on branch 'dfsg'. This has little to no benefit, but many downsides: it departs from common Debian workflows, and also represents extra maintenance work Checksums-Sha1: ed92ba5c0ee9cfa000c8b3054c6645e70f2f5674 2268 libmpikmeans_1.5+dfsg-7.dsc b5815e250d12072a3ba779ac5b64cf7b0275f536 8632 libmpikmeans_1.5+dfsg-7.debian.tar.xz 3c31e34bb4d0bffe37147ed2259041eea4ea1c1d 6709 libmpikmeans_1.5+dfsg-7_source.buildinfo Checksums-Sha256: 6069047610eea81324bb7986beb7cfe955e8454d966d536ef70d578943d9172b 2268 libmpikmeans_1.5+dfsg-7.dsc 70735491ed3c52809af4fc9a3e136f2623a776adc377274659d3b133ffd2b901 8632 libmpikmeans_1.5+dfsg-7.debian.tar.xz 026e4a7adb0407bf97d39e1328b429f3e3f518f501bd7dc34f6ded048f33ca3e 6709 libmpikmeans_1.5+dfsg-7_source.buildinfo Files: 4d80435f613fd3cb141cef9c8b57bd4f 2268 libs optional libmpikmeans_1.5+dfsg-7.dsc e788ff07c1014d810e361421a31b3432 8632 libs optional libmpikmeans_1.5+dfsg-7.debian.tar.xz bacf417428e47226858ed8175337913d 6709 libs optional libmpikmeans_1.5+dfsg-7_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAlxq/kQPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNr0zMP+gJffn+V7AjvashwpWEiF2a5zK7czEinBqly dBsL+7WtMAdjuz7DtZEXBfoyjWHNm/cL/wQKSrvJb39+nD98XfX9yVoDY0a7DXg5 W8LEozr/7lXswpqtVvc1ztTFl6v4J4zRS9Z7dHgRD4EK0wVK1QViWhrui+YqarlF g2j7s5n6J6Rz7E5wTxyVw85IOtHTgaTsIxiHKogDagfV8d4fWvy1TqLWobPp7Pv0 3NbVX8rEwJwXedHnOnisZ+9m9f+Lyj/W8LZo66CHIlkgupB9n11JJC0AoikvoidI PBVC/IbTorzl9JTNUuykTmyJ3I+sTZp/cEM/G61Ke43XRWuv1BAm154VBaFG0Yia RgDDR+aCgyUNThpiYeyS5haH4+0O2cMUXAYVZm9ME2XANxZaVTHqf31k79dMI2y0 1dt9trqqqjRvR5b+bxt425450WWV6m/JXcImWJ3G6T/5h7D71nlXwWzE/CTk1/mp Ohh1e+E967F+ML0U4DBpDvduB/wGbmo40uE+fzZ2voWZnb456WMyBOTKCa9i1N+E Kc1apLzYNjKyJcsBrLJ5sxgYJ4TWxrhCzdJIOtWLovkM1VuDSqPS8euZMhk79z1E XBhUrdlrE318Emo+Hr0ZJjnbXrlay9D/aG6XNcyuPnTIteX467EMl/UQId2n36VD cflZwjfW =XjBJ -END PGP SIGNATURE-
Accepted librscode 1.3-6 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 17 Feb 2019 18:11:21 +0100 Source: librscode Architecture: source Version: 1.3-6 Distribution: unstable Urgency: medium Maintainer: Christian Kastner Changed-By: Christian Kastner Changes: librscode (1.3-6) unstable; urgency=medium . * Drop package librscode-dbg in favor of automatic dbgsym packages. As per https://lists.debian.org/debian-devel/2015/12/msg00262.html * d/control: - Point Vcs-* to Salsa - Switch Build-Depends from debhelper to debhelper-compat - Bump debhelper to compatibility level 12 - Bump Standards-Version to 4.3.0 - Add Rules-Requires-root: no. We don't need (fake)root for building the packages * Remove now obsolete d/compat * d/rules: Move override_dh_install to override_dh_missing for --fail-missing * d/watch - Update to format version 4 - Switch to https * Rename ADTTMP to AUTOPKGTEST_TMP * Add Build-Depends-Package to librscode1.symbols * gbp.conf: Set pristine-tar and sign-tags options * d/copyright: Switch to https in Format field Checksums-Sha1: 8e556dc7a551ff6a3c53e50bb2c5945cda2aff2c 1952 librscode_1.3-6.dsc bb7b925deed550ab9a6a95104edefa4794e4f5fa 4916 librscode_1.3-6.debian.tar.xz 8130a99286bd4ae9bd182e93078aba6670e84069 4976 librscode_1.3-6_source.buildinfo Checksums-Sha256: babf73d14bbc7236e11d644e7f6739a60a7f8ff515dde74e77970706dbdabad4 1952 librscode_1.3-6.dsc ea92cd510e2df7123a33936342386994b20da8bef60456dbcbe7e2dcf1c428e5 4916 librscode_1.3-6.debian.tar.xz 630208521f928c08d8dbacc3e360afdbbbf2a1380ac04ada505b3de84c668682 4976 librscode_1.3-6_source.buildinfo Files: daad0c4533d980c9abf331adc95c8a35 1952 libs optional librscode_1.3-6.dsc 1bab7ed266ff90773246963928dd90f4 4916 libs optional librscode_1.3-6.debian.tar.xz 8db7b1d1030237d0044cc624854f3dbe 4976 libs optional librscode_1.3-6_source.buildinfo -BEGIN PGP SIGNATURE- iQJDBAEBCgAtFiEEQZ9+mkfDq5UZ8bCjOZU6N95Os2sFAlxpl1EPHGNra0BkZWJp YW4ub3JnAAoJEDmVOjfeTrNrtg4P/1sloBEcHeeUCejbKpE7HNF1ylvaGi86hZYJ 12HOL0wVvdGshA9lIP1BGai0W41706TpgQTmsI13NC9HvZnoNm4c2LsOggPcPmhq waln3AHSjQmHA/1qGiHeELNDrWTRFZTRBOv3xYe1j8AX5azua9IP7PNfLIkspsR0 vm5O4CGV1Rc6dp9zkuvWGwid/FYa1lMYBZO1cmyr90V9IBqhPmFRl7bsA/n99UOD 04iAAEzoMPyQzSt4g1HGWZWjJ/64k7LcAdJozNrZH4hPHJOFzvNgbMRu6Ha/vXrc Xuok0cYHvjl0en4dxUI65RS/N+FE5uOhXzaN8QzVfGvG4Rz2+19JD2yz0uZg/jeG +oyCxcYeRDfHPw4XhzoxQl0ocgSpTszrCsrDkswC5EP6t6drSzTNIz8Tx9uyMAYR q0r7BvxdO7FNE5kYR05SeUHl+fjN5fakMzdCPEuWfzCuv1qcnBJDQRRDLrM96aHE J7FLmZSvWmZkcHQen/q1lSqLlrPZN9n9XJ9pDq8Ma2K3AQXfhAaZkN/MBLYhj2yg fEWNR2+wi55Hm7EsrUNiJfDwHqlmFqjpliAY2xpIwB1qEivJhZYG3nxI+9JYZrBe lMcNVFoxRbvCcvtd1Tlmzr7jUHtaXyh7BG++O1q+APgXkySbG8aCWnbfWXibviTY olEefCZL =DraJ -END PGP SIGNATURE-
