Bug#762412: ITP: paraclu -- Parametric clustering of genomic and transcriptomic features
Package: wnpp Severity: wishlist Owner: Charles Plessy * Package name: paraclu Version : 9 Upstream Author : Martin C. Frith * URL : http://www.cbrc.jp/paraclu/ * License : GPL-3+ Programming Lang: C++ Description : Parametric clustering of genomic and transcriptomic features Paraclu finds clusters in data attached to sequences. It was first applied to transcription start counts in genome sequences, but it could be applied to other things too. . Paraclu is intended to explore the data, imposing minimal prior assumptions, and letting the data speak for itself. . One consequence of this is that paraclu can find clusters within clusters. Real data sometimes exhibits clustering at multiple scales: there may be large, rarefied clusters; and within each large cluster there may be several small, dense clusters. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140922014634.32408.15482.reportbug@localhost.localdomain
Bug#762381: ITP: libpegex-perl -- Acmeist PEG Parser Framework
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libpegex-perl Version : 0.55 Upstream Author : Ingy d�t Net * URL : https://metacpan.org/release/Pegex * License : Artistic or GPL-1+ Programming Lang: Perl Description : Acmeist PEG Parser Framework Pegex is an Acmeist parser framework. It allows you to easily create parsers that will work equivalently in lots of programming languages! The inspiration for Pegex comes from the parsing engine upon which the postmodern programming language Perl 6 is based on. Pegex brings this beauty to the other *just*modern languages that have a normal regular expression engine available. Pegex gets it name by combining Parsing Expression Grammars (PEG), with Regular Expessions (Regex). That's actually what Pegex does. PEG is the cool new way to elegantly specify recursive descent grammars. The Perl 6 language is defined in terms of a self modifying PEG language called Perl 6 Rules. Regexes are familiar to programmers of most modern programming languages. Pegex defines a simple PEG syntax, where all the terminals are regexes. This means that Pegex can be quite fast and powerful. Pegex attempts to be the simplest way to define new (or old) Domain Specific Languages (DSLs) that need to be used in several programming languages and environments. Things like JSON, YAML, Markdown etc. It also great for writing parsers/compilers that only need to work in one language. signature.asc Description: Digital Signature
Re: Bug#762116: marked as done (general: Some packages depend on a particular init system)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/18/2014 at 12:10 PM, Holger Levsen wrote: > So file it there, or rather please don't. Better send patches. > Really. Upstream has decided to go this way / these ways, the best > way to persuede them into another direction also, is by providing > code. Filing bugs against the individual packages which depend indirectly on systemd would not be productive. The bug is not that these packages depend on functionality which they need; the bug is that functionality which they legitimately want to depend on is provided by an init system, rather than by something that can run independently of any init system, but is not something that must necessarily be provided by anything that qualifies as an init system. I agree that this is an upstream bug, but the upstream in question is not that of the individual packages which indirectly depend on systemd, but that of systemd itself - and the design choices which lead to this undesirable situation appear to be intentional decisions (one might even say "policy") on their part. Thus, filing bugs about this against systemd (either in Debian or upstream) seems unlikely to be productive either. As a decent coder who is not familiar with the functionality in question except from a layman's perspective, the best approach I've been able to think of to resolving the current instance of this problem would be to redesign systemd such that its cgroups management takes place in a separate process, which does not depend on having systemd be PID 1 (or ideally be present at all), and then have the PID-1 systemd depend on that external process for its cgroups management - and fall back to a reduced-functionality mode, with no cgroups handling, if that process is not available. Alternately, to avoid the need for such a reduced-functionality mode, it could also work to copy the cgroups-management code out of the PID-1 systemd into a standalone form (with any modifications necessary to let it work that way), and then make sure that any updates or other changes to either set of cgroups-management code get applied in both places. But that would be much harder to sustain, in terms of keeping their functionality parallel and equivalent. Either way, libpam-systemd would then not need to depend on systemd-sysv in order get the cgroups-management functionality it needs; it could instead depend directly on the standalone separate daemon, and so could anything else which needs similar functionality. That would seem to break the chain which is the primary means by which packages indirectly depend on systemd-sysv, as far as I'm aware. I strongly suspect, however, that even if patches implementing either of these were to be provided to systemd upstream they would be rejected out of hand. If there is reason to think that I'm wrong in that, I'd be glad to know about it. Unfortunately, I lack the emotional fortitude to try to brave that breach (if you'll excuse my mixing metaphors). > I'm closing this bug because this ain't a general bug in Debian. (At the least, it's much closer to such than the usual "support request with no substantial information to go on" bugs that are what usually tends to get filed against general. ^_^) > Some packages depend on Gnome too (or KDE or some obscure OCAML > library) and it's no secret mean conspirancy that they do so, but > rather relying on some feature somewhere. Aka: "business as > usual". An init system is fundamentally different from a library, both because it's a more low-level system component, and because while it's possible to have multiple libraries installed and running in parallel it is not possible to have more than one init system running at a time. The problem is not that a package depends on a feature that it needs. The problem is that that feature is implemented primarily - or even only - - in an init system, but is not implemented in other init systems. Since it is not practical to require all init systems (present and future) to implement certain functionality, beyond that which is essential to the nature of an init system, the only way to avoid this is to require that no init system implement any feature that something outside of the init system might legitimately want to depend on - unless that feature is also implemented equally in a standalone form. - -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUHwiUAAoJEASpNY00KDJrYNYP/2WNlyc/Nbu/GP58cM+KKMFC EEtcMVYZgy3hW6Ur6d/FeUUYNYfYkjqNqVWzlccdVh/t8b0U+fqA94vJuVNUxSbZ GapIePhwuKACY2AmMzPxhOKnDV4WtLI+sVsKQrrCWsRXSqqmjx7nEAHDwEXO9o8l 6BvlgZrGOotNCcdhs82uTYffj3B0UKPTa7xput7pBKdngiDXEFnj/262RiV13YQs NXhgFpGO9mbQozg79qPo3EHC+fi7QUryuTLwuGt1B2yR0F0kJmP911FrRIjH3pYu V1IFJt7KDDkGSGbBUOOkT1rXL93U3U9RlJCZ
Re: schroot, apt-get and experimental
On Sun, Sep 21, 2014 at 10:11:50 -0500, Adam Majer wrote: > On Sun, Sep 21, 2014 at 11:14:41AM +0200, Peter Palfrader wrote: > > (If you don't like that, we can probably consider your patches to > > dd-schroot-cmd :) > > Is the source code only in /usr/local/bin on the schroot machines? Or > is there a better repository? > There's http://anonscm.debian.org/cgit/mirror/dsa-puppet.git/tree/modules/porterbox/files/dd-schroot-cmd Cheers, Julien signature.asc Description: Digital signature
Re: schroot, apt-get and experimental
On Sun, Sep 21, 2014 at 11:14:41AM +0200, Peter Palfrader wrote: > > dd-schroot-cmd -c weaseltst -- apt-get install > libqt5opengl5-dev/experimental OK, thank you. > Which appears to have worked. > > (If you don't like that, we can probably consider your patches to > dd-schroot-cmd :) Is the source code only in /usr/local/bin on the schroot machines? Or is there a better repository? - Adam -- Adam Majer ad...@zombino.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140921151148.ga2...@mira.lan.galacticasoftware.com
Re: schroot, apt-get and experimental
On Sat, 20 Sep 2014, Adam Majer wrote:
> There seems to be an issue with dd-schroot-cmd on porter boxes (I just
> checked barriere) where it seems impossible to actually use
> experimental distribution.
>
> For example,
>
> $ dd-schroot-cmd -c $ssession -- apt-get build-dep qtcreator -t experimental
From
dd-schroot-cmd -c weaseltst -- apt-get install libqt5opengl5-dev/experimental
I eventually ended up at
dd-schroot-cmd -c weaseltst -- apt-get install
{libqt5opengl5-dev,libqt5opengl5,qtbase5-dev,libqt5concurrent5,libqt5core5a,libqt5dbus5,libqt5gui5,libqt5network5,libqt5printsupport5,libqt5sql5,libqt5test5,libqt5widgets5,libqt5xml5,qt5-qmake,qtbase5-dev-tools}/experimental
Which appears to have worked.
(If you don't like that, we can probably consider your patches to
dd-schroot-cmd :)
Cheers,
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
http://www.palfrader.org/ | `. `' Operating System
| `-http://www.debian.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140921091441.gj8...@anguilla.noreply.org
