Re: Mass filing on Python 3.7 async module import?

[Adrian Bunk]

On Mon, Jul 09, 2018 at 02:33:18PM +0200, Thomas Goirand wrote:
> On 07/08/2018 12:36 PM, Emilio Pozuelo Monfort wrote:
> > List of affected packages:
> > 
> > openscap-daemon: /usr/lib/python3/dist-packages/openscap_daemon/async.py
> > pylint3: /usr/lib/python3/dist-packages/pylint/checkers/async.py
> > python3-astroquery: 
> > /usr/lib/python3/dist-packages/astroquery/vo_conesearch/async.py
> > python3-celery: /usr/lib/python3/dist-packages/celery/backends/async.py
> > python3-dropbox: /usr/lib/python3/dist-packages/dropbox/async.py
> > python3-exabgp: /usr/lib/python3/dist-packages/exabgp/reactor/async.py
> > python3-gunicorn: /usr/lib/python3/dist-packages/gunicorn/workers/async.py
> > python3-ldap: /usr/lib/python3/dist-packages/ldap/async.py
> > python3-mapproxy: /usr/lib/python3/dist-packages/mapproxy/util/async.py
> > python3-opengl: /usr/lib/python3/dist-packages/OpenGL/GL/SGIX/async.py
> > python3-opengl: /usr/lib/python3/dist-packages/OpenGL/raw/GL/SGIX/async.py
> > python3-pexpect: /usr/lib/python3/dist-packages/pexpect/async.py
> > python3-pylama: /usr/lib/python3/dist-packages/pylama/async.py
> > python3-pymodbus: /usr/lib/python3/dist-packages/pymodbus/client/async.py
> > python3-pymodbus: /usr/lib/python3/dist-packages/pymodbus/server/async.py
> > python3-raven: /usr/lib/python3/dist-packages/raven/contrib/async.py
> > python3-rpyc: /usr/lib/python3/dist-packages/rpyc/core/async.py
> > python3-tenacity: /usr/lib/python3/dist-packages/tenacity/async.py
> > salt-common: /usr/lib/python3/dist-packages/salt/utils/async.py
> > visidata: /usr/lib/python3/dist-packages/visidata/async.py
> 
> There's more than this. What you're reporting doesn't seem to include
> packages defining the async function, for example gevent. I also saw
> more than this list, just by trying to rebuild neutron-fwaas:
> python3-oslo.db (we just fixed that one), python3-kafka, python3-pika,
> python3-dogpile.cache (bug with fix already filled, we'll fix soon).
> 
> I would anyway very much welcome a mass bug filling, but best would be
> to try not to forget any package. Note that tenacity is already fixed.

Note that "already fixed in unstable" is only part of the story.

Most important will be Breaks for all affected packages in *stretch*,
since there might otherwise be nasty problems in stretch->buster
upgrades depending on the undefined order of package upgrades.

> Cheers,
> 
> Thomas Goirand (zigo)

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#903427: ITP: libuuid-urandom-perl -- Perl module to provide UUIDs based on /dev/urandom

[Xavier Guimard]

Package: wnpp
Severity: wishlist
Owner: Xavier Guimard 

* Package name: libuuid-urandom-perl
  Version : 0.001-1
  Upstream Author : David Golden 
* URL : https://metacpan.org/release/UUID-URandom
* License : Apache 2.0
  Programming Lang: Perl
  Description : Perl module to provide UUIDs based on /dev/urandom

UUID::URandom provides a portable, secure generator of RFC-4122 version 4
(random) UUIDs. It is a thin wrapper around Crypt::URandom to set the UUID
version and variant bits required by the RFC.

This package is a new dependency of libmongodb-perl (version ≥ 2.0.0),
that's why I'd like to propose it.

Re: Reproducible builds error: libQt5Core.so.5: cannot open shared object file: No such file or directory

[Holger Levsen]

On Mon, Jul 09, 2018 at 08:34:54PM +0200, Mattia Rizzolo wrote:
> I agree.  I haven't been mad about it only because it affects i386 only,
> and we have 3 other architectures, 

I agree too.

> but we'll need to figure a workaround
> soon.

and/or exclude these results from showing up on tracker.d.o and
elsewhere.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: workarounds for Planet bugs?

[Daniel Pocock]

On 03/07/18 20:24, Laura Arjona Reina wrote:
> Hello Daniel
> 
> 
> El 02/07/18 a las 20:04, Daniel Pocock escribió:
>>
>>
>> Hi everybody,
>>
>> Planet struggles to poll certain blogs (see below), including some new
>> contributors.
>>
>> Does anybody know of workarounds these people can use until Planet is
>> updated to a recent version of planet-venus?  For example, at least
>> three of them I communicated with are using Wordpress, is there some
>> setting in Wordpress they need to enable or disable to make their feed work?
>>
> 
> I've switched some feeds to HTTPS:
> 
> https://salsa.debian.org/planet-team/config/commit/32a1934f4f142a664f397f5c6c8b6cc664689f60
> 
> I hope this fixes the issue.

Thanks for trying this

> In other cases, the blogs were inaccessible. I suggest to contact with
> each one of their authors, because the issue may not be the same for all
> of them, and try to find a working feed that can be added to the planet.
> 


Yes, I don't think they are all the same problem.

For Anisa, Jona and Kristi they are all using Wordpress and it is polled
successfully by the version of planet-venus[1] in stretch and by other
Planet sites so I didn't want to bother them to try changing their whole
blog unless there is a known workaround for the issue that they can
enable without too much effort.

Regards,

Daniel

$ curl -o - -s https://planet.debian.org | grep 'href=""'
 (feed)
Anisa Kuci https://anisakuci.com/feed/";>(feed)
Benjamin Kerensa (feed)
Eduard Bloch http://www.rootfs.net/jaws/data/xml/blog.Debian.rss";>(feed)
James Bromberger https://blog.james.rcpt.to/category/computing/linux/feed/";>(feed)
Jona Azizaj https://blog.azizaj.com/tag/debian/feed/";>(feed)
Jose Luis Rivas https://ghostbar.co/feed-planetdebian.xml";>(feed)
Kristi Progri https://kristiprogri.com/feed/";>(feed)
Marco d'Itri https://blog.bofh.it/debian/?format=atom";>(feed)
Martin Meredith (feed)




1. https://packages.qa.debian.org/p/planet-venus.html

Re: Reproducible builds error: libQt5Core.so.5: cannot open shared object file: No such file or directory

[Mattia Rizzolo]

On Mon, Jul 09, 2018 at 07:36:51PM +0200, Innocent De Marchi wrote:
> Thank you very much for your answer. This does not leave the
> reproducible builds in a very good place...

I agree.  I haven't been mad about it only because it affects i386 only,
and we have 3 other architectures, but we'll need to figure a workaround
soon.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Reproducible builds error: libQt5Core.so.5: cannot open shared object file: No such file or directory

[Innocent De Marchi]

Hi Mattia & Holger ,


> 
> The (IMHO) misleading message is instead a linker bug, that I don't
> think anybody filed anywhere.  Although that stupid message did cause
> and is still causing a ton of wasted time for people to figure what is
> going on.
> 

Thank you very much for your answer. This does not leave the
reproducible builds in a very good place...


Regards!

I. De Marchi

Re: Reproducible builds error: libQt5Core.so.5: cannot open shared object file: No such file or directory

[Holger Levsen]

On Mon, Jul 09, 2018 at 07:02:00PM +0200, Innocent De Marchi wrote:
> Recently, ALL the packages that I maintain based on Qt, have problems
> of reproducibility on build on i386.
> 
> The message is always the same: 
> /usr/lib/qt5/bin/uic: error while loading shared libraries:
> libQt5Core.so.5: cannot open shared object file: No such file or
> directory [0].
 
This is because of #895718 "libqt5core5a: Requires Linux kernel 3.17.0 or 
newer".


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: Reproducible builds error: libQt5Core.so.5: cannot open shared object file: No such file or directory

[Mattia Rizzolo]

On Mon, Jul 09, 2018 at 07:02:00PM +0200, Innocent De Marchi wrote:
> Recently, ALL the packages that I maintain based on Qt, have problems
> of reproducibility on build on i386.

This is:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895718
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902383

Which turned out to be needed due to:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875990
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876035

> The message is always the same: 
> /usr/lib/qt5/bin/uic: error while loading shared libraries:
> libQt5Core.so.5: cannot open shared object file: No such file or
> directory [0]

The (IMHO) misleading message is instead a linker bug, that I don't
think anybody filed anywhere.  Although that stupid message did cause
and is still causing a ton of wasted time for people to figure what is
going on.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Reproducible builds error: libQt5Core.so.5: cannot open shared object file: No such file or directory

[Innocent De Marchi]

Hello everyone,

Recently, ALL the packages that I maintain based on Qt, have problems
of reproducibility on build on i386.

The message is always the same: 
/usr/lib/qt5/bin/uic: error while loading shared libraries:
libQt5Core.so.5: cannot open shared object file: No such file or
directory [0].

I'm missing something? libQt5Core is a dependency that must be
installed when the qtbase5-dev packages depend.

Regards!

I. De Marchi



[0]
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/glpeces.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/librecad.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/connectagram.html
and others...

Thanks again for autopkgtest testing migration gating.

[Ian Jackson]

I just wanted to say thank you again for getting this working.  I know
I have been sending a lot of messages about how things can be
improved.  That doesn't really reflect how good a change this has
been.

Now, when I have a package with a good test suite, development speed
is very substantially increased.  With the reduction in migration
delays, I feel closer to (at least some of) my users.

The migration delay effect is great in both directions: I feel less
need to run very formal (and therefore very time consuming) tests
manually on my laptop.  (Although I do still find them useful, so
they're not out of my workflow completely, and I do do quite thorough
ad-hoc testing.)  This is good redirection of my time, away from
setting up and babysitting tests.

And the rdependency testing has already meant that one obscure
potential data loss regression, due to complicated interactions
between different programs, was detected by my test suite, and fixed,
before the affected combinations of software reached testing.
With a program which makes heavy use of some of its dependencies, it
is good to feel confident that regressions will be detected, and
quickly reported to me.[1]

I would encourage everyone who can do so, to jump on this bandwagon.
Development is so much faster and easier when a solid set of tests
stand between you and releasing bugs.

Ian.

[1] I'm using grep-excuses --autopkgtests for this, which is in very
recent versions of devscripts.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: SALSA migration of XML/SGML packages (sgml-data for me)

[Mattia Rizzolo]

On Mon, Jul 09, 2018 at 11:46:48PM +0900, Osamu Aoki wrote:
> I vote for this: debian-s...@lists.debian.org

The everybody, please remember to change the Maintainer address on your
next upload, and subscribe it! :)

