Bug#924299: ITP: mpi4py-fft -- a Python package for computing Fast Fourier Transforms (FFTs)

2019-03-11 Thread Drew Parsons
Package: wnpp
Severity: wishlist
Owner: Drew Parsons 

* Package name: mpi4py-fft
  Version : 2.0.0
  Upstream Author : Lisandro Dalcin , Mikael Mortensen 

* URL : https://bitbucket.org/mpi4py/mpi4py-fft/src
* License : BSD-2-clause
  Programming Lang: Python
  Description : a Python package for computing Fast Fourier Transforms 
(FFTs)

mpi4py-fft is a Python package for computing Fast Fourier Transforms
(FFTs). Large arrays are distributed and communications are handled
under the hood by MPI for Python (mpi4py). To distribute large arrays
we are using a new and completely generic algorithm that allows for
any index set of a multidimensional array to be distributed. We can
distribute just one index (a slab decomposition), two index sets
(pencil decomposition) or even more for higher-dimensional arrays.

In mpi4py-fft there is also included a Python interface to the FFTW
library. This interface can be used without MPI, much like pyfftw, and
even for real-to-real transforms, like discrete cosine or sine
transforms.

The package, like pyfftw, provides a Python interface to FFTW, but
with MPI parallelisation. This enables strong scaling tested to 16000
cores, or weak scaling tested to 2000 cores. The algorithm is
documented at https://arxiv.org/abs/1804.09536

Packaging is expected to be maintained under the Debian Science team.



FanPage na Facebooku

2019-03-11 Thread Twój FanPage

Dzień dobry, 

zajmujemy się profesjonalnym prowadzeniem 
*FanPage* na *Facebook**'u. *

