Bug#941726: ITP: packmol -- Initial configurations for Molecular Dynamics Simulations by packing optimization

[Drew Parsons]

Package: wnpp
Severity: wishlist
Owner: Drew Parsons 

* Package name: packmol
  Version : 18.169
  Upstream Author : Leandro Martínez, José Mario Martínez, Ernesto Birgin
* URL : http://m3g.iqm.unicamp.br/packmol/
* License : MIT
  Programming Lang: fortran90
  Description : Initial configurations for Molecular Dynamics Simulations 
by packing optimization

Packmol creates an initial point for molecular dynamics simulations by
packing molecules in defined regions of space. The packing guarantees
that short range repulsive interactions do not disrupt the
simulations.

The great variety of types of spatial constraints that can be
attributed to the molecules, or atoms within the molecules, makes it
easy to create ordered systems, such as lamellar, spherical or tubular
lipid layers.

The user must provide only the coordinates of one molecule of each
type, the number of molecules of each type and the spatial constraints
that each type of molecule must satisfy.

The package is compatible with input files of PDB, TINKER, XYZ and
MOLDY formats.

See http://m3g.iqm.unicamp.br/packmol for more information.

References

Please always cite one of the following references in publications for
which Packmol was useful:

L Martinez, R Andrade, EG Birgin, JM Martinez, Packmol: A package for
building initial configurations for molecular dynamics simulations.
Journal of Computational Chemistry, 30, 2157-2164, 2009.
(http://www3.interscience.wiley.com/journal/122210103/abstract)

JM Martinez, L Martinez, Packing optimization for the automated
generation of complex system's initial configurations for molecular
dynamics and docking. Journal of Computational Chemistry, 24, 819-825,
2003. (http://www3.interscience.wiley.com/journal/104086246/abstract)



This package complements existing molecular dynamics software such as
lammps, gromacs, cp2k and others, providing tools for filling a volume
with solvent molecules.

This area of application is more specialised and therefore the package
can be team-maintained under debichem rather than debian-science.

Drew

Bug#941732: ITP: golang-github-jzelinskie-whirlpool -- whirlpool cryptographic hashing library

[Dr. Tobias Quathamer]

Package: wnpp
Severity: wishlist
Owner: Dr. Tobias Quathamer 

* Package name: golang-github-jzelinskie-whirlpool
  Version : 0.0~git20170603.c19460b-1
  Upstream Author : Jimmy Zelinskie
* URL : https://github.com/jzelinskie/whirlpool
* License : BSD-3-clause
  Programming Lang: Go
  Description : whirlpool cryptographic hashing library
 This package implements the whirlpool hashing library for go.


The package is needed for the new upstream version of rclone.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#941736: ITP: golang-github-putdotio-go-putio -- Put.io Go API client

[Dr. Tobias Quathamer]

Package: wnpp
Severity: wishlist
Owner: Dr. Tobias Quathamer 

* Package name: golang-github-putdotio-go-putio
  Version : 0.0~git20190822.19b9c63-1
  Upstream Author : H. İbrahim Güngör
* URL : https://github.com/putdotio/go-putio
* License : Expat
  Programming Lang: Go
  Description : Put.io Go API client
 Putio is a Go client library for accessing the Put.io API v2.


This package is needed for the new upstream version of rclone.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Re: Debian and our frenemies of containers and userland repos

[Enrico Weigelt, metux IT consult]

On 24.07.19 08:17, Marc Haber wrote:

> Do we have a build technology that uses containers instead of chroots
> yet?

Something like docker-buildpackage ?


--mtx


-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Re: virtualbox, backports, and fasttrack

[Pirate Praveen]

On Wed, Oct 2, 2019 at 23:23, Bernd Zeimetz  wrote:

Hi Lucaus,


 Given that backports are a no-go, I hope that
  will make quick progress and turn 
into an

 official service soon.


basically a good idea, but


I'm part of the Fast Track team and I'll try to answer your questions.



- what are your requirements for packages that are being uploaded 
there?


buster-fasttrack suite:

If a package cannot be part of a stable release because we cannot 
provide security updates for the entire stable lifecylce then that 
package cannot be in testing or backports. Those packages get security 
updates along with new upstream versions and such software can be in 
FastTrack.


buster-backports suite:

We also allow dependencies of packages in fasttrack to be updated from 
experimental during special cases like freeze, transitions or for new 
security update (backport-new can take some time). In the normal 
course, they should be uploaded to official backports since they 
qualify for backports.


You can see the original proposal that explains things in detail.

https://lists.debian.org/debian-devel/2018/12/msg00297.html

- how do you want to avoid that this service becomes a mess? who 
removes

packages when, who makes sure maintainers actually take care of what
they upload? how are bugs being reported? What about security issues?



We have not really thought about removals yet (probably we have not 
reached that stage yet as we only have one package there ie, gitlab and 
it is maintained well.). But we could follow the same rules as testing 
and backports (except for the meta rc bug that is present only to 
prevent testing migration).


Secutity issues are fixed by uploading new upstream releases.


Thanks,

Bernd


--
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.de 
http://www.debian.org 

 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Rethinking tensorflow build (taking shortcuts)

[Mo Zhou]

Hi -devel,

The only officially supported build system for Tensorflow is
bazel[1], which is not present in our archive due to some reasons.
A possible solution to build tensorflow for Debian in
forward-engineering style is to write an alternative build system
to approximate the original build system. It is difficult because
the structure and build process for the 4.5 million lines of code
is quite complex. It's also hard to keep the proximity between
the resulting binaries and the official binary releases.

Another angle for addressing the building problem is in the
reverse-engineering style: parse the bazel buildlog, rebuild the
dependency graph and generate a ninja build for it. See [2].

Building tensorflow in this way could significantly reduce
the discrepancy between resulting binaries and official binaries,
because such a build basically replays the original build sequence.
So the resulting shared objects are expected to be good enough.

Currently the following shared objects can be built along the
described way:
 * libtensorflow_framework.so (fundamental)
 * libtensorflow.so (C)
 * libtensorflow_cc.so (C++)
They are almost identical to the official binary, except for some
manually removed parts.

Building the python package is a little bit more complex, but
parsing buildlogs is supposed to be simple enough for me to
proceed.

Far better than the two previous uploads. The old build system
builds imprecise shared objects.

[1] https://bazel.build/
[2]
https://salsa.debian.org/science-team/tensorflow/blob/lumin/debian/fakebazel.py
[3] https://salsa.debian.org/science-team/tensorflow/tree/lumin/

Re: Debian and our frenemies of containers and userland repos

[Jose-Luis Rivas]

On 10/4/19 10:49, Enrico Weigelt, metux IT consult wrote:
> On 24.07.19 08:17, Marc Haber wrote:
> 
>> Do we have a build technology that uses containers instead of chroots
>> yet?
> 
> Something like docker-buildpackage ?
> 

For this purpose I built deb-build-pkg which is a pretty
straight-forward way to build debian packages, it's a simple bash script
that only requires bash and docker in your system in order to build the
packages.

https://github.com/resnullius/deb-build-pkg/blob/master/deb-build-pkg

-- 

   __.https://wiki.debian.org/JoseLuisRivas
___'/___  rsa4096/D278F9C15E5461AA3C1E2FCD13EC43EEB9AC8C43

Re: Rethinking tensorflow build (taking shortcuts)

[Samuel Thibault]

Hello,

Mo Zhou, le ven. 04 oct. 2019 09:04:25 -0700, a ecrit:
> Another angle for addressing the building problem is in the
> reverse-engineering style: parse the bazel buildlog, rebuild the
> dependency graph and generate a ninja build for it. See [2].

Interesting :) But then if one wants to add some files to the software,
which changes the dependencies, are we able to insert it correctly in
the build process? Being able to change the set of files to be built is
part of being able to modify the software, for it to be free :/

Samuel

Re: Rethinking tensorflow build (taking shortcuts)

[Enrico Zini]

On Fri, Oct 04, 2019 at 06:25:21PM +0200, Samuel Thibault wrote:

> Interesting :) But then if one wants to add some files to the software,
> which changes the dependencies, are we able to insert it correctly in
> the build process? Being able to change the set of files to be built is
> part of being able to modify the software, for it to be free :/

