Bug#933830: ITP: ocaml-num -- legacy Num library for arbitrary-precision integer and rational arithmetic
Package: wnpp Severity: wishlist Owner: Stéphane Glondu * Package name: ocaml-num Version : 1.2 Upstream Author : Xavier Leroy * URL : https://github.com/ocaml/num/ * License : LGPL 2.1 with OCaml linking exception Programming Lang: OCaml, C Description : legacy Num library for arbitrary-precision integer and rational arithmetic This library implements arbitrary-precision arithmetic on big integers and on rationals. This is a legacy library. It used to be part of the core OCaml distribution (in otherlibs/num) but is now distributed separately. New applications that need arbitrary-precision arithmetic should use the Zarith library (https://github.com/ocaml/Zarith) instead of the Num library, and older applications that already use Num are encouraged to switch to Zarith. Zarith delivers much better performance than Num and has a nicer API. Several packages depends on this in Debian, including: scilab, z3, coccinelle, ocaml-batteries. The package will be maintained by the ocaml-team.
Bug#933846: ITP: endlessh -- SSH tarpit that slowly sends an endless connection banner
Package: wnpp Severity: wishlist Owner: Nicolas Braud-Santoni -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: endlessh Version : 1.0 Upstream Author : Christopher Wellons * URL : https://github.com/skeeto/endlessh * License : Unlicense Programming Lang: C Description : SSH tarpit that slowly sends an endless connection banner Endlessh is an SSH tarpit that very slowly sends an endless, random SSH banner. It keeps SSH clients locked up for hours or even days at a time. The purpose is to put your real SSH server on another port and then let abusive bots get stuck in this tarpit instead of bothering a real server. Since the tarpit is in the banner before any cryptographic exchange occurs, this program doesn't depend on any cryptographic libraries. It's a simple, single-threaded, standalone C program. It uses poll() to trap multiple clients at a time. See https://nullprogram.com/blog/2019/03/22/ for more details. -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl1Gvh4RHG5pY29vQGRl Ymlhbi5vcmcACgkQ5vmO4pLV7MvxQQ/9Eig0tW91IHtmQ5qgCncUr2ESyBFjYNGx rAsLiHMG2YyYgMkR2VJJt/Uc6nx76zqs+SqHPo6cmU27iHI8FrM+7qJ6NdhNwm8s whXzjcVDpzibnY9voBFvRNd6/2lxvBzMBXtoTGlgFrpH7bYwwnKv27NeC/SKc6En Gh7CGYJg5sbJWtZIuPoqA5ijtFGLxwQlAJTlPw77K0wHLjxkVO+vR6Y6eec813+B XHJzhhpqU+sJmEI62LMBlZIIqypn2KXCPS4CO6lhKXT6Xff6+q85URCNUVTTq/QQ nP1jB7vSmILZ0CwSakWqFg8rtU4cJ3qpRXxNZ70m8FO69Tpm90mJT7wt0DQjqbLg c0t0+tn7mG1e65F/pOXpKXYafWaY08DYZdtQ9qddF6O0Wgq2tCkUy1u8c0jMK4x9 DlPdAR4yVnW53VHHPm6ILqm4esFkYeM2m2GayrxBYUSkwAiV1EMNxLRhRZL9Q9tq gy2Ajb0niUz5HFaksQcoj1cwO1nKTixTGyINWhRrvnbZbhAkj6KlhRpZYb1NH71P LbGOTiLYK2KVojq/G2NCcziQlhfYbjDB3hdB/JRBqE6CJzN/ZIU4LrNBEtM3i7zX b0xeF0pjenp1l2GgBNkdEilvcIMhiplcqbIhq3dcsgfS8bf1PUUS5lf9jyJXKkyG oFYXOdof7+Q= =P059 -END PGP SIGNATURE-
Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?
On Mon, 29 Jul 2019 18:42:34 +0100, Simon McVittie
wrote:
>On Wed, 24 Jul 2019 at 20:14:22 +0200, Marc Haber wrote:
>> Scripts with such dependencies will probably fail miserably on systems
>> that are using systemd-cron instead of one of the "classic" cron
>> packaes
>
>I thought so too, but they don't: systemd-cron uses run-parts for
>cron.{hourly,etc.} too.
... this imports many disadvantages of the old scheme into the new
world. Philipp has explained in this thread very well.
Maybe systemd-cron could be extended to be locally configurable
whether to use run-parts, keeping the old semantics, or to generate
individual timers.
systemd itself would need a means to group different timers together
with the constraint that at most X of those can run in parallel.
>On Sun, 28 Jul 2019 at 08:47:49 +0200, Marc Haber wrote:
>> Setting RandomizeDelaySecs sufficiently high on our daily jobs would
>> probably help to chop off the load pike that especially virtualization
>> setups running many Debian instances suffer from at 06:25 or 07:35. I
>> think this could be a net gain worth pursuing.
>
>If you want this, the way to opt-in to it is currently to add a native
>systemd timer, and make the traditional cron script a no-op on systems
>running systemd (to avoid doing the periodic task twice). For example,
>apt and man-db have both done this.
... which takes away flexibility and standardization from the local
admin, adding more things to think about when developing larger
infrastructures. I am not sure whether I like that.
Greetings
Marc
--
-- !! No courtesy copies, please !! -
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Cron, anacron, cronie, systemd-timers
On Mon, 29 Jul 2019 19:13:15 +0100, Simon McVittie
wrote:
>On Sun, 07 Jul 2019 at 17:00:53 +0200, Marc Haber wrote:
>> And on the third side, we have systemd timers, which are not suited as
>> a complete replacement. There is code to transform crontab entries into
>> systemd timer units, but functionality that cron delivers, such as
>> in-sequence execution of the cron.{daily|weekly|monthly} jobs and the
>> ability to send cron-job output per e-mail (which can be a nuisance, but
>> is still functionality a lot of code depends upon).
>
>Presumably you got distracted by the parenthesized clauses and lost the
>end of this sentence, which was meant to end with "functionality that
>cron delivers ... is lost"?
Presumably, yes. Happens to me all the time.
>> in-sequence execution of the cron.{daily|weekly|monthly} jobs
>
>As noted in another thread, this isn't actually missing from systemd-cron,
>which still uses run-parts for these (although
>https://github.com/systemd-cron/systemd-cron/issues/47 requests the
>behaviour that it seems we both assumed it already had).
I am not sure which way is the better one. I can think of both methods
having advantages and disadvantages and would probably try the other
one if it was implemented or just available by throwing one switch.
>> ability to send cron-job output per e-mail
>
>I think sending cron job output by email can be either a positive or a
>negative, depending on the system it's happening on.
Sending cron output by e-mail has the advantage of getting the admin's
attention right away in a place where people usually look a anyway. It
has the disadvantage of not scaling at all, so the journal is the
better place for a site running more than, say, a hundred systems. But
those places tend to have monitoring mechanisms in place that can be
used to lead the administrator's attention to those systems with cron
output present.
Having cron output going to a journal at a place that doesn't have
sophisticated monitoring is hiding information and hiding problems,
which is bad. If sending cron output per mail is the default, the pain
is likely to increase with growing number of systems, motivating those
places to change things. Starting with hiding information isn't a good
thing from this point of view.
> On a traditional
>Unix server with a local MTA and monitored local email accounts, it's
>certainly expected functionality, and perhaps the best way to contact a
>sysadmin - but not every Debian system falls into that category any more,
>with many desktop systems having personal email travel directly between
>the user's MUA and remote IMAP/SMTP servers like GMail, the same way it
>typicaly would on Windows or macOS. On such systems, if there is a local
>MTA at all, it will often deliver system-level email to a mbox that the
>user probably isn't aware of and certainly never reads.
Same effect as having the information in the journal, with the notable
exception that the journal is rotated.
>It has been a recurring issue that there is no good way to notify the
>user of a typical desktop/laptop system about things going wrong during
>boot, package installation or normal operation. The system log (syslog or
>systemd Journal) is certainly imperfect, but it seems closer to a solution
>than email does - it already a concept of priority, has configurable
>data retention, interleaves messages from concurrent events in multiple
>daemons, records segfaults (and other core dumps if systemd-coredump
>is used), and includes at least a subset of messages from system boot
>and daemons (admittedly rather less complete on sysvinit systems, where
>each daemon has to implement syslog support for itself rather than just
>logging to stdout/stderr).
A single, stand-alone system is the third case, yes, but I think that
have lost the majority of those users to the more "user-friendly"
derivatives already anyway.
Greetings
Marc
--
-- !! No courtesy copies, please !! -
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Bug#933885: ITP: GNU Health - a hospital information system
Control: reassign -1 wnpp On Du, 04 aug 19, 22:44:51, Sakirnth Nagarasa wrote: > Package: gnuhealth > Owner: sakir...@gmail.com > > * Package name: gnuhealth > Upstream Author : GNU Health contributors > * License : GPL-3+ > Description : GNU Health is a Free/Libre project for health > practitioners, health institutions and governments. It provides the > functionality of Electronic Medical Record (EMR), Hospital Management > (HMIS) and Health Information System (HIS). > > Its modular design allows to be deployed in many different scenarios: > from small private offices, to large, national public health systems. > > Greetings, > > Sakirnth (Saki) -- Looking after bugs reported against inexistent or removed packages signature.asc Description: PGP signature
Re: Bits from the Release Team: ride like the wind, Bullseye!
Hi Paul! El sáb., 20 jul. 2019 16:42, Paul Gevers escribió: > Hi Lisandro, > > On 07-07-2019 16:16, Lisandro Damián Nicanor Pérez Meyer wrote: > >> All autopkgtest failures considered RC for bullseye > >> === > >> > >> From now on, all autopkgtest failures will be considered > release-critical for > >> bullseye. So if your package has failing autopkgtests, now is a good > time to > >> start looking for a fix > > > > Now this raises some questions for me. Now I maintain a (huge) library > > (hello Qt!). I do an unstable upload and package A starts failing it's > > autopkgtests. In this case: > > > > - How does this failure affects the uploaded library (imagine we have > > a transition, as it will always be Qt's case due to private headers). > > By default, the migration to testing will be blocked, exactly like we > have been doing the last half year. > > > - What's expected from the maintainers of the library? > > It is expected that you communicate (e.g. via a bug report filed against > both packages like I have been doing for over a year now, see examples > on [1]) with the maintainers of the package to see why the test starts > failing. Together, you should be able to work out which package needs to > adapt. Either the autopkgtest found a real issue in your library which > you need to fix, or the package needs to adapt to the new status of your > library, either by fixing the package itself, or its autopkgtest. The > migration of your library will be stalled to give the package time to be > adapted. Of course that needs to happen within a reasonable amount of > time, so if it takes to long, or you and the maintainers of the package > can't agree on who should adapt what, contact the release team. > > Just to be clear, in case you got confused by it, if the package > *already* fails in testing, it isn't a concern for packages that just > trigger that autopkgtest, only for the package with the failing > autopkgtest. > > I wonder if you were thinking of something else? If so, please elaborate. > First of all thanks for replying and sorry for not doing so sooner, I clearly missed it. No, what I have been perceiving (and pretty please note that this is my personal "feeling") is that maintainers, specially library maintainers, have even more and more "stuff to care for". Also please don't get me wrong, I do understand that this is indeed with the idea of improving Debian. But the amount of work needed to maintain the same stuff I have been working with this last years take more and more time, to the point that sometimes I feel it gets into pair with a payed job. Once again please remember it's my personal point of view, and if something above doesn't seems quite right it might be my not so good English ;-) Again, thanks a lot for replying. Cheers, Lisandro. >
Bug#933907: ITP: erlang-mimerl -- Erlang library to handle mimetypes
Package: wnpp Severity: wishlist Owner: James Valleroy * Package name: erlang-mimerl Version : 1.2.0 Upstream Author : Benoit Chesneau * URL : https://github.com/benoitc/mimerl * License : Expat Programming Lang: Erlang Description : Erlang library to handle mimetypes Parse IANA media types (formerly known as MIME types). mimerl provides functions to transform file extension to mimetype, web extension to mimetype, filename to mimetype, web path to mimetype, and to return the list of extensions for a mimetype. This is a dependency of pleroma (#895050) (via erlang-hackney and elixir-swoosh). I plan to maintain this package in erlang-team.
What compiler flags are allowed in unstable/testing
Hi all, What compiler flags are allowed for optimization with gcc in debian unstable/testing? My project has got support for builtin vector functions. And we don't enable any compiler flags to architecture specific CPU extensions. https://salsa.debian.org/multimedia-team/gsequencer/blob/master/debian/rules Learn more about vectors: https://www.linuxjournal.com/content/introduction-gcc-compiler-intrinsics-vector-processing cheers, Joël