Jeżeli chcieliby Państwo otrzymać bezpłatną 
propozycję w tym zakresie prosimy odpowiedzieć "*TAK" / /*na tę wiadomość 
e-mail .

_ _ _
Pozdrawiamy Serdecznie!



Help us understand the effects of developers' personality on collaboration in OSS development

2019-03-11 Thread collab . uniba
(** Apologies for multiple emails **)

Dear Apache developer,

We are a team of researchers from the Collab research group 
(http://collab.di.uniba.it), in the Department of Computer Science at the 
University of Bari, Italy. We would be grateful if you could help us understand 
the effects of developers' different personalities when they collaborate in the 
development of OSS projects.

Being an Apache developer, you are kindly invited to take a brief personality 
test (the so-called Big Five mini-IPIP test), which only takes *3 minutes* to 
complete (we promise!):
Link: http://collab.di.uniba.it:8000/miniipip/?id=N6FDs8

For more, please read "M.B. Donnellan et al. (2006). The mini-IPIP scales: 
Tiny-yet-effective measures of the Big Five factors of personality. 
Psychological Assessment, 18, 192-203"

All survey responses will be stored on a secure server in our University data 
center. We will openly publish the results so everyone can benefit from them, 
but we will anonymize and/or present them in aggregate so that tracking answers 
back to the respondents will be impossible. By filling in and submitting the 
survey, you are providing implied consent to participate in the study. However, 
if at some point during the survey you want to stop, you are free to do so and 
your partial answers will be discarded. Should you have further privacy 
concerns, please review the details of the ethics protocol for this research 
available at http://collab.di.uniba.it/mini-IPIP/privacy or contact us by email.

We appreciate your participation. Thank you for taking the time for reading 
this email.

Kind regards,
The Collab research team

Bug#924342: ITP: wf-recorder -- screen recorder for wlroots-based compositors

2019-03-11 Thread Birger Schacht
Package: wnpp
Severity: wishlist
Owner: Birger Schacht 

* Package name: wf-recorder
  Version : no release yet
  Upstream Author : Ilia Bozhinov
* URL : https://github.com/ammen99/wf-recorder
* License : MIT
  Programming Lang: C
  Description : screen recorder for wlroots-based compositors

wf-recorder is a utility program for screen recording of wlroots-based
compositors (more specifically, those that support wlr-screencopy-v1 and
xdg-output). Its dependences are ffmpeg, wayland-client and
wayland-protocols.



gbp-buildpackage showing change outside debian/, possibly after DEP-14 conversion

2019-03-11 Thread Bernhard Schmidt
Hi,

this has been bothering me for days and I can't find the reason. It is
probably something very trivial, but I don't get it. I have a
workaround, but I'd like to understand what went wrong here.

TL;DR: There is an unexplained linefeed difference in one file in the
orig.tar.xz2 generated by gbp that is only visible in one branch,
possibly after DEP-14 conversion, and only happens when using export=WC.

I use a pretty much standard (I think) development environment using
gbp-buildpackage and sbuild on my workstation tracking Buster. For years
I had this in my ~/.gbp.conf

---
[buildpackage]
export = WC
export-dir = ../build-area
---

this worked fine for all packages I'm (co)maintaining, I cannot recall
ever having issues with this. I like this setting because it allows me
to quickly testbuild a local change using my standard tooling without
committing it first.

I have also used this workflow for the last couple of src:bind9 uploads,
including the latest 1:9.11.5.P4+dfsg-1 . Up until a few days ago,
including my latest upload, the bind9 repository on salsa
(https://salsa.debian.org/dns-team/bind9) was in the default gbp layout.
Ondrej thankfully converted the repo into the DEP-14 layout by renaming
the branches, but afaics they are still the same commits. I cannot
easily check right now because the git checkout from before the
conversion is on a laptop I don't have with me at the moment. It COULD
be unrelated to the dep-14 conversion, but I think it's related.

This is where things get weird. When I clone the repo and try to build
the debian/buster branch, dpkg-source errors out about an unexpected
upstream change

berni@BOTOX:~/debian$ gbp clone g...@salsa.debian.org:dns-team/bind9.git
gbp:info: Cloning from 'g...@salsa.debian.org:dns-team/bind9.git'
berni@BOTOX:~/debian/bind9$ git checkout debian/buster
Branch 'debian/buster' folgt nun Remote-Branch 'debian/buster' von 'origin'.
Zu neuem Branch 'debian/buster' gewechselt
berni@BOTOX:~/debian/bind9$ gbp buildpackage --git-builder="sbuild
--source-only-changes "
gbp:info: Tarballs 'bind9_9.11.5.P4+dfsg.orig.tar.xz' not found at '../'
gbp:info: Exporting 'WC' to
'/ssdpool/bulkhome/berni/debian/build-area/bind9-tmp'
gbp:info: Moving '/ssdpool/bulkhome/berni/debian/build-area/bind9-tmp'
to '/ssdpool/bulkhome/berni/debian/build-area/bind9-9.11.5.P4+dfsg'
gbp:info: Performing the build
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 05_non-linux.diff
dpkg-source: info: applying 07_multiarch.diff
dpkg-source: info: applying 10_min-cache-ttl.diff
dpkg-source: info: applying 25_library_paths.diff
dpkg-source: info: applying 33_resource_missing_include.diff
dpkg-source: info: applying 34_prepare_native_pkcs11.diff
dpkg-source: info: applying 75_ctxstart_no_sighandling.diff
dpkg-source: info: applying 80_reproducible_build.diff
dpkg-source: info: applying Add_--install-layout=deb_to_setup.py_call.patch
dpkg-source: info: applying skip-rtld-deepbind-for-dyndb.diff
dh clean --with python3 --fail-missing --exclude=.la --exclude=lwresd
--exclude=__pycache__
   debian/rules override_dh_auto_clean
make[1]: Entering directory
'/ssdpool/bulkhome/berni/debian/build-area/bind9-9.11.5.P4+dfsg'
rm -rf bin/named-pkcs11
rm -rf bin/dnssec-pkcs11
rm -rf lib/isc-pkcs11
rm -rf lib/dns-pkcs11
if [ -f version.bak ]; then cp version.bak version; fi
dh_auto_clean -B build
dh_auto_clean -B build-udeb
make[1]: Leaving directory
'/ssdpool/bulkhome/berni/debian/build-area/bind9-9.11.5.P4+dfsg'
   dh_autoreconf_clean -O--fail-missing -O--exclude=.la
-O--exclude=lwresd -O--exclude=__pycache__
   dh_clean -O--fail-missing -O--exclude=.la -O--exclude=lwresd
-O--exclude=__pycache__
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building bind9 using existing
./bind9_9.11.5.P4+dfsg.orig.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: local changes detected, the modified files are:
 bind9-9.11.5.P4+dfsg/contrib/dlz/example/win32/dxdriver.dsw
dpkg-source: info: you can integrate the local changes with dpkg-source
--commit
dpkg-source: error: aborting due to unexpected upstream changes, see
/tmp/bind9_9.11.5.P4+dfsg-1.diff.cqPGYG
E: Failed to package source directory
/ssdpool/bulkhome/berni/debian/build-area/bind9-9.11.5.P4+dfsg
gbp:error: 'sbuild --source-only-changes ' failed: it exited with 1

The diff (attached) shows the single file
"contrib/dlz/example/win32/dxdriver.dsw", which we definitely never
touch in Debian, being converted from "\n" to "\r\n" line terminators. I
don't get where this comes from.

There is no difference between the upstream tag being used to generate
the orig.tar.xz2 and the debian/buster branch, in both there are DOS
crlf endings

berni@BOTOX:~/debian/bind9$ git diff
upstream/9.11.5.P4+dfsg..debian/buster
contrib/dlz/example/win32/dxdriver.dsw
berni@BOTOX:~/debian/bind9$ file contrib/dlz/example/win32/dxdriver.dsw
contrib/dlz/example/win32/dxdriver.dsw: ASCII t