Re: Progress in preparing the Bazel Build System for Debian (COVID-19 Biohackathon follow-up)

2020-05-06 Thread Andreas Tille
Hi Thorsten,

On Wed, May 06, 2020 at 05:15:04PM +0200, Thorsten Glaser wrote:
> > Provides or something to make it clear? I saw changes to packages adding
> 
> Or perhaps we need a webpage or wiki page generated by parsing the
> Contents file and listing the matching Debian package for each class
> or, at least, Java package (unless split across multiple packages)…

I remember times when such a web page (actually some autogenerated text
file) existed which was **extremely** helpful.  I wished this would be
back!
 
> … I just volunteerd, didn’t I?

:-)

Kind regards

  Andreas.

-- 
http://fam-tille.de



RFC: threadding-aware virtual BLAS/LAPACK?

2020-05-06 Thread Mo Zhou
Hi,

Through some previous discussions I realized that the issue of
threadding implementation of the BLAS can be sometimes cumbersome.  For
example, sometimes we can observe severe performance regression from
pthread program + BLAS with gomp, or even observe severe calculation
error from gomp program + BLAS with iomp (aka llvm openmp).

These threadding disasters will be eventually propagated to our end
users, and may possibly harm their scientific computing experience.

- Fedora

Recall what Fedora does for the BLAS libraries: they dont do any virtual
package at all. OpenBLAS packages with different threadding support are
given different sonames:

  openblas + pthread: libopenblasp.so.*
  openblas + openmp:  libopenblaso.so.* (IIRC)
  openblas + serial:  libopenblass.so.* (IIRC)

Although this makes implementations not switchable at runtime, but at
least the users won't have to struggle with threads.

- Gentoo

I wrote the alternatives mechanism for gentoo's blas/lapack, which
resembles Debian's. However, gentoo's package management system supports
a "USE flag" feature which allows the user to set global threadding
implementation for the whole system.

- what can we do

Maybe we can provide some more virtual shared objects such as
libblasp.so, which has candidates such as openblas-pthread and
blis-pthread?

In that case if a Debian maintainer intentionally choose to link against
a pthread BLAS (libblasp) to avoid issues of an openmp BLAS (libblaso),
we can help the users to avoid threadding issues when they don't read
any documentation (actually I think 99% of the users won't read the doc,
or have enough background to understand the threadding issue).

We can dig deeper into this direction if this turns to be a sensible
direction for making improvement.

Acknowledgement
---
This is a part of my GSoC2020 project, although this topic is not on the
original plan.



Re: Welcoming Mo Zhou as GSoC student

2020-05-06 Thread Mo Zhou
Needless to introduce myself here.
I'll start working shortly after finishing my reviewer jobs for a
deep learning and computer vision conference :-)

On Tue, May 05, 2020 at 07:07:30AM +0200, Andreas Tille wrote:
> Hi,
> 
> I've got confirmation that Mo Zhou is accepted as GSoC student
> for the topic
> 
>BLAS/LAPACK Ecosystem Enhancement for Debian
> 
> I'm really happy that Mo is taking over this task and I could not
> imagine anybody more competent for this task.  Mo, good luck for this
> time!  I do not think that you need any specific introduction here. ;-)
> 
> Kind regards
> 
> Andreas.
> 
> -- 
> http://fam-tille.de
> 



Re: Progress in preparing the Bazel Build System for Debian (COVID-19 Biohackathon follow-up)

2020-05-06 Thread Emmanuel Bourg
Hi Olek,

Le 06/05/2020 à 07:42, Olek Wojnar a écrit :

> We have more information available, including links to RFP bugs, on our
> Workplan wiki [3]. If you have Java experience and are willing to assist
> in this effort, even packaging one of these would be a great help. If
> you also want to help with the main Bazel-packaging effort, please feel
> free to join the team!

You can remove javax-annotation from the list, it's already packaged as
libgeronimo-annotation-1.3-spec-java. Also error-prone and
checker-framework provide annotations that are not required at runtime,
patching them out is an option.

Regarding the other generic dependencies, it would be nice to package
them under the Java Team umbrella.


Emmanuel Bourg