My understanding is that the preferred source of modification will still
be shipped, only with the addition of the preprocessed build
instructions, to remove the need free software that is not in Debian.

If someone wants to add things to the software that change the
dependency, I understand, one can regenerate the build trace with the
build system that upstream uses (which is free software), and things
keep working.

Unless I misuinderstood something, I quite like this shortcut :)


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Rethinking tensorflow build (taking shortcuts)

[Mo Zhou]

On 2019-10-04 16:25, Samuel Thibault wrote:
> Hello,
> 
> Mo Zhou, le ven. 04 oct. 2019 09:04:25 -0700, a ecrit:
>> Another angle for addressing the building problem is in the
>> reverse-engineering style: parse the bazel buildlog, rebuild the
>> dependency graph and generate a ninja build for it. See [2].
> 
> Interesting :) But then if one wants to add some files to the software,
> which changes the dependencies, are we able to insert it correctly in
> the build process? Being able to change the set of files to be built is
> part of being able to modify the software, for it to be free :/

Minor modifications won't be too difficult. For example the object list
for building libtensorflow.so is explicitly listed here[1]. During build
the object list is passed to compiler via
-Wl,@libtensorflow...params
I did manually edit the object list to customize the shared object, and
the changes will be reflected in the dependency graph[2].
(FYI: ninja writer's "implicit" argument stores dependencies)

On the other hand, ff the user wants significantly different stuff,
they have to re-generate a buildlog and update the parser accordingly.

Not bad, right?

[1]
https://salsa.debian.org/science-team/tensorflow/blob/lumin/debian/buildlogs/libtensorflow.so.2.0.0-2.params
[2]
https://salsa.debian.org/science-team/tensorflow/blob/lumin/debian/fakebazel.py#L413-417

Re: Maintainer/home wanted for DDE (Debian Data Export / dde.debian.net)

[lalusudiarto.bakers09]

Dikirim dari ponsel cerdas Samsung Galaxy saya.

Re: Rethinking tensorflow build (taking shortcuts)

[Samuel Thibault]

Enrico Zini, le ven. 04 oct. 2019 18:33:44 +0200, a ecrit:
> On Fri, Oct 04, 2019 at 06:25:21PM +0200, Samuel Thibault wrote:
> 
> > Interesting :) But then if one wants to add some files to the software,
> > which changes the dependencies, are we able to insert it correctly in
> > the build process? Being able to change the set of files to be built is
> > part of being able to modify the software, for it to be free :/
> 
> My understanding is that the preferred source of modification will still
> be shipped, only with the addition of the preprocessed build
> instructions, to remove the need free software that is not in Debian.
> 
> If someone wants to add things to the software that change the
> dependency, I understand, one can regenerate the build trace with the
> build system that upstream uses (which is free software), and things
> keep working.