> (If anyone has energy, ask ML admin to make this
> debian-xml-s...@lists.debian.org but that can be dome by making it as
> alias later.)

Is that actually possible?  I don't think I ever saw it happen on
@lists.debian.org...

> PS:  Are team+foo@tracker.d.o mails archived?

They are not, which is one reason for preferring @l.d.o given that we
already have it.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: SALSA migration of XML/SGML packages (sgml-data for me)

[Osamu Aoki]

Hi,

On Mon, Jul 09, 2018 at 04:07:44PM +0200, Mattia Rizzolo wrote:
> On Mon, Jul 09, 2018 at 10:52:29PM +0900, Osamu Aoki wrote:
...
> > Since we have developer ML as debian-s...@lists.debian.org, why not use
> > it as group mail address.  Then we already have well supported stable
> > archived ML system.  ...
> 
> TBH, I never subscribed to that ML, as for some reason it wasn't used
> (if you check the archive, it's pretty much all spam in the last years).
> 
> Indeed, at this point it would make a ton of sense to change all the
> packages to just use that ML, given that we have it.
> What do you think?  Should we ask all the people that are in CC here to
> subscribe that ML and change the packages?

I vote for this: debian-s...@lists.debian.org

(If anyone has energy, ask ML admin to make this
debian-xml-s...@lists.debian.org but that can be dome by making it as
alias later.)

Osamu

PS:  Are team+foo@tracker.d.o mails archived?
 

Re: Compiling binaries with PGO

[Chris Lamb]

Hi Alexander,

> Will you try to use PGO for your packages

Note that (naive) implementations of PGO can have ramifications for
reproducible builds [0].

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: SALSA migration of XML/SGML packages (sgml-data for me)

[Mattia Rizzolo]

On Mon, Jul 09, 2018 at 10:52:29PM +0900, Osamu Aoki wrote:
> > > This sgml-data is SGML package so it is most appropriate to be taken
> > > care by people who were on Debian XML/SGML Group
> > > .  I think this is
> > > unreachable email address by now.
> > 
> > You think wrong, as that mail address has been migrated on the temporary
> > server on alioth-lists.debian.net, together with all the others
> > (although I believe most of them should have been archived away, and
> > move to use a team+foo@tracker.d.o address).
> 
> I see.  I also saw:
>   https://lists.debian.org/debian-sgml/2018/02/msg0.html
> by  Joseph Herlant who created https://salsa.debian.org/xml-sgml-team

Right, he was him who started the migration.

> Since we have developer ML as debian-s...@lists.debian.org, why not use
> it as group mail address.  Then we already have well supported stable
> archived ML system.  ...

TBH, I never subscribed to that ML, as for some reason it wasn't used
(if you check the archive, it's pretty much all spam in the last years).

Indeed, at this point it would make a ton of sense to change all the
packages to just use that ML, given that we have it.
What do you think?  Should we ask all the people that are in CC here to
subscribe that ML and change the packages?

> Is team+foo@tracker.d.o address usable now?  Any howto to set it up?

It is.  I just created one, just for the sake of it:
https://tracker.debian.org/teams/xml-sgml/
That would mean the team address would be team+xml-sgml@tracker.d.o (it
can be changed, but it would also change the url).  IMHO, we should just
use the @lists.d.o one that provides an archive and everything.

> > > Does anyone working on moving these repo to SALSA and uploading properly
> > > updated packages with reachable group address?
> > 
> > If you checked DDPO as you said, and noticed that *some* are on alioth,
> > you must also have noticed that the others are already on salsa…
> 
> Yes.  Also prople are using their name as Maintainer instead of group
> mail address.

aye :(

> > https://salsa.debian.org/groups/xml-sgml-team/-/group_members
> > 
> > I added you to the team now.
> 
> Thanks
> 
> > > FYI: I created SALSA repo for sgml-data
> > >  https://salsa.debian.org/debian/sgml-data
> > 
> > I'd consider asking the salsa admin to move it under the team namespace,
> > unless you think it would be best under /debian/, of course.
> 
> Are you suggesting some manual repo move?

Yes.

> Is that important?

Not really.  And what you did is also fine for me (and quite
transparent).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: SALSA migration of XML/SGML packages (sgml-data for me)

[Osamu Aoki]

Hi,

FYI:
 Now sgml-data is listed in https://salsa.debian.org/xml-sgml-team

On Sun, Jul 08, 2018 at 06:38:38PM +0200, Mattia Rizzolo wrote:
> On Sun, Jul 08, 2018 at 11:20:57PM +0900, Osamu Aoki wrote:
> > I am wondering what is happening with XML/SGML packages.
> 
> The group is now on salsa at:
> https://salsa.debian.org/xml-sgml-team
> and not all packages are abandoned, thought several are.

Good.

> > This sgml-data is SGML package so it is most appropriate to be taken
> > care by people who were on Debian XML/SGML Group
> > .  I think this is
> > unreachable email address by now.
> 
> You think wrong, as that mail address has been migrated on the temporary
> server on alioth-lists.debian.net, together with all the others
> (although I believe most of them should have been archived away, and
> move to use a team+foo@tracker.d.o address).

I see.  I also saw:
  https://lists.debian.org/debian-sgml/2018/02/msg0.html
by  Joseph Herlant who created https://salsa.debian.org/xml-sgml-team

Since we have developer ML as debian-s...@lists.debian.org, why not use
it as group mail address.  Then we already have well supported stable
archived ML system.  ...

Is team+foo@tracker.d.o address usable now?  Any howto to set it up?

> > Does anyone working on moving these repo to SALSA and uploading properly
> > updated packages with reachable group address?
> 
> If you checked DDPO as you said, and noticed that *some* are on alioth,
> you must also have noticed that the others are already on salsa…

Yes.  Also prople are using their name as Maintainer instead of group
mail address.
 
> https://salsa.debian.org/groups/xml-sgml-team/-/group_members
> 
> I added you to the team now.

Thanks

> > FYI: I created SALSA repo for sgml-data
> >  https://salsa.debian.org/debian/sgml-data
> 
> I'd consider asking the salsa admin to move it under the team namespace,
> unless you think it would be best under /debian/, of course.

Are you suggesting some manual repo move?  Is that important?

I added xml-sgml-team group member a group write access to the sgml-data
archive as Developer.  This action has nice side effect.  Now, sgml-data
is listed under https://salsa.debian.org/xml-sgml-team as a member
project.

Currently, xml-sgml-team projects doesn't add debian group at the top
level.  That should be possible soon with updated github.  If you intend
to give access to all DD, setting write access by the debian group (DD)
may be an option.

Osamu

Re: Mass filing on Python 3.7 async module import?

[Thomas Goirand]

On 07/08/2018 12:36 PM, Emilio Pozuelo Monfort wrote:
> List of affected packages:
> 
> openscap-daemon: /usr/lib/python3/dist-packages/openscap_daemon/async.py
> pylint3: /usr/lib/python3/dist-packages/pylint/checkers/async.py
> python3-astroquery: 
> /usr/lib/python3/dist-packages/astroquery/vo_conesearch/async.py
> python3-celery: /usr/lib/python3/dist-packages/celery/backends/async.py
> python3-dropbox: /usr/lib/python3/dist-packages/dropbox/async.py
> python3-exabgp: /usr/lib/python3/dist-packages/exabgp/reactor/async.py
> python3-gunicorn: /usr/lib/python3/dist-packages/gunicorn/workers/async.py
> python3-ldap: /usr/lib/python3/dist-packages/ldap/async.py
> python3-mapproxy: /usr/lib/python3/dist-packages/mapproxy/util/async.py
> python3-opengl: /usr/lib/python3/dist-packages/OpenGL/GL/SGIX/async.py
> python3-opengl: /usr/lib/python3/dist-packages/OpenGL/raw/GL/SGIX/async.py
> python3-pexpect: /usr/lib/python3/dist-packages/pexpect/async.py
> python3-pylama: /usr/lib/python3/dist-packages/pylama/async.py
> python3-pymodbus: /usr/lib/python3/dist-packages/pymodbus/client/async.py
> python3-pymodbus: /usr/lib/python3/dist-packages/pymodbus/server/async.py
> python3-raven: /usr/lib/python3/dist-packages/raven/contrib/async.py
> python3-rpyc: /usr/lib/python3/dist-packages/rpyc/core/async.py
> python3-tenacity: /usr/lib/python3/dist-packages/tenacity/async.py
> salt-common: /usr/lib/python3/dist-packages/salt/utils/async.py
> visidata: /usr/lib/python3/dist-packages/visidata/async.py

There's more than this. What you're reporting doesn't seem to include
packages defining the async function, for example gevent. I also saw
more than this list, just by trying to rebuild neutron-fwaas:
python3-oslo.db (we just fixed that one), python3-kafka, python3-pika,
python3-dogpile.cache (bug with fix already filled, we'll fix soon).

I would anyway very much welcome a mass bug filling, but best would be
to try not to forget any package. Note that tenacity is already fixed.

Cheers,

Thomas Goirand (zigo)

Re: Mass filing on Python 3.7 async module import?

[Matthias Klose]

I'll add these as breaks in the next python3.7 upload. Please mention these in 
#902788.


On 08.07.2018 12:36, Emilio Pozuelo Monfort wrote:

On 08/07/18 00:17, Paul R. Tagliamonte wrote:

Hey DPMT (BCC'ing -devel, let's keep conversaion on DPMT),

I see that Python 3.7 now raises a syntax error when you try to import
a module that is named `async`.

```
$ python3.6
Python 3.6.6 (default, Jun 27 2018, 14:44:17)
[GCC 8.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

import foo.async

Traceback (most recent call last):
   File "", line 1, in 
ModuleNotFoundError: No module named 'foo'



```

With Python 3.7:

```
$ python3.7
Python 3.7.0 (default, Jun 27 2018, 14:40:03)
[GCC 8.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

import foo.async

   File "", line 1
 import foo.async
^
SyntaxError: invalid syntax



```

Quickly checking codesearch, there are a bunch of packages that have
import lines that look like they'd fail.

Anyone mind if I do a MBF on libraries that are providing anything
named `async.py`?


List of affected packages:

openscap-daemon: /usr/lib/python3/dist-packages/openscap_daemon/async.py
pylint3: /usr/lib/python3/dist-packages/pylint/checkers/async.py
python3-astroquery: 
/usr/lib/python3/dist-packages/astroquery/vo_conesearch/async.py
python3-celery: /usr/lib/python3/dist-packages/celery/backends/async.py
python3-dropbox: /usr/lib/python3/dist-packages/dropbox/async.py
python3-exabgp: /usr/lib/python3/dist-packages/exabgp/reactor/async.py
python3-gunicorn: /usr/lib/python3/dist-packages/gunicorn/workers/async.py
python3-ldap: /usr/lib/python3/dist-packages/ldap/async.py
python3-mapproxy: /usr/lib/python3/dist-packages/mapproxy/util/async.py
python3-opengl: /usr/lib/python3/dist-packages/OpenGL/GL/SGIX/async.py
python3-opengl: /usr/lib/python3/dist-packages/OpenGL/raw/GL/SGIX/async.py
python3-pexpect: /usr/lib/python3/dist-packages/pexpect/async.py
python3-pylama: /usr/lib/python3/dist-packages/pylama/async.py
python3-pymodbus: /usr/lib/python3/dist-packages/pymodbus/client/async.py
python3-pymodbus: /usr/lib/python3/dist-packages/pymodbus/server/async.py
python3-raven: /usr/lib/python3/dist-packages/raven/contrib/async.py
python3-rpyc: /usr/lib/python3/dist-packages/rpyc/core/async.py
python3-tenacity: /usr/lib/python3/dist-packages/tenacity/async.py
salt-common: /usr/lib/python3/dist-packages/salt/utils/async.py
visidata: /usr/lib/python3/dist-packages/visidata/async.py

and the dd-list:

Andriy Senkovych 
salt (U)

Anja Boskovic 
visidata

Bas Couwenberg 
mapproxy (U)

Benjamin Drung 
salt (U)

Brian May 
celery (U)

Carl Suster 
rpyc (U)

ChangZhuo Chen (陳昌倬) 
pylama (U)

Chris Lamb 
gunicorn

Debian Astro Team 
astroquery

Debian GIS Project 
mapproxy

Debian Python Modules Team 
celery
pexpect
pylama
pymodbus
pyopengl
python-dropbox
python-ldap
python-raven (U)
python-tenacity
rpyc

Debian Salt Team 
salt

Debian Security Tools 
openscap-daemon

Franklin G Mendoza 
salt (U)

Joe Healy 
salt (U)

Maximiliano Curia 
pymodbus (U)

Michael Fladischer 
celery (U)
python-dropbox (U)

Ondřej Kobližek 
python-tenacity (U)

Ondřej Nový 
python-tenacity (U)
salt (U)

Philippe Thierry 
openscap-daemon (U)

Python Applications Packaging Team 
pylint (U)

Sandro Tosi 
pylint

Thomas Goirand 
python-tenacity (U)

Tobias Hansen 
pexpect (U)

Torsten Marek 
pyopengl (U)

Vincent Bernat 
exabgp
python-raven

Vincent Prat 
astroquery (U)

W. Martin Borgert 
pymodbus (U)

Willem van den Akker 
python-ldap (U)

Wolodja Wentland 
salt (U)

Cheers,
Emilio

Re: Compiling binaries with PGO

[Matthias Klose]

On 09.07.2018 12:13, Alexander Zaitsev wrote:

Hello.

As far as I know binaries in Debian repositories most binaries are compiled 
without
PGO (profile-guided optimization). Also I don't know any LInux-based OS
where all (or significant part) binaries are precompiled with PGO. With PGO we
can improve
performance of binaries for typical use-cases without compiling for some
specific architecture (so binaries with PGO will be architecture-independent).

Question: why PGO isn't used by maintainers for packages? Lack of
profile data for compilation with PGO? Isn't interested for
mainatainers? Lack of build resources? Something else? Will you try to use PGO
for your packages,
if will be available repository with profile data for different
applications, where you can pick profile data for your application,
recompile package with this information and, probably, increase
performance of your application?


it is used to some extent. E.g. the python interpreter packages are built using 
PGO/LTO optimization on some architectures, and some upstreams support building 
using PGO as well.  You need to find some way to create the profile data, which 
usually requires some extra packaging work.  There is also autofdo, using a more 
general profile data format suitable for both GCC and LLVM, so you could try to 
include that data into the packaging, and use it in the build process.


Don't assume too much speed improvements. I usually see around 3-6%.

Matthias

Bug#903386: ITP: bcbio -- toolkit for analysing high-throughput sequencing data

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: bcbio
* URL : https://github.com/bcbio/bcbio-nextgen
* License : MIT
  Programming Lang: Python
  Description : toolkit for analysing high-throughput sequencing data

Team-maintained at https://salsa.debian.org/med-team/bcbio

Re: Research survey: Impact of Microsoft Acquisition of GitHub

[Dominik George]

Hi,

>However, your choice of involving Google in this "anonymized" survey 
>strongly discourages me personally from participating.

Me too.

I will not take part in a survey needlessly using non-free spyware.

-nik

Compiling binaries with PGO

[Alexander Zaitsev]

Hello.As far as I know binaries in Debian repositories most binaries are compiled withoutPGO (profile-guided optimization). Also I don't know any LInux-based OSwhere all (or significant part) binaries are precompiled with PGO. With PGO we can improveperformance of binaries for typical use-cases without compiling for somespecific architecture (so binaries with PGO will be architecture-independent).Question: why PGO isn't used by maintainers for packages? Lack ofprofile data for compilation with PGO? Isn't interested formainatainers? Lack of build resources? Something else? Will you try to use PGO for your packages,if will be available repository with profile data for differentapplications, where you can pick profile data for your application,recompile package with this information and, probably, increaseperformance of your application? -- Best regards, Alexander Zaitsev 

Re: Research survey: Impact of Microsoft Acquisition of GitHub

[Jonas Smedegaard]

Hi Asavaseri,

Quoting Asavaseri Natnaree (2018-07-09 07:13:13)
> Dear Debian developers, 
> 
> I am Natnaree Asavaseri and currently undertaking a research 
> internship at Nara Institute of Science and Technology, Japan. Note 
> that we are not biased to either GitHub or Microsoft, and this is 
> purely from an empirical research perspective. 
> 
> As a part of my research in the field of Software Engineering (SE), my 
> professors and I are analyzing the impact of Microsoft's acquisition 
> of GitHub. The main purpose of my survey is understanding how 
> developers perceive the Microsoft's acquisition of GitHub, especially 
> from contributors to Linux distributions and BSD families. If the 
> survey is successful, we will publish our findings at SE academic 
> venues (journals or conference).
> 
> So please consider voicing your opinion by allowing us up to 5 minutes 
> to complete my short survey. 
> 
> https://goo.gl/forms/lbIL5qsinDRQyTaK2 
> 
> We would like to remind you that participation in this survey is 
> completely voluntary and your identity is hidden for anonymity. Thank 
> you for your time in advance. 

I appreciate your making this survey, and find it relevant to invite us 
Debian developers to take part in it.

However, your choice of involving Google in this "anonymized" survey 
strongly discourages me personally from participating.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#903375: ITP: node-path-parse -- The path module provides utilities for working with file and directory paths

[mangesh divate]

Package: wnpp
Severity: wishlist
Owner: Mangesh Divate  
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-path-parse
  Version : 1.0.5
  Upstream Author : Javier Blanco 
* URL : https://github.com/jbgutierrez/path-parse#readme
* License : Expat
  Programming Lang: JavaScript
  Description : The path module provides utilities for working
with file and directory paths

 Path parse is debian package written in nodejs which  helps to
 understand path(directory).
 .
 for the path "/home/user/dir/file.txt'  path.parse package returns
follwing information
 root: '/',
 dir: '/home/user/dir',
 base: 'file.txt',
 ext: '.txt',
 name: 'file'


Packaging path-parse  as a dependency for browserify