Re: Progress in preparing the Bazel Build System for Debian (COVID-19 Biohackathon follow-up)

2020-05-06 Thread Olek Wojnar
Hi Emmanuel,

On Wed, May 6, 2020 at 10:03 AM Emmanuel Bourg  wrote:

>
> You can remove javax-annotation from the list, it's already packaged as
> libgeronimo-annotation-1.3-spec-java. Also error-prone and
> checker-framework provide annotations that are not required at runtime,
> patching them out is an option.
>

Excellent, thanks for the info! That's great news. Yes, I was considering
that if we couldn't get those packaged quickly. Those two are my lowest
priority for that reason. I already did something similar in a patch for
libprotobuf-java and it was reasonably painless.

Regarding the other generic dependencies, it would be nice to package
> them under the Java Team umbrella.
>

I absolutely agree but I didn't want to speak for the Java Team. :) I'll
pass that request on to any contributors I interact with.

-Olek


Re: Progress in preparing the Bazel Build System for Debian (COVID-19 Biohackathon follow-up)

2020-05-06 Thread Sudip Mukherjee
On Wed, May 6, 2020 at 6:43 AM Olek Wojnar  wrote:
>
> Fellow Developers, Maintainers, and Contributors,
>
> This is a quick update on recent progress with packaging the Bazel Build
> System [1] for Debian. My involvement grew out of an urgent need for
> TensorFlow that was identified during the recent COVID-19 Biohackathon
> [2]. Upstream has been very supportive of our efforts and we have had
> many positive interactions with them.
>
> However, we've now reached a point where we need more help in order to
> get these important tools packaged in a timely manner. There are
> currently 10 Java package dependencies that are not available in Debian.
> These are:
> google-api-client
> google-auth
> google-auto
> checker-framework
> diffutils

As mentioned in #959834, diffutils was pretty straight forward and I
can take care of it under Java-Team.

-- 
Regards
Sudip



Re: Progress in preparing the Bazel Build System for Debian (COVID-19 Biohackathon follow-up)

2020-05-06 Thread Thorsten Glaser
On Wed, 6 May 2020, Andrej Shadura wrote:

> I wonder could we improve the package description and maybe add some

YES please, me either. Why even Geronimo, why not Jakarta’s, which
is the most latest?

> Provides or something to make it clear? I saw changes to packages adding

Or perhaps we need a webpage or wiki page generated by parsing the
Contents file and listing the matching Debian package for each class
or, at least, Java package (unless split across multiple packages)…

…

…

… I just volunteerd, didn’t I?

Mraw,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg



Re: Progress in preparing the Bazel Build System for Debian (COVID-19 Biohackathon follow-up)

2020-05-06 Thread Olek Wojnar
On Wed, May 6, 2020 at 11:23 AM Thorsten Glaser  wrote:

> Or perhaps we need a webpage or wiki page generated by parsing the
> Contents file and listing the matching Debian package for each class
> or, at least, Java package (unless split across multiple packages)…
>
> …
>
> …
>
> … I just volunteerd, didn’t I?
>

Sure sounds like it! Ha, ha! :)


Re: PSPP removed from Debian

2020-05-06 Thread Andreas Tille
Hi Friedrich,

On Wed, May 06, 2020 at 03:51:34PM +0200, Friedrich Beckmann wrote:
> Hi John, hi Andreas
> 
> the debian science team did the last CVE patches and wanted to maintain
> the package. I think the reason for removal is described here:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932951
> 
> The science team moved the debian code to the salsa git repository and I found
> a patch (or at least something that might fix that) here:
> 
> https://salsa.debian.org/science-team/pspp/-/commit/86bb103cbb9313ea70326a00223a2510e7462a0f
> 
> @Andreas: I am not too sure about the release process - is there anything 
> somebody must do to release this?

I think I gave up un the Python3 migration.  Please write to the team -
I'm personally not interested in pspp and flooded with work that is
connected to fight COVID-19 and I need to restrict my tasks in Debian to
this one for the moment.  To get the package back into Debian somebody
needs to care for the Python3 migration and than the package needs to
pass the new queue again.

Kinf regards

 Andreas.

-- 
http://fam-tille.de