Being free software doesn't matter here if it's not available in
Debian. This fails the Desert Island test with only a set of Debian CDs
at hand.

Samuel

Re: Rethinking tensorflow build (taking shortcuts)

[Samuel Thibault]

Mo Zhou, le ven. 04 oct. 2019 09:37:25 -0700, a ecrit:
> On the other hand, ff the user wants significantly different stuff,
> they have to re-generate a buildlog and update the parser accordingly.
> 
> Not bad, right?

Better than nothing, sure :)

Samuel

Re: Rethinking tensorflow build (taking shortcuts)

[Daniele Nicolodi]

On 04-10-2019 10:04, Mo Zhou wrote:
> The only officially supported build system for Tensorflow is
> bazel[1], which is not present in our archive due to some reasons.

For those not following closely, can you please point to the reasons why
bazel (cannot?) is (yet?) packaged for Debian?  I recently pumped into
another software that proposes to use bazel as its build system, thus I
would like to be aware of any problems with it.

Thanks!

Cheers,
Dan

Re: Rethinking tensorflow build (taking shortcuts)

[Samuel Thibault]

Daniele Nicolodi, le ven. 04 oct. 2019 12:27:08 -0600, a ecrit:
> On 04-10-2019 10:04, Mo Zhou wrote:
> > The only officially supported build system for Tensorflow is
> > bazel[1], which is not present in our archive due to some reasons.
> 
> For those not following closely, can you please point to the reasons why
> bazel (cannot?) is (yet?) packaged for Debian?  I recently pumped into
> another software that proposes to use bazel as its build system, thus I
> would like to be aware of any problems with it.

At least, when I tried to have a look, I got scared away by the
magnitude of dependencies :/

Samuel

Re: Rethinking tensorflow build (taking shortcuts)

[Kyle Edwards]

On Fri, 2019-10-04 at 12:27 -0600, Daniele Nicolodi wrote:
> For those not following closely, can you please point to the reasons
> why
> bazel (cannot?) is (yet?) packaged for Debian?  I recently pumped
> into
> another software that proposes to use bazel as its build system, thus
> I
> would like to be aware of any problems with it.
> 
> Thanks!
> 
> Cheers,
> Dan

The issues have been discussed on the ITP for Bazel:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782654

Kyle

Re: Debian and our frenemies of containers and userland repos

[Paul Wise]

On Fri, Oct 4, 2019 at 10:49 PM Enrico Weigelt wrote:
> On 24.07.19 08:17, Marc Haber wrote:
>
> > Do we have a build technology that uses containers instead of chroots
> > yet?
>
> Something like docker-buildpackage ?

AFAICT, docker-buildpackage doesn't exist but whalebuilder does.

For systemd-nspawn containers there is debspawn.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise