Re: Handling Multi-Arch packages that must be installed for every enabled architecture?

[Sven Joachim]

On 2016-06-24 23:01 -0700, Josh Triplett wrote:

> Some packages, if installed on any architecture, must be installed for
> every enabled architecture.  Most notably, an NSS or PAM module package,
> if enabled in /etc/nsswitch.conf or /etc/pam.d respectively, must exist
> for every enabled architecture to avoid breaking programs for that
> architecture.
>
> As one possible solution for this problem (but not an ideal one, just a
> thought experiment), dpkg could support a new value for "Multi-Arch",
> "Multi-Arch: every".  This value would imply "Multi-Arch: same", but if
> installed, would additionally cause dpkg to act the same way it does for
> Essential packages: install the package when enabling the architecture.

This is not at all what dpkg does, the Essential flag only means that
dpkg will not remove the package in question, unless given the
--force-remove-essential switch.

> (And when installing the package, dpkg would need to require installing
> it for every supported architecture; dpkg could refuse to configure the
> package if any enabled architecture doesn't have it unpacked.)

One problem here is that dpkg does not even know which packages are
available.  Another one: should "dpkg --add-architecture" automatically
deconfigure any such "Multi-Arch: every" package?

I think such problems are better solved in apt: apt-get dist-upgrade
already reinstalls every Essential package, the same way it could ensure
that NSS or PAM modules are pulled in for every enabled architecture.

Cheers,
   Sven

Re: Handling Multi-Arch packages that must be installed for every enabled architecture?

[Ben Hutchings]

On Fri, 2016-06-24 at 23:01 -0700, Josh Triplett wrote:
> Some packages, if installed on any architecture, must be installed for
> every enabled architecture.  Most notably, an NSS or PAM module package,
> if enabled in /etc/nsswitch.conf or /etc/pam.d respectively, must exist
> for every enabled architecture to avoid breaking programs for that
> architecture.

What if I enable an architecture only for cross-building and don't
intend to run programs from that architecture?

> As one possible solution for this problem (but not an ideal one, just a
> thought experiment), dpkg could support a new value for "Multi-Arch",
> "Multi-Arch: every".  This value would imply "Multi-Arch: same", but if
> installed, would additionally cause dpkg to act the same way it does for
> Essential packages: install the package when enabling the architecture.
> (And when installing the package, dpkg would need to require installing
> it for every supported architecture; dpkg could refuse to configure the
> package if any enabled architecture doesn't have it unpacked.)
> 
> That would solve the problem for the couple of cases it has come up in,
> but it seems far from ideal; I'd welcome an cleaner alternative
> solution.  Notably, this doesn't work well for plugin packages for
> libraries less critical than glibc; it's not even ideal for PAM, as not
> every enabled architecture will have packages depending on libpam0g.
> The real dependency is "if any package on the architecture depends on
> package X, and package Y is installed, package Y:arch must be
> installed", but that's excessively complicated.

I don't think we can ever say there is a hard dependency here.
Instead of adding another Multi-Arch value, how about adding
'Recommends: Y:every' to Y?  (This also moves the problem up from dpkg
to APT.)

Ben.

> Any ideas on how to solve this problem?

-- 

Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.


signature.asc
Description: This is a digitally signed message part

Re: Handling Multi-Arch packages that must be installed for every enabled architecture?

[Josh Triplett]

On Sat, Jun 25, 2016 at 09:37:37AM +0200, Ben Hutchings wrote:
> On Fri, 2016-06-24 at 23:01 -0700, Josh Triplett wrote:
> > Some packages, if installed on any architecture, must be installed for
> > every enabled architecture.  Most notably, an NSS or PAM module package,
> > if enabled in /etc/nsswitch.conf or /etc/pam.d respectively, must exist
> > for every enabled architecture to avoid breaking programs for that
> > architecture.
> 
> What if I enable an architecture only for cross-building and don't
> intend to run programs from that architecture?

How much harm does it do to have (for instance) libnss-foo installed on
that architecture?  By comparison, how much harm does it do to *not*
have libnss-foo installed for an architecture but have it configured in
/etc/nsswitch.conf because you have libnss-foo installed for your main
system architecture?

> > As one possible solution for this problem (but not an ideal one, just a
> > thought experiment), dpkg could support a new value for "Multi-Arch",
> > "Multi-Arch: every".  This value would imply "Multi-Arch: same", but if
> > installed, would additionally cause dpkg to act the same way it does for
> > Essential packages: install the package when enabling the architecture.
> > (And when installing the package, dpkg would need to require installing
> > it for every supported architecture; dpkg could refuse to configure the
> > package if any enabled architecture doesn't have it unpacked.)
> > 
> > That would solve the problem for the couple of cases it has come up in,
> > but it seems far from ideal; I'd welcome an cleaner alternative
> > solution.  Notably, this doesn't work well for plugin packages for
> > libraries less critical than glibc; it's not even ideal for PAM, as not
> > every enabled architecture will have packages depending on libpam0g.
> > The real dependency is "if any package on the architecture depends on
> > package X, and package Y is installed, package Y:arch must be
> > installed", but that's excessively complicated.
> 
> I don't think we can ever say there is a hard dependency here.
> Instead of adding another Multi-Arch value, how about adding
> 'Recommends: Y:every' to Y?  (This also moves the problem up from dpkg
> to APT.)

Recommends doesn't seem like the appropriate dependency relationship for
a package required to run programs.  Choosing not to install Recommends
can produce suboptimal behavior, but "programs fail to run" seems
excessive for not installing a Recommends.

Y could "Depends: Y:every", though; that would solve the problem, and as
you said, raise it from dpkg to apt.  Not perfect, as you don't (for
instance) need libpam-foo:somearch installed unless you have
libpam0g:somearch installed, but better than breaking.

Seems like the ideal solution would be (assuming a new virtual package
"pam-module" that PAM module packages provided) some dependency field in
libpam0g like "Depends: pam-module:same-if-any".  That would act like
"Depends: pam-module:same-as-libpam0g" if the system had pam-module
installed for any architecture.  I don't know how much complexity that
would introduce, though.

- Josh Triplett

Re: Handling Multi-Arch packages that must be installed for every enabled architecture?

[Josh Triplett]

Sven Joachim wrote:
> On 2016-06-24 23:01 -0700, Josh Triplett wrote:
> > Some packages, if installed on any architecture, must be installed for
> > every enabled architecture.  Most notably, an NSS or PAM module package,
> > if enabled in /etc/nsswitch.conf or /etc/pam.d respectively, must exist
> > for every enabled architecture to avoid breaking programs for that
> > architecture.
> >
> > As one possible solution for this problem (but not an ideal one, just a
> > thought experiment), dpkg could support a new value for "Multi-Arch",
> > "Multi-Arch: every".  This value would imply "Multi-Arch: same", but if
> > installed, would additionally cause dpkg to act the same way it does for
> > Essential packages: install the package when enabling the architecture.
> 
> This is not at all what dpkg does, the Essential flag only means that
> dpkg will not remove the package in question, unless given the
> --force-remove-essential switch.

It's been a while since I'd set up "dpkg --add-architecture i386" on a new
system, so I'd misremembered.  I had thought that doing so (or subsequently
installing an i386 package) would force the installation of Essential packages
for i386 for any package that was "Multi-Arch: same".  Apparently not.

> > (And when installing the package, dpkg would need to require installing
> > it for every supported architecture; dpkg could refuse to configure the
> > package if any enabled architecture doesn't have it unpacked.)
> 
> One problem here is that dpkg does not even know which packages are
> available.  Another one: should "dpkg --add-architecture" automatically
> deconfigure any such "Multi-Arch: every" package?
> 
> I think such problems are better solved in apt: apt-get dist-upgrade
> already reinstalls every Essential package, the same way it could ensure
> that NSS or PAM modules are pulled in for every enabled architecture.

That sounds quite reasonable to me.  The question then becomes how apt
can know what packages it must install for every enabled architecture if
installed for any architecture.

- Josh Triplett

Re: Handling Multi-Arch packages that must be installed for every enabled architecture?

[Simon McVittie]

On Fri, 24 Jun 2016 at 23:01:21 -0700, Josh Triplett wrote:
> Some packages, if installed on any architecture, must be installed for
> every enabled architecture.  Most notably, an NSS or PAM module package,
> if enabled in /etc/nsswitch.conf or /etc/pam.d respectively, must exist
> for every enabled architecture to avoid breaking programs for that
> architecture.

This might well be true for PAM. For NSS, it used to be true, but based
on work I did on nss-mdns a while ago, I'm reasonably sure that was a
glibc bug that was later fixed. (See
.)

> As one possible solution for this problem (but not an ideal one, just a
> thought experiment), dpkg could support a new value for "Multi-Arch",
> "Multi-Arch: every".

A flag to indicate "keep this in sync across architectures" seems a
good idea, but I think this is perhaps a job for apt rather than dpkg
(and apt will need to understand it anyway). Using a separate field
would avoid the need to add the field to dpkg, wait for a new stable,
and only then start adding it to packages.

Perhaps something more like this? (I don't really like the field name,
but it's the best I could think of right now.)

Package: libpam-whatever
Multi-arch: same
Follow-architectures-of: libpam0g

which would mean: if you install libpam-whatever:amd64, you have
amd64, i386 and armhf architectures enabled in dpkg, and you have
libpam0g:amd64 and libpam0g:i386 but not libpam0g:armhf, then
libpam-whatever:i386 (only) is also automatically selected for
installation; and if you subsequently enable arm64 and install
libpam0g:arm64, then libpam-whatever:arm64 is also
automatically selected?

S

How to select an interpretor version?

[Victor Porton]

I have an interpreter name (say "Python") and an interval of versions (say 
"2.5 - 2.6").

Based on this data I need to select the python executable among installed 
files, if available.

The rule of the "game" is that I write a data file (preferably in RDF/Turtle 
format) which describes all available version of Python (and other 
interpreters).

My question is advice how to do it, in a practical way.

For example, if I understand correctly /usr/bin/python on some systems may 
mean Python 2.x and on some systems Python 3.x.

Is there any "standard" to avoid such multiple meanings of an executable 
located in the same path of the filesystem? In Debian, are there always more 
specific paths like /usr/bin/python2.7 or /usr/bin/python3.1?

Also, does it make sense to parse output of `dpkg -p`? or is it better to 
write RDF config files manually?

-- 
Victor Porton - http://portonvictor.org

Re: How to select an interpretor version?

[Geert Stappers]

On Sat, Jun 25, 2016 at 02:41:04PM +0300, Victor Porton wrote:
> I have an interpreter name (say "Python") and an interval of versions (say 
> "2.5 - 2.6").
> 
> Based on this data I need to select the python executable among installed 
> files, if available.

That "problem" is solved by '#!/usr/bin/env python'

> The rule of the "game" is that I write a data file (preferably in RDF/Turtle 
> format) which describes all available version of Python (and other 
> interpreters).

That seems like the (wrong??) mindset "I have problem, so I add something".


> My question is advice how to do it, in a practical way.
> 
> For example, if I understand correctly /usr/bin/python on some systems may 
> mean Python 2.x and on some systems Python 3.x.
> 
> Is there any "standard" to avoid such multiple meanings of an executable 
> located in the same path of the filesystem? In Debian, are there always more 
> specific paths like /usr/bin/python2.7 or /usr/bin/python3.1?
> 
> Also, does it make sense to parse output of `dpkg -p`? or is it better to 
> write RDF config files manually?



I think the original poster needs to elaborate the "problem"


Regards
Geert Stappers

P.S.  it is interpreter
-- 
Leven en laten leven

Re: Bug#727169: RFP: lua-stdlib -- Standard Lua libraries

[Sergio Durigan Junior]

Control: retitle -1 ITP: lua-stdlib -- Standard Lua libraries
Control: owner -1 !

On Tuesday, October 22 2013, Axel Beckert wrote:

> * Package name: lua-stdlib
>   Version : v35
>   Upstream Author : Reuben Thomas et al.
> * URL or Web page : https://github.com/rrthomas/lua-stdlib
> * License : MIT
>   Description : Standard Lua libraries
>
> Upstream description:
>
>   This is a collection of Lua libraries for Lua 5.1 and 5.2. The
>   libraries are copyright by their authors 2000-2013 (see the AUTHORS
>   file for details), and released under the MIT license (the same
>   license as Lua itself). There is no warranty.
>
>   Stdlib has no prerequisites beyond a standard Lua system.
>
> I maintain GNU Zile in Debian. Upstream currently works on a
> reimplementation of Zile in Lua which seems to become "Zile 3".
>
> This library seems to be a dependency for that rewrite.

I am taking care of this package.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Re: Neomutt packages available

[Geert Stappers]

On Fri, Jun 24, 2016 at 11:19:33PM +0200, Alexander Wirt wrote:
> On Fri, 24 Jun 2016, Elimar Riesebieter wrote:
> > * Jonathan Dowland  [2016-06-24 09:24 +0100]:
> > > On Thu, Jun 23, 2016 at 09:10:50PM +0200, Elimar Riesebieter wrote:
> > > > 
> > > > I've packaged neomutt for Debian. A Debian ITP [2] is filed.
> > > > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825821
> > > 
> > > For those on -devel not up to speed on what is going on (such as me) the
> > > ITP makes interesting reading.
> > > 
> > > The existing mutt maintainers have a considered plan to move to neomutt
> > > for the existing mutt packages (at least mutt-patched and quite likely
> > > mutt itself).
> > 
> > This I am not aware of. I never noticed such a consideration. AFAIK
> > mutt maintainers are in contact to neomutt upstream, but thats it.
> https://lists.debian.org/msgid-search/20160530191157.ga21...@nana.phantasia.die-welt.net
with a CC to the ITP bug report 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825821#55
it says, among other: 
| The current plan is to replace Debian's mutt-patched patchset with neomutt. 
[1]
| Maybe even s/mutt/neomutt/ at some point.
| 
| [1] https://github.com/neomutt/neomutt/issues/23

Elimar,

Where you have the skill to package software,
please show the world that you have the skill to work together with people.


pkg-mutt,

There is a new kid on the block. Where I think that his entrance could/should
have been better, I still ask for a way to get along.


Groeten
Geert Stappers

Who personally thinks that Elimar is to egar to have his own package in Debian.
Yes, I could be wrong about that. So please prove me wrong. Other things to
avoid a fight over who packaged what, is also preferred.
-- 
Leven en laten leven


signature.asc
Description: Digital signature

Re: Handling Multi-Arch packages that must be installed for every enabled architecture?

[David Kalnischkies]

On Sat, Jun 25, 2016 at 02:01:27AM -0700, Josh Triplett wrote:
> Sven Joachim wrote:
> > On 2016-06-24 23:01 -0700, Josh Triplett wrote:
> > > Some packages, if installed on any architecture, must be installed for
> > > every enabled architecture.  Most notably, an NSS or PAM module package,
> > > if enabled in /etc/nsswitch.conf or /etc/pam.d respectively, must exist
> > > for every enabled architecture to avoid breaking programs for that
> > > architecture.

See https://wiki.debian.org/HelmutGrohne/MultiarchSpecChanges (and
links) for more examples, potential solutions and problems/shortcomings
from each of them.

So, as usual, what looks like a simple and easy thing is actually
a complexity monster eating little kids^W DDs for breakfast.

(That isn't to say stop all discussion… this discussion died down and in
case we still need a solution it should 'just' be resumed from the last
good state rather than from zero)

> > > As one possible solution for this problem (but not an ideal one, just a
> > > thought experiment), dpkg could support a new value for "Multi-Arch",
> > > "Multi-Arch: every".  This value would imply "Multi-Arch: same", but if
> > > installed, would additionally cause dpkg to act the same way it does for
> > > Essential packages: install the package when enabling the architecture.
> > 
> > This is not at all what dpkg does, the Essential flag only means that
> > dpkg will not remove the package in question, unless given the
> > --force-remove-essential switch.
> 
> It's been a while since I'd set up "dpkg --add-architecture i386" on a new
> system, so I'd misremembered.  I had thought that doing so (or subsequently
> installing an i386 package) would force the installation of Essential packages
> for i386 for any package that was "Multi-Arch: same".  Apparently not.

Nitpick, but there are no essential M-A:same packages (first, because
libraries are forbidden from being essential and M-A:same applies mostly
only to them and second, a package tends to be essential because it
ships an architecture-independent commandline interface – hence most of
them are M-A:foreign – so important that noone can be bothered to depend
on it).


> > > (And when installing the package, dpkg would need to require
> > > it for every supported architecture; dpkg could refuse to configure the
> > > package if any enabled architecture doesn't have it unpacked.)
> > 
> > One problem here is that dpkg does not even know which packages are
> > available. […]

Another nitpick, but dpkg does know (to a certain extend). That isn't
all to important in the suggested case here as if you would model it as
a hard-requirement as suggested here with configure-refusal or later
with an automatic deconfiguration the package would need to exist for
all architectures anyhow as if you allow it to be not available for one
it isn't a hard-requirement anymore, but a magical recommends depending
on which sources a user has currently configured (and happend to be
successful in downloading).

Such a requirement also prevents packages from adding/removing
architectures (probably very very uncommon) and makes the interaction
all around pretty strange: I add a new architecture via dpkg and
instantly ever package manager screams at me that my system is broken.
But that is already written in the wiki…


> > I think such problems are better solved in apt: apt-get dist-upgrade
> > already reinstalls every Essential package, the same way it could ensure
> 
> That sounds quite reasonable to me.  The question then becomes how apt

It does to you and me perhaps, but apts handling of essentials (which
aptitude has copied and extended to prio:required in recent versions) is
the source of constant complains.

With every magic implemented in apt it should also be considered what
that means for all non-src:apt package managers be them libapt-based or
not as for better or worse apt(-get) is by far not the only thing
dealing with packages.


For Multi-Arch itself I managed to hide away most of it behind implicit
dependency relations, versioned provides and 'strange' virtual packages
for the libapt-based ones which made that transition quite "easy" all
things considered, but we can't pretend it will always be that "easy"…


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Re: How to select an interpretor version?

[Victor Porton]

Geert Stappers, you have misunderstood my problem.

I want to support ALL interpreters available in Debian (Perl, Python, Ruby, 
Java, etc.)

I need to make supporting all interpreters and all their versions 
manageable. My question is how to support it all, specifically when a user 
explicitly specifies a version range.

Input:

- name of programming language

- the range of versions of the programming language

- the location of a script in this language

Output:

- the command line to run the script

Note that if several version match, I'd prefer to use the latest matching 
version.

Geert Stappers wrote:
> On Sat, Jun 25, 2016 at 02:41:04PM +0300, Victor Porton wrote:
>> I have an interpreter name (say "Python") and an interval of versions
>> (say "2.5 - 2.6").
>> 
>> Based on this data I need to select the python executable among installed
>> files, if available.
> 
> That "problem" is solved by '#!/usr/bin/env python'
> 
>> The rule of the "game" is that I write a data file (preferably in
>> RDF/Turtle format) which describes all available version of Python (and
>> other interpreters).
> 
> That seems like the (wrong??) mindset "I have problem, so I add
> something".
> 
> 
>> My question is advice how to do it, in a practical way.
>> 
>> For example, if I understand correctly /usr/bin/python on some systems
>> may mean Python 2.x and on some systems Python 3.x.
>> 
>> Is there any "standard" to avoid such multiple meanings of an executable
>> located in the same path of the filesystem? In Debian, are there always
>> more specific paths like /usr/bin/python2.7 or /usr/bin/python3.1?
>> 
>> Also, does it make sense to parse output of `dpkg -p`? or is it better to
>> write RDF config files manually?
> 
> 
> 
> I think the original poster needs to elaborate the "problem"
> 
> 
> Regards
> Geert Stappers
> 
> P.S.  it is interpreter

-- 
Victor Porton - http://portonvictor.org

Re: How to select an interpretor version?

[Geert Stappers]

On Sat, Jun 25, 2016 at 06:44:35PM +0300, Victor Porton wrote:
> Geert Stappers wrote:
> > On Sat, Jun 25, 2016 at 02:41:04PM +0300, Victor Porton wrote:
> > > I have an interpreter name (say "Python") and an interval of versions

... 28 lines from previous posting ( not previous discussion ) ...

> > 
> > I think the original poster needs to elaborate the "problem"
> > 
> 
> Geert Stappers, you have misunderstood my problem.

:-)


> I want to support ALL interpreters available in Debian (Perl, Python, Ruby, 
> Java, etc.)
> 
> I need to make supporting all interpreters and all their versions 
> manageable. My question is how to support it all, specifically when a user 
> explicitly specifies a version range.
> 
> Input:
> 
> - name of programming language
> 
> - the range of versions of the programming language
> 
> - the location of a script in this language
> 
> Output:
> 
> - the command line to run the script
> 
> Note that if several version match, I'd prefer to use the latest matching 
> version.


Repeating what it is wanted  is not the same as explaining what is wanted.



> > Regards
> > Geert Stappers
> > 
> > P.S.  it is interpreter
> 

https://en.wikipedia.org/wiki/Interpreter_%28computing%29

In other words: Change 'interpretor' in the Subject into 'interpreter'


Groeten
Geert Stappers
-- 
Leven en laten leven


signature.asc
Description: Digital signature

Re: Handling Multi-Arch packages that must be installed for every enabled architecture?

[Ian Jackson]

Josh Triplett writes ("Handling Multi-Arch packages that must be installed for 
every enabled architecture?"):
> That would solve the problem for the couple of cases it has come up in,
> but it seems far from ideal; I'd welcome an cleaner alternative
> solution.  Notably, this doesn't work well for plugin packages for
> libraries less critical than glibc; it's not even ideal for PAM, as not
> every enabled architecture will have packages depending on libpam0g.
> The real dependency is "if any package on the architecture depends on
> package X, and package Y is installed, package Y:arch must be
> installed", but that's excessively complicated.
> 
> Any ideas on how to solve this problem?

I don't have really good suggestions, but I wanted to mention two
additional problems which are very nearby:

* LD_PRELOAD hacks need their .so installing for all architecture "for
  which they are going to be used" (whatever that means)

* The language plugin problem.

Ian.

Re: How to select an interpretor version?

[Ian Jackson]

Victor Porton writes ("Re: How to select an interpretor version?"):
> Geert Stappers, you have misunderstood my problem.
> 
> I want to support ALL interpreters available in Debian (Perl, Python, Ruby, 
> Java, etc.)
> 
> I need to make supporting all interpreters and all their versions 
> manageable. My question is how to support it all, specifically when a user 
> explicitly specifies a version range.
> 
> Input:
> 
> - name of programming language
> 
> - the range of versions of the programming language
> 
> - the location of a script in this language
> 
> Output:
> 
> - the command line to run the script

Like Geert, I don't understand why you want this.  Obviously I have
some wrong model of your situation.   (Which is quite likely, because
you haven't really explained it.)

Can you tell us the underlying real problem that you hope your utility
is going to solve ?  By `tell us the underlying real problem', I mean
to ask for what in engineering is called a Solution Neutral Problem
Statement.

Ian.

Re: Handling Multi-Arch packages that must be installed for every enabled architecture?

[Josh Triplett]

On Sat, Jun 25, 2016 at 07:08:39PM +0100, Ian Jackson wrote:
> Josh Triplett writes ("Handling Multi-Arch packages that must be installed 
> for every enabled architecture?"):
> > That would solve the problem for the couple of cases it has come up in,
> > but it seems far from ideal; I'd welcome an cleaner alternative
> > solution.  Notably, this doesn't work well for plugin packages for
> > libraries less critical than glibc; it's not even ideal for PAM, as not
> > every enabled architecture will have packages depending on libpam0g.
> > The real dependency is "if any package on the architecture depends on
> > package X, and package Y is installed, package Y:arch must be
> > installed", but that's excessively complicated.
> > 
> > Any ideas on how to solve this problem?
> 
> I don't have really good suggestions, but I wanted to mention two
> additional problems which are very nearby:
> 
> * LD_PRELOAD hacks need their .so installing for all architecture "for
>   which they are going to be used" (whatever that means)

Such as fakeroot and fakechroot?

> * The language plugin problem.

Can you elaborate on this?  Do you mean languages that have native-code
plugins?

- Josh Triplett

Bug#828176: ITP: cnvkit -- Copy number variant detection from targeted DNA sequencing

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: cnvkit
  Version : 0.7.11
  Upstream Author : Eric Talevich 
* URL : http://cnvkit.readthedocs.io/
* License : Apache-2.0
  Programming Lang: Python
  Description : Copy number variant detection from targeted DNA sequencing

A command-line toolkit and Python library for detecting copy number variants
and alterations genome-wide from targeted DNA sequencing. It is designed for
use with hybrid capture, including both whole-exome and custom target panels,
and short-read sequencing platforms such as Illumina and Ion Torrent.

Will be team maintained by the Debian Med team

Re: Handling Multi-Arch packages that must be installed for every enabled architecture?

[Josh Triplett]

Simon McVittie wrote:
> On Fri, 24 Jun 2016 at 23:01:21 -0700, Josh Triplett wrote:
> > Some packages, if installed on any architecture, must be installed for
> > every enabled architecture.  Most notably, an NSS or PAM module package,
> > if enabled in /etc/nsswitch.conf or /etc/pam.d respectively, must exist
> > for every enabled architecture to avoid breaking programs for that
> > architecture.
>
> This might well be true for PAM. For NSS, it used to be true, but based
> on work I did on nss-mdns a while ago, I'm reasonably sure that was a
> glibc bug that was later fixed. (See
> .)

Glad to hear that the NSS case has gotten a bit better.  But that still
means applications for an architecture without the configured NSS module
installed can't resolve names in the expected way.  Effectively, any NSS
module not shipped with glibc won't work reliably across all
applications without a solution to this problem.

> > As one possible solution for this problem (but not an ideal one, just a
> > thought experiment), dpkg could support a new value for "Multi-Arch",
> > "Multi-Arch: every".
> 
> A flag to indicate "keep this in sync across architectures" seems a
> good idea, but I think this is perhaps a job for apt rather than dpkg
> (and apt will need to understand it anyway). Using a separate field
> would avoid the need to add the field to dpkg, wait for a new stable,
> and only then start adding it to packages.

Good point; if dpkg and apt will both ignore any field they don't
understand, then this doesn't need to wait for a stable cycle.

> Perhaps something more like this? (I don't really like the field name,
> but it's the best I could think of right now.)
> 
> Package: libpam-whatever
> Multi-arch: same
> Follow-architectures-of: libpam0g
>
> which would mean: if you install libpam-whatever:amd64, you have
> amd64, i386 and armhf architectures enabled in dpkg, and you have
> libpam0g:amd64 and libpam0g:i386 but not libpam0g:armhf, then
> libpam-whatever:i386 (only) is also automatically selected for
> installation; and if you subsequently enable arm64 and install
> libpam0g:arm64, then libpam-whatever:arm64 is also
> automatically selected?

That sounds perfect.

NSS modules would then "Follow-Arch-Of: libc6".  And PAM modules would
"Follow-Arch-Of: libpam0g".

Looking at the link provided elsewhere in the thread, this looks similar
to the "Install-Same-As" header suggested on
https://wiki.debian.org/HelmutGrohne/MultiarchSpecChanges .  Of the
proposals on that page, this seems like the most viable.

- Josh Triplett

Re: Handling Multi-Arch packages that must be installed for every enabled architecture?

[Ian Jackson]

Josh Triplett writes ("Re: Handling Multi-Arch packages that must be installed 
for every enabled architecture?"):
> On Sat, Jun 25, 2016 at 07:08:39PM +0100, Ian Jackson wrote:
> > * LD_PRELOAD hacks need their .so installing for all architecture "for
> >   which they are going to be used" (whatever that means)
> 
> Such as fakeroot and fakechroot?

Right, faketime too.  I maintain one: authbind.

> > * The language plugin problem.
> 
> Can you elaborate on this?  Do you mean languages that have native-code
> plugins?

Yes.

Example:

sauce [all] contains pure Tcl code.

It has a #! line naming a specific Tcl interpreter (let's say 8.5, for
now).  So it Depends tcl8.5 (or whatever).  tcl8.5 is (or should be)
M-A foreign.  It contains the Tcl script interpreter executable.

sauce uses adns to do its primary DNS queries.  This is done via a Tcl
plugin in the chiark-tcl package.  sauce loads this with the Tcl
"load" builtin, which loads a named shared object from the library
search path and calls a specific init function.

So sauce Depends libtcl-chiark-1.

libtcl-chiark-1 is Arch: any.  It contains only shared objects.  It
needs to be coinstallable.  It should be M-A: same.

Somehow we need to arrange that if sauce:all's dependency on tcl8.5
is satisfied by tcl8.5:X, and libtcl-chiark-1:X is installed.

Ian.

Re: Handling Multi-Arch packages that must be installed for every enabled architecture?

[Josh Triplett]

David Kalnischkies wrote:
> On Sat, Jun 25, 2016 at 02:01:27AM -0700, Josh Triplett wrote:
> > Sven Joachim wrote:
> > > On 2016-06-24 23:01 -0700, Josh Triplett wrote:
> > > > Some packages, if installed on any architecture, must be installed for
> > > > every enabled architecture.  Most notably, an NSS or PAM module package,
> > > > if enabled in /etc/nsswitch.conf or /etc/pam.d respectively, must exist
> > > > for every enabled architecture to avoid breaking programs for that
> > > > architecture.
> 
> See https://wiki.debian.org/HelmutGrohne/MultiarchSpecChanges (and
> links) for more examples, potential solutions and problems/shortcomings
> from each of them.

The "Install-Same-As" header on that page looks ideal for this case.

The bootstrap issue would certainly need a solution, but it doesn't seem
too hard to have an option/configuration to ignore such dependencies.
Someone installing a specialized build chroot might want that options as
well.  For instance, a build chroot could install an
/etc/apt/apt.conf.d/* file containing:

Ignore-Install-Same-As: libc6, libpam0g

I think that largely addresses the other cons as well.

Do you know if anyone has looked into what it would take to implement
Install-Same-As in apt?

- Josh Triplett

Re: How to select an interpretor version?

[Victor Porton]

Ian Jackson wrote:

> Victor Porton writes ("Re: How to select an interpretor version?"):
>> Geert Stappers, you have misunderstood my problem.
>> 
>> I want to support ALL interpreters available in Debian (Perl, Python,
>> Ruby, Java, etc.)
>> 
>> I need to make supporting all interpreters and all their versions
>> manageable. My question is how to support it all, specifically when a
>> user explicitly specifies a version range.
>> 
>> Input:
>> 
>> - name of programming language
>> 
>> - the range of versions of the programming language
>> 
>> - the location of a script in this language
>> 
>> Output:
>> 
>> - the command line to run the script
> 
> Like Geert, I don't understand why you want this.  Obviously I have
> some wrong model of your situation.   (Which is quite likely, because
> you haven't really explained it.)
> 
> Can you tell us the underlying real problem that you hope your utility
> is going to solve ?  By `tell us the underlying real problem', I mean
> to ask for what in engineering is called a Solution Neutral Problem
> Statement.

I am going to write a program which automatically converts between XML 
formats using scripts described by RDF resources located at namespace URLs 
(not a precise description of my project, but you've got the taste).

The formal specification of my project:

https://en.wikiversity.org/wiki/Automatic_transformation_of_XML_namespaces

I am going to run scripts in Firejail (or another sandbox), in other that a 
hacker not to be able to harm the server at which my program would run.

-- 
Victor Porton - http://portonvictor.org

Bug#828184: ITP: r-cran-r.cache -- R package: Fast and Light-Weight Caching of Objects and Results

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: r-cran-r.cache
  Version : 0.12.0
  Upstream Author : Henrik Bengtsson 
* URL : https://github.com/HenrikBengtsson/R.cache
* License : LGPL (>= 2.1)
  Programming Lang: R
  Description : R package: Fast and Light-Weight Caching of Objects and 
Results

Memoization can be used to speed up repetitive and computational expensive
function calls.  The first time a function that implements memoization is
called the results are stored in a cache memory.  The next time the function is
called with the same set of parameters, the results are momentarily retrieved
from the cache avoiding repeating the calculations.  With this package, any R
object can be cached in a key-value storage where the key can be an arbitrary
set of R objects.  The cache memory is persistent (on the file system).

Dependency of r-cran-pscbs, will be team maintained by the Debian Med team

Bug#828189: ITP: r-bioc-dnacopy -- R package: DNA copy number data analysis

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: r-bioc-dnacopy
  Version : 1.46.0
  Upstream Author : Venkatraman E. Seshan 
* URL : 
http://www.bioconductor.org/packages/release/bioc/html/DNAcopy.html
* License : GPL-2.0+
  Programming Lang: R
  Description : R package: DNA copy number data analysis

 Implements the circular binary segmentation (CBS) algorithm to segment DNA
 copy number data and identify genomic regions with abnormal copy number.
 .
 This package is for analyzing array DNA copy number data, which is usually
 (but not always) called array Comparative Genomic Hybridization (array CGH)
 data It implements a methodology for finding change-points in these data which
 are points after which the (log) test over reference ratios have changed
 location. This model is that the change-points correspond to positions where
 the underlying DNA copy number has changed. Therefore, change-points can be
 used to identify regions of gained and lost copy number. We also provide a
 function for making relevant plots of these data.

This is a dependency for r-cran-pscbs and will be team maintained by the Debian 
Med team

Re: How to select an interpretor version?

[Ian Jackson]

Victor Porton writes ("Re: How to select an interpretor version?"):
> I am going to write a program which automatically converts between XML 
> formats using scripts described by RDF resources located at namespace URLs 
> (not a precise description of my project, but you've got the taste).
> 
> The formal specification of my project:
> 
> https://en.wikiversity.org/wiki/Automatic_transformation_of_XML_namespaces

Thanks for the info!  That all sounds very exciting.
Although, I confess I don't quite understand everything there.

> I am going to run scripts in Firejail (or another sandbox), in other that a 
> hacker not to be able to harm the server at which my program would run.

That sounds like it might be a good idea.  Where do these scripts come
from ?  Is it these scripts for which you are tryiung to automatically
identify a suitable interpreter ?

Regards,
Ian.

Re: How to select an interpretor version?

[Victor Porton]

On Sat, 2016-06-25 at 23:54 +0100, Ian Jackson wrote:
> Victor Porton writes ("Re: How to select an interpretor version?"):
> > I am going to write a program which automatically converts between
> > XML 
> > formats using scripts described by RDF resources located at
> > namespace URLs 
> > (not a precise description of my project, but you've got the
> > taste).
> > 
> > The formal specification of my project:
> > 
> > https://en.wikiversity.org/wiki/Automatic_transformation_of_XML_nam
> > espaces
> 
> Thanks for the info!  That all sounds very exciting.
> Although, I confess I don't quite understand everything there.
> 
> > I am going to run scripts in Firejail (or another sandbox), in
> > other that a 
> > hacker not to be able to harm the server at which my program would
> > run.
> 
> That sounds like it might be a good idea.  Where do these scripts
> come
> from ?  Is it these scripts for which you are tryiung to
> automatically
> identify a suitable interpreter ?
Accordingly my plan:
- XML developers should put a description (in RDF format) of their
namespaces at XML namespace URLs.
- The RDF files may refer to scripts (a script may be located at any
URL on the Web) which (among other things) can transform from one XML
namespace to another XML namespace. When the RDF refers to a script,
among the script URL, the scripting language (such as "Python") is
pointed in aforementioned RDF file (additionally the RDF file may
contain an interval of versions, to restrict for example to Python 2
and not 3).
- My software may use these scripts.
This way my software is to run (at a say Debian Linux server) scripts
downloaded from the Web. They are run in a jail.
The script URL, programming language, and version interval are
downloaded from the Web. After this, my software should decide which
interpreter (/usr/bin/python, /usr/bin/ruby, /usr/bin/java, etc.) to
use, download the script and run it in a jail. The script may convert
from one format to another. Or it may check data validity.

Bug#828194: ITP: r-cran-listenv -- R package: Environments Behaving (Almost) as Lists

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: r-cran-listenv
  Version : 0.6.0
  Upstream Author : Henrik Bengtsson 
* URL : https://github.com/HenrikBengtsson/listenv
* License : LGPL 2.1+
  Programming Lang: R
  Description : R package: Environments Behaving (Almost) as Lists

List environments are environments that have list-like properties. For
 instance, the elements of a list environment are ordered and can be accessed
 and iterated over using index subsetting, e.g. 'x <- listenv(a=1, b=2); for (i
 in seq_along(x)) x[[i]] <- x[[i]]^2; y <- as.list(x)'.

A dependency of r-cran-pscbs, will be team maintained by Debian Med.

Bug#828196: ITP: r-cran-globals -- R package: Identify Global Objects in R Expressions

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: r-cran-globals
  Version : 0.6.1
  Upstream Author : Henrik Bengtsson 
* URL : https://github.com/HenrikBengtsson/globals
* License : LGPL-2.1+
  Programming Lang: R
  Description : R package: Identify Global Objects in R Expressions

 Identifies global ("unknown") objects in R expressions by code inspection
 using various strategies, e.g. conservative or liberal. The objective of this
 package is to make it as simple as possible to identify global objects for the
 purpose of exporting them in distributed compute environments.

Dependency of r-cran-future, will be team maintained by Debian Med

Bug#828197: ITP: r-cran-future -- R package: A Future API for R

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: r-cran-future
  Version : 1.0.0
  Upstream Author : Henrik Bengtsson 
* URL : https://github.com/HenrikBengtsson/future
* License : LGPL-2.1+
  Programming Lang: R
  Description : R package: A Future API for R

In programming, a future is an abstraction for a value that may be available
 at some point in the future. The state of a future can either be unresolved or
 resolved. As soon as it is resolved, the value is available. Futures are
 useful constructs in for instance concurrent evaluation, e.g. parallel
 processing and distributed processing on compute clusters. The purpose of this
 package is to provide a lightweight interface for using futures in R.

A dependency of r-cran-pscbs, team maintained by Debian Med

Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)

[Tollef Fog Heen]

]] Holger Levsen 

> On Wed, Jun 22, 2016 at 08:13:40AM +, Eliran Mesika wrote:
> > As I wrote earlier, we're open to making certain features available upon
> > request. In the specific case of the feature that was discussed - could you
> > please elaborate what is missing and what functionality is available on the
> > Enterprise edition that you'd like to be made public? We want to better
> > understand the use-case and the requirements to respond to this request.
> 
> I'm obviously not Alex but I also object using a software for Debian's
> own infrastructure which is split into a free and an enterprise version.

Do you also object to DSA using puppet for configuration management?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are