Bug#911506: ITP: r-cran-gsa -- GNU R gene set analysis

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-gsa
  Version : 1.03
  Upstream Author : Brad Efron and R. Tibshirani
* URL : https://cran.r-project.org/package=GSA
* License : LGPL
  Programming Lang: GNU R
  Description : GNU R gene set analysis
 This GNU R package provides functions for gene set analysis.
 .
 It determines the significance of pre-defined sets of genes with respect
 to an outcome variable, such as a group indicator, a quantitative
 variable or a survival time.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-gsa
This package is needed to upgrade r-cran-samr to its latest upstream version.

Bug#911498: ITP: python-httptools -- framework independent HTTP protocol utils

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-httptools
  Version : 0.0.11
  Upstream Author : 2015, MagicStack Inc.
* URL : https://github.com/MagicStack/httptools/
* License : Expat
  Programming Lang: Python, C
  Description : framework independent HTTP protocol utils

 httptools is a Python binding for nodejs HTTP parser. It contains two classes
 httptools.HttpRequestParser, httptools.HttpResponseParser and a function for
 parsing URLs httptools.parse_url.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlvLj5IRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WoHegf+JU4g3YH/HsxAlLdcX9uDSYx22dhXzHTr
0+SOVjq3QXle4kTa0gZ+VcABTLcVn9W+1yDgJSyfuZxChYO6nTl1ww5ljBFnH3Rp
kJ4Wr97phmyfw3mf75JQpwP+nAaCOXRSEYxx6lXOwTq69T17497Pg7D/BVvDt+D1
cWQZtiD42OcDcNWvrjkU+gB27BgtM9okgYqJc2DALySGVn1lxezuniw095IezgXQ
6TqSoHNKWt+QWtpMt4alYKnFKaRYG9uXlT62NVSpJvBo/W3BZZGqBwEuy4q9Tyem
tUUmyFttd/PrSKLaqsGq4HOcbzgiq0TAtOZKabTPDz0Wp8Ida/rKRA==
=EXrl
-END PGP SIGNATURE-

Re: Debian Buster release to partially drop non-systemd support

[Marco d'Itri]

On Oct 20, Paul Wise  wrote:

> It might be feasible to introduce nosystemd build profiles to Debian
> source packages and then create a shed/bikeshed/PPA (once that
> infrastructure exists) that contains rebuilds using that build
> profile. That would allow Devuan's libsystemd stripping to be
> completely merged into Debian source packages and infrastructure. I
No need to introduce build profiles: if somebody cares enough they can 
spend one hour to revive my libsystemd-dummy package, which I wrote 
because I did not want to use conditional build dependencies for the 
hurd/kfreebsd ports in my own packages.
It allows to rebuild any package with no source changes at all and 
remove the libsystemd dependency.
As usual, there is a lot of talking and not much code.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: no{thing} build profiles

[Andrey Rahmatullin]

On Sat, Oct 20, 2018 at 06:37:20PM +, Ivan Shmakov wrote:
>   Now, unless I be mistaken, “build profiles,” as suggested in
>   this subthread, are meant to allow for building packages with
>   specific changes to their run-time library dependencies?
>   Frankly, I don’t see much of a problem with that – assuming that
>   the libraries are “well-behaving,” that is.
You seem to miss that this subthread started with discussing Devuan
removing libsystemd deps.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

no{thing} build profiles

[Ivan Shmakov]

> Bastian Blank  writes:
> On Sat, Oct 20, 2018 at 06:54:07PM +0200, Arne Babenhauserheide wrote:
> Ansgar Burchardt  writes:

 >>> Should Debian also support “noalsa”, “noavahi”, “nocups”,
 >>> “nopulseaudio”, “nosysvinit”, “nodbus”, “nopam”, “nowayland”,

So long as there’s sufficient interest among the developers?
Sure, why not?

 >> Are alsa, avahi, cups, pulseaudio, sysvinit, dbus, pam and wayland
 >> all similar in scope to systemd?  If not, then this question is a
 >> strawman.

 > Yes, they all completely took over their field and have a lot of haters.

AFAICT, that’s, for the most part, untrue.  For instance, I do
/not/ run Avahi (why for?), Cups (I use an ad-hoc wrapper around
foo2zjs instead), Pulseaudio (for there’s ALSA, but also NAS and
JACK should I need them), D-Bus (although I admit I’ve had to
implement a “no-dbus.perl” stub non-server to work around
Bug#868453), or Wayland (huh?)  And I suppose those who run
Systemd don’t run SysVinit just as well.

Granted, I know of no way to use audio on Debian GNU/Linux without
ALSA; and I know of no way to avoid running PAM, either.

Now, unless I be mistaken, “build profiles,” as suggested in
this subthread, are meant to allow for building packages with
specific changes to their run-time library dependencies?
Frankly, I don’t see much of a problem with that – assuming that
the libraries are “well-behaving,” that is.  I can see an
application's run-time dependency on the presence of client
PostgreSQL, MySQL and MS SQL libraries at run-time as necessary
evil.  Having that application pull one or more of the respective
servers per Depends: is something I tend to consider a bug.

(BTW, while we're at it, could someone please explain me what
tinysshd [1] does need systemd for?  Or why installing neomutt
has to invite gnupg along?)

[1] http://packages.debian.org/sid/tinysshd

-- 
FSF associate member #7257  np. Green Beret (title theme) — Johan Andersson

Bug#911486: ITP: loggerhead-breezy -- Web viewer for Breezy

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: loggerhead-breezy
  Version : 1.20.0
  Upstream Author : Loggerhead Developers
* URL : https://launchpad.net/loggerhead-breezy
* License : GPL
  Programming Lang: Python
  Description : Web viewer for Breezy

 This is a web viewer for projects in the Breezy version control system.
 It can be used to navigate a branch history, annotate files, view patches and
 perform searches.
 .
 This is a friendly fork of the Loggerhead package, modified to work with
 Breezy and ported to Python 3.

Re: Debian Buster release to partially drop non-systemd support

[Andrey Rahmatullin]

On Sat, Oct 20, 2018 at 06:54:07PM +0200, Arne Babenhauserheide wrote:
> > Should Debian also support "noalsa", "noavahi", "nocups",
> > "nopulseaudio", "nosysvinit", "nodbus", "nopam", "nowayland",
> 
> Are alsa, avahi, cups, pulseaudio, sysvinit, dbus, pam and wayland all
> similar in scope to systemd? If not, then this question is a strawman.
Scope? Maybe not. Hate? Some of them yes, surely.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Debian Buster release to partially drop non-systemd support

[Bastian Blank]

On Sat, Oct 20, 2018 at 06:54:07PM +0200, Arne Babenhauserheide wrote:
> Ansgar Burchardt  writes:
> > Should Debian also support "noalsa", "noavahi", "nocups",
> > "nopulseaudio", "nosysvinit", "nodbus", "nopam", "nowayland",
> Are alsa, avahi, cups, pulseaudio, sysvinit, dbus, pam and wayland all
> similar in scope to systemd? If not, then this question is a strawman.

Yes, they all completely took over their field and have a lot of haters.

Bastian

-- 
There are always alternatives.
-- Spock, "The Galileo Seven", stardate 2822.3

Re: PHP Support in Debian

[Ondřej Surý]

Well, either you want old stable or bleeding edge. And with web technologies 
it’s usually the bleeding edge type of people. It would take a full time job to 
create all the variants, and I do this mostly in my free time.

As for reproducible builds - that’s the next thing on my list, it seems that 
the patches got mixed up and the reproducible build patch got replaced with 
something else.

Cheers,
Ondrej
--
Ondřej Surý 

> On 20 Oct 2018, at 18:34, Jonas Meurer  wrote:
> 
>> Am 20.10.18 um 03:50 schrieb Chris Knadle:
>> Jonas Meurer:
>>> * Adding backports to my sources.list doesn't automatically pull any
>>>  packages from there. I have to choose particular packages in a manual
>>>  process in order to install them from backports. That's different for
>>>  repositories like sury.org that provide packages under the release
>>>  target (e.g. 'stretch').
>>>  If I add deb.sury.org to my sources.list, then installed packages with
>>>  newer versions in this repo are automatically upgraded. This makes it
>>>  much easier to abuse the repo, e.g. in order to spread malware. In
>>>  other words, the attack vector is way larger.
>> 
>> There's an available middle-ground, which is to add an additional repository 
>> to
>> the sources.list file and add an apt Pin-Priority in /etc/apt/preferences.d/ 
>> for
>> that repository (of say priority 150) such that any installed packages from 
>> the
>> additional repository get updated, but any not-already-installed packages 
>> from
>> the additional repository aren't automatically used for upgrades.
>> 
>> See 'man apt_preferences' for details.
> 
> Jep, you're right. I was talking about the default experience for users
> who don't know about advanced tricks.
> 
> Cheers
> jonas
> 
> 

Re: Debian Buster release to partially drop non-systemd support

[Arne Babenhauserheide]

Ansgar Burchardt  writes:
> Should Debian also support "noalsa", "noavahi", "nocups",
> "nopulseaudio", "nosysvinit", "nodbus", "nopam", "nowayland",

Are alsa, avahi, cups, pulseaudio, sysvinit, dbus, pam and wayland all
similar in scope to systemd? If not, then this question is a strawman.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: PHP Support in Debian

[Jonas Meurer]

Am 20.10.18 um 03:50 schrieb Chris Knadle:
> Jonas Meurer:
>> * Adding backports to my sources.list doesn't automatically pull any
>>   packages from there. I have to choose particular packages in a manual
>>   process in order to install them from backports. That's different for
>>   repositories like sury.org that provide packages under the release
>>   target (e.g. 'stretch').
>>   If I add deb.sury.org to my sources.list, then installed packages with
>>   newer versions in this repo are automatically upgraded. This makes it
>>   much easier to abuse the repo, e.g. in order to spread malware. In
>>   other words, the attack vector is way larger.
> 
> There's an available middle-ground, which is to add an additional repository 
> to
> the sources.list file and add an apt Pin-Priority in /etc/apt/preferences.d/ 
> for
> that repository (of say priority 150) such that any installed packages from 
> the
> additional repository get updated, but any not-already-installed packages from
> the additional repository aren't automatically used for upgrades.
> 
> See 'man apt_preferences' for details.

Jep, you're right. I was talking about the default experience for users
who don't know about advanced tricks.

Cheers
 jonas




signature.asc
Description: OpenPGP digital signature

Bug#911480: ITP: php-excimer -- PHP extension that provides a non-static, non-global profiler

[Kunal Mehta]

Package: wnpp
Severity: wishlist
Owner: Kunal Mehta 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: php-excimer
  Version : 0.0.1
  Upstream Author : Tim Starling 
* URL : https://www.mediawiki.org/wiki/Excimer
* License : Apache-2.0
  Programming Lang: C
  Description : PHP extension that provides a non-static, non-global 
profiler

Excimer is a new PHP extension that provides a non-static, non-global
profiler. It is intended to replace MediaWiki's usage of xhprof/tideways.
There are some more details at .

I'll maintain this as part of the MediaWiki maintenance team.

-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAlvLUN8THGxlZ29rdG1A
ZGViaWFuLm9yZwAKCRBS/I577bf8oqq/D/4z8a8jZhFyH+06ME+rAm5ptuCChwl4
9C0cGfJr4P7c9iu6tul3Q9e6bEXgS6pNm/MVvizAzLamfk9ycD9MJYyYNP3xJJ08
GwU7rDgJ6zv1JDFpMvk1tSI+TmrIV7fVdxF3p/12OWAib6d9wXegw4Jq7bayxwR3
ryFrT4oId3lpD8K6ez53hkS8ruiepllKo/chlODVIyjcIS8kqAk089sZ5ehkw957
bh2bsHNivrmE+IxMt1PoWjgE87ReGU2ux0prqBav2EkQKHQ0vHBsS4AsNa2sgVyS
QRnsIYK6Tm6rfGVuhkpITHeC44Wl2TY6PR0KEiCtmmIMdZePsjuc7ul6Xbo8/Tc5
CLnQGSNfqoyVzijFzDY7GSsGYP0/VcssVx6ktLnkGmbi+H7Cmdz1ATn0VkkbM6d6
/1qG1km0Kya6hj32d1wC2ysgnOAnpu/vOQ96BgRFppn27NH315V72ZwSTkx9vTrQ
hxqPr0OwzM2VPrTgY7Afq3S4PEt+YBpi/jiQ/+EkLQVRVFd/BYWIzAsRnY15isBi
f+kUA/fDuEIiQ82bTlVUCdxBH6BERDRxiToXfONlKVbpTUx28wy3DCGa4aMbtvUh
egaie4/UHGSFLZsdAfVJA1rtwKtH6TVe0p+2D/24ovwcK3m/UCb8GMfy9ZhKBmUR
b4pV6L5PSOFpXw==
=LI1J
-END PGP SIGNATURE-

Re: Debian Buster release to partially drop non-systemd support

[Narcis Garcia]

Does "Debian uses Systemd by default" mean "Debian is married with
Systemd forever"?

Should Debian exclude other desktop environments but Gnome, because
Gnome shell is the default one? Then drop Qt and Wx compatibility?




__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.

Bug#911465: ITP: libciepki1 -- PKCS11 driver for Italian CIE

[Andrea della Porta]

Package: wnpp
Severity: wishlist
Owner: Andrea della Porta 

* Package name: libciepki1
  Version : 1.0-1
  Upstream Author : Andrea della Porta 
* URL : http://github.com/italia/cie-middleware-linux
* License : (BSD-3-Clause)
  Programming Lang: (C++)
  Description : PKCS11 driver for Italian CIE

ciepki allows any PKCS11 enabled application to leverage
the cryptographic and authentication facilities of
the Italian CIE. 
Binaries to change/unlock PIN are also provided.
This will be the main middleware to use with any Italian ID card.
Source code is provided through github as above but this package 
will be a binary only one since teh cachelib will be slightly changed
to provide added security though encryption, and the key/iv should
not be exposed. Cachelib reference implementation on github is almost 
identical except for the lacking encrypted data.
I guess I will need a sponsor to push it to non-free repository.

Bug#911453: ITP: python3-simpletal -- Simple TAL, TALES and METAL implementation

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: python3-simpletal
  Version : 5.2.0
  Upstream Author : Colin Stewart
* URL : http://www.example.org/
* License : BSD-3
  Programming Lang: Python
  Description : Simple TAL, TALES and METAL implementation

SimpleTAL is a reimplementation of the ZOPE TAL (Template Attribute Language),
TALES (TAL Expression Syntax) and METAL (Macro Expansion for TAL) languages.
More information and specifications of these languages is available at
http://www.zope.org/Wikis/DevSite/Projects/ZPT/FrontPage .

This package is for the newer releases of SimpleTAL, which only work with
Python 3.

Re: Re: Debian Buster release to partially drop non-systemd support

[Laurent Bigonville]

Bastian Blank wrote:


On Fri, Oct 19, 2018 at 11:35:54AM +0200, Martin Steigerwald wrote:
> So Devuan almost doubles the percentage of sysvinit-core  installations.

Devuan is _not_ Debian.  They forked it, with the full knowledge that
they might have to do all the work to support their choices.  They had
the chance to not do that, contribute the proper changes back to support
their use case.  They we might have had a proper maintained sysvinit.

But instead they flip tables by even seeing systemd units or libsystemd,
which by definition does nothing in this context.  If someone comes up
with a usable systemd service to init script converter, I don't think
Debian would opt against using it to provide a service for our users.
What would they do?


Yeah well, looking at the following message, some people think that an 
init script converter is "madness":


https://lists.dyne.org/lurker/message/20181020.015531.8bef4b71.en.html

Re: Debian Buster release to partially drop non-systemd support

[Ansgar Burchardt]

Paul Wise writes:
> On Fri, Oct 19, 2018 at 7:30 PM Martin Steigerwald wrote:
>> As long as people choose to strip of dependencies to libsystemd from
>> packages like util-linux, avoiding a fork would not work with how Debian
>> and Debian based distributions are built.
>
> It might be feasible to introduce nosystemd build profiles to Debian
> source packages and then create a shed/bikeshed/PPA (once that
> infrastructure exists) that contains rebuilds using that build
> profile.

Why should Debian spend resources on implementing and maintaining the
changes needed for the "systemd is cancer" trip of the Devuan lead
developers?

Should Debian also support "noalsa", "noavahi", "nocups",
"nopulseaudio", "nosysvinit", "nodbus", "nopam", "nowayland",
... profiles because there are people who do not like these projects and
would like to not see them used?

Or an "ubuntu" build profile so Ubuntu can merge all their changes
(branding, Ubuntu-specific choices, integration, ...) and would no
longer have to rebase them?

If one really cares about which shared libraries one wants to use, this
is *much* easier in source-based distributions such as Gentoo which
already have implemented this (USE flags).

See https://www.gentoo.org/support/use-flags/ for more build profiles ;-)

(The nosystemd build profile was already suggested in the past.)

> That would allow Devuan's libsystemd stripping to be
> completely merged into Debian source packages and infrastructure. I
> guess Devuan have other changes that might be easier or harder to
> merge too though.

And if we also build packages for them, they wouldn't even have to fix
their package-building infrastructure which seems to no longer work for
some time already now ;-) (A datapoint for how much interest in working
on stuff there is?)

But why spend work on implementing and, more importantly, maintaining
all of this for a derivative distribution which already had 498 active
developers(!) back in 2015 according to a presentation by Devuan
developer Alberto Zuin and Devuan founder Jaromil, and which represents
an exodus for half of the active Debian user base (according to a Devuan
lead developer in a publication in 2018)?  They certainly should have
enough resources.

Ansgar