Re: Please do not drop Python 2 modules

[Ondrej Novy]

Hi,

2018-04-26 20:04 GMT+02:00 Adrian Bunk :

> Triaging would imply a valid technical reason like problems with the
> Python 2 module, not blind dropping out of a desire to kill Python 2.
>

I completely agree with you Adrian, thanks!

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

RFC: Support for zstd in .deb packages?

[Guillem Jover]

Hi!

In 2016 Paul Wise mentioned the Zstandard compressor on IRC [Z],
and I briefly checked it out as a potential candidate for dpkg
(while also mentioning it to Julian Andres Klode who was considering
adding lz4 support to apt). At the time it looked like it was not
worth it (apt went with lz4), so it got parked.

Recently Julian mentioned it again on IRC, and we each started
implementing support in dpkg and apt respectively, to allow easier
evaluation. I stopped when I realized the code was getting too messy,
but after few weeks Julian and Bálint Réczey ended up implementing
the support for apt and dpkg [D], so that they could merge it in
Ubuntu for their upcoming release, which they did.

Their main driving reason (AFAICT) has been (de)compression speed.

The following is a quick run-down of the items from [F], not all
being important from Debian's perspective, but being for dpkg's:

* License: Permissive (dual BSD + GPL-2), which makes universal
  availability possible.
* Portability: The code seems portable, and it's available on some
  non-Linux systems.
* Availability: I don't think it's as common as gzip/bzip2/xz are now,
  say on non-Linux systems, perhaps not even on Linux distros.
* Implementation size: The shared library and its package are quite
  fatter than any of the other compressors dpkg uses.
* Eternity contract: This would add yet another format that would need
  to be supported pretty much forever, to be able to at least unpack
  .deb's that might be available in the wild. This also increases the
  (Build-)Essential-set.
* Format stability: Although it's supposedly frozen now, it has
  changed quite often in recent times. AFAIR it was also mentioned at
  least in the past that the target was mainly real-time data streaming,
  so long-term data storage might not be a priority? Would need
  clarification from upstream I guess.
* Memory usage: Seemed equivalent or less to current compressors, but
  only as long as equal or less space was desired.
* Space usage: Seemed worse.
* (De)compression speed: Seemed better (compared only to the existing
  supported formats) depending on the compression level used.


I'm still quite skeptical about it being worth it though, given the costs
implied (f.ex. [S]). That it trades space for speed, which could perhaps
improve use-cases like CI or buildds, or rolling distribution users, but
that still varies depending on the network speed, fsys/disk speed, etc,
which might not be an universal improver (to get there we might need to
tie this to delta debs, which would benefit xz too). It makes CD/DVD/BD
images and the archive in general larger. It's not the fastest, and it
doesn't have the highest compression ratio either; if we'd want way
faster (de)compression I think we'd still be better off with something
like lz4 anyway? And that most of the assumed benefits would only be
gained if we switched to it as the new default compressor, which would
require project-wide consensus. As a replacement for gzip, it would
definitely make sense, but otherwise I'm not sure I see it.

An area where there's still room for improvement with xz f.ex. when it
comes to decompression speed, is lack of multi-threaded support, as
liblzma currently only supports it for compression.


In any case, I've CCed both Julian and Bálint, so that they can fill
in with more details and numbers from what they have been trying out.

But in any case, I'm still open to data and opinions given that this
is in the end a matter of trade-offs, so → request for comments. :)

(And BTW I do not consider the current support in Ubuntu a deciding
factor in any way, while it could perhaps fragment the .deb ecosystem,
that's something for them to deal with IMO; should really start adding
the vendor to the generated .deb's. :)

Thanks,
Guillem

[Z] 


[F] 

[D] 
[S] 

Bug#897011: ITP: ruby-geoip -- Tool to search IP address according to Geoip database

[Manas Kashyap]

Package: wnpp
Severity: wishlist
Owner: Manas kashyap 
X-Debbugs-CC: debian-devel@lists.debian.org, debian-r...@lists.debian.org

* Package name: ruby-geoip
  Version : 1.6.4
 Upstream Author : Clifford Heath
* URL : https://github.com/cjheath/geoip
* License : LGPL 2.1
  Programming Lang: Ruby
  Description : It searches a GeoIP database for a given host or IP
address
  .
  And it returns information about the country where the IP address is
allocated,
  and the city, ISP and other information, according to the version of
GeoIP database.

Work-needing packages report for Apr 27, 2018

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1267 (new: 3)
Total number of packages offered up for adoption: 162 (new: 1)
Total number of packages requested help for: 54 (new: 1)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   libdigidoc (#896910), orphaned yesterday
 Description: DigiDoc digital signature library
 Reverse Depends: libdigidoc-dev libdigidoc-tools libdigidoc2
 Installations reported by Popcon: 91
 Bug Report URL: http://bugs.debian.org/896910

   libguess (#896821), orphaned 2 days ago
 Reverse Depends: libguess-dev python-libguess python3-libguess
 Installations reported by Popcon: 5809
 Bug Report URL: http://bugs.debian.org/896821

   libmowgli-2 (#896820), orphaned 2 days ago
 Reverse Depends: atheme-services libmowgli-2-0-dbg libmowgli-2-dev
 Installations reported by Popcon: 1186
 Bug Report URL: http://bugs.debian.org/896820

1264 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   bibutils (#896574), offered 4 days ago
 Description: interconvert various bibliographic data formats
 Reverse Depends: bibutils blogliterately libbibutils-dev
   libghc-blogliterately-dev libghc-hakyll-dev libghc-hs-bibutils-dev
   libghc-pandoc-citeproc-dev pandoc-citeproc
 Installations reported by Popcon: 1147
 Bug Report URL: http://bugs.debian.org/896574

161 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

[NEW] swi-prolog (#896458), requested 5 days ago
 Description: ISO/Edinburgh-style Prolog interpreter
 Reverse Depends: elpa-ediprolog libppl-swi logol-bin pakcs spark
   swi-prolog swi-prolog-bdb swi-prolog-java swi-prolog-odbc
   swi-prolog-x
 Installations reported by Popcon: 1308
 Bug Report URL: http://bugs.debian.org/896458

   autopkgtest (#846328), requested 512 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker openstack-pkg-tools
 Installations reported by Popcon: 1114
 Bug Report URL: http://bugs.debian.org/846328

   balsa (#642906), requested 2405 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 152
 Bug Report URL: http://bugs.debian.org/642906

   broadcom-sta (#886599), requested 108 days ago (non-free)
 Description: Broadcom STA Wireless driver (non-free)
 Installations reported by Popcon: 2051
 Bug Report URL: http://bugs.debian.org/886599

   cargo (#860116), requested 380 days ago
 Description: Rust package manager
 Reverse Depends: dh-cargo
 Installations reported by Popcon: 631
 Bug Report URL: http://bugs.debian.org/860116

   cups (#532097), requested 3246 days ago
 Description: Common UNIX Printing System
 Reverse Depends: ayatana-indicator-printers bluez-cups boomaga
   chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp
   cups-browsed cups-bsd (70 more omitted)
 Installations reported by Popcon: 175165
 Bug Report URL: http://bugs.debian.org/532097

   cyrus-sasl2 (#799864), requested 946 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli
   autofs-ldap cairo-dock-mail-plug-in claws-mail
   claws-mail-acpi-notifier claws-mail-address-keeper
   claws-mail-archiver-plugin (122 more omitted)
 Installations reported by Popcon: 197875
 Bug Report URL: http://bugs.debian.org/799864

   dee (#831388), requested 650 days ago
 Description: model to synchronize mutiple instances over DBus
 Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-1.0-4-dbg
   libdee-dev zeitgeist-core
 Installations reported by Popcon: 64325
 Bug Report URL: http://bugs.debian.org/831388

   developers-reference (#759995), requested 1335 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 12839
 Bug Report URL: http://bugs.debian.org/759995

   devscripts (#800413), requested 940 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   brz-debian bzr-builddeb customdeb debci debian-builder debmake (28
   more omitted)
 Installations reported by Popcon: 12285
 

Re: Please do not drop Python 2 modules

[Ben Hutchings]

On Thu, 2018-04-26 at 20:14 +0300, Adrian Bunk wrote:
> On Thu, Apr 26, 2018 at 12:03:56AM +0200, Thomas Goirand wrote:
[...]
> > ...
> > > Maintaining the Python 2 interpreter is actually reasonably trivial.
> > 
> > That's not the question I was asking. I was asking if someone is
> > volunteering for the next 5 years (ie: Buster + LTS support, that's
> > quite a huge commitment).
> 
> LTS is an effort by a 3rd party external company,
> what and how they support in LTS is not our problem.
[...]

LTS is a Debian project running on Debian infrastructure.  It's true
that most of the news you see about it is related to Freexian, but
there are other contributors quietly working on it.

But you are right that packages can be excluded from support - and in
fact this can be done during the regular stable period, at the
beginning of LTS, or later.  Specific exclusions are recorded in the
debian-security-support package.

Ben.

-- 
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot



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

Re: Please do not drop Python 2 modules

[Adrian Bunk]

On Thu, Apr 26, 2018 at 06:19:24PM +0100, Ian Jackson wrote:
>...
> Adrian: are you volunteering to write patches to solve Helmut's cross
> building problem ?

I am willing to stop for several weeks/months to monitor RC bugs and 
report FTBFS if you can make the case that it is more beneficial for 
Debian to spend this time instead on making ~ 100 additional packages 
cross-buildable.

> Ian.

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

Re: Please do not drop Python 2 modules

[Adrian Bunk]

On Thu, Apr 26, 2018 at 10:35:10AM -0700, Don Armstrong wrote:
> On Thu, 26 Apr 2018, Adrian Bunk wrote:
> > We (Debian) have decided to support Python 2.7 in buster, like it or
> > not.
> >
> > At that point it is not up to individual maintainers to sabotage
> > Python 2.7 support in buster by dropping Python 2 packages without a
> > valid technical reason.
> > 
> > "I want Python 2 to die" is not a valid technical reason here.
> 
> Some package maintainers do not wish to spend the time and effort
> necessary to support python 2 indefinitely in their packages. That's a
> reasonable personal assessment, and I applaud package maintainers for
> saying so early, clearly, and publicly.
> 
> The question is what (if anything) do any of us want to do to provide
> resources to provide that support.
> 
> We do not have unlimited maintainer time; triaging is sad, but it
> produces better outcomes.

This discussion is not about triaging, it is about maintainers dropping
Python 2 modules for no technical reason at all.

We already had several cases of a changelog for a new Debian revision
that looked approximately:
  * move vcs to salsa
  * Standards-Version: 4.1.3
  * remove python2 package

Soon afterwards there was an RC bug because this removed package still 
had a two digit number of reverse dependencies.

This is the tip of the iceberg I mentioned.

Triaging would imply a valid technical reason like problems with the 
Python 2 module, not blind dropping out of a desire to kill Python 2.

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#896993: ITP: python-cmarkgfm -- GitHub-flavored Markdown renderer Python bindings

[Nicolas Dandrimont]

Package: wnpp
Owner: Nicolas Dandrimont 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Control: block 896992 by -1

* Package name: python-cmarkgfm
  Version : 0.4.1
  Upstream Author : Thea Flowers, The Python Packaging Authority (PyPA)
* URL : https://github.com/jonparrott/cmarkgfm
* License : Expat and BSD-2-Clause
  Programming Lang: Python
  Description : GitHub-flavored Markdown renderer Python bindings

cmark is an extended version of the C reference implementation of
CommonMark, a rationalized version of Markdown syntax with a spec.

The cmark-gfm fork adds GitHub Flavored Markdown extensions to the
upstream implementation, as defined in the spec.

This package provides Python bindings for the cmark-gfm library.

This is a dependency for python-readme-renderer, which it itself a dependency
for devpi-web. This will be packaged under the Debian Python Modules Team.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#896992: ITP: python-readme-renderer -- Library to safely render arbitrary README files into HTML

[Nicolas Dandrimont]

Package: wnpp
Owner: Nicolas Dandrimont 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Control: block 896097 by -1

* Package name: python-readme-renderer
  Version : 20.0
  Upstream Author : Donald Stufft
* URL : https://github.com/pypa/readme_renderer
* License : Apache-2.0
  Programming Lang: Python
  Description : Library to safely render arbitrary README files into HTML

Readme Renderer is a library that will safely render arbitrary README files
into HTML.

It is designed to be used in the PyPI Warehouse to render the long_description
for packages.

It can handle Markdown, reStructuredText (.rst), and plain text.

This package is a dependency for devpi-web, and will be maintained within the
Debian Python Modules Team.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Re: Please do not drop Python 2 modules

[Don Armstrong]

On Thu, 26 Apr 2018, Adrian Bunk wrote:
> We (Debian) have decided to support Python 2.7 in buster, like it or
> not.
>
> At that point it is not up to individual maintainers to sabotage
> Python 2.7 support in buster by dropping Python 2 packages without a
> valid technical reason.
> 
> "I want Python 2 to die" is not a valid technical reason here.

Some package maintainers do not wish to spend the time and effort
necessary to support python 2 indefinitely in their packages. That's a
reasonable personal assessment, and I applaud package maintainers for
saying so early, clearly, and publicly.

The question is what (if anything) do any of us want to do to provide
resources to provide that support.

We do not have unlimited maintainer time; triaging is sad, but it
produces better outcomes.

-- 
Don Armstrong  https://www.donarmstrong.com

I shall require that [a scientific system's] logical form shall be
such that it can be singled out, by means of empirical tests, in a
negative sense: it must be possible for an empirical scientific system
to be refuted by experience.
 -- Sir Karl Popper _Logic of Scientific Discovery_ §6

Re: Please do not drop Python 2 modules

[Ian Jackson]

Andrej Shadura writes ("Re: Please do not drop Python 2 modules"):
> On 25 April 2018 at 18:14, Adrian Bunk  wrote:
> > There are big codebases written in languages like Tcl around,
> > so still using Python 2 doesn't strike me as exceptionally weird.
> 
> Not really disagreeing with you on anything, but I felt I have to be a
> shameless plug and note Tcl is actually quite a nice language, as long
> as you’re not using it the way it was done in the 90s.

I love Tcl.  I am still writing lots of new Tcl.

But of course Tcl is not deprecated upstream.

Having said that, the question is how much work is it to keep having
python2.  Helmut gave an example of a situation where it _is_ work:
having python2 gets in the way of crossbuilding and porting.

I think that there comes a point where it is reasonable to ask people
who want to keep something going, in the absence of upstream support,
to do that kind of work.

Adrian: are you volunteering to write patches to solve Helmut's cross
building problem ?

Ian.

-- 
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: Please do not drop Python 2 modules

[Adrian Bunk]

On Thu, Apr 26, 2018 at 12:03:56AM +0200, Thomas Goirand wrote:
> On 04/25/2018 06:14 PM, Adrian Bunk wrote:
> > On Tue, Apr 24, 2018 at 12:10:12AM +0200, Thomas Goirand wrote:
> >> ...
> >> This cannot go on, and on, and on, and on... We have to send a clear
> >> message on the right direction, which is Python 2 removal. Yes, removal!
> >> Why are we even discussing this? Isn't it obvious?
> > 
> > It is not for us to decide what tools our users should use,
> > we should support them no matter what tools they have to use.
> 
> I'd really love if it was the case. Reality is otherwise.
> 
> What if our users want to use Python 2.4? Will we do it? Of course not,
> at some point, we may say it's not doable reasonably, because of the
> lost of upstream support and the work it involves to keep it alive. So
> yes, it's up to us to decide what we're able or what we want to do for
> our users, and our users cannot dictate what tool we must maintain. It
> has to be the other way around, like it or not.

We (Debian) have decided to support Python 2.7 in buster, like it or not.

At that point it is not up to individual maintainers to sabotage
Python 2.7 support in buster by dropping Python 2 packages without
a valid technical reason.

"I want Python 2 to die" is not a valid technical reason here.

> >> Python 3 was released the 3rd of December 2008. 2020 is 12 years later.
> >> How many more years does one think we need until we send the message
> >> that yes, we should port our app/module to Python 3? Sorry, but legacy
> >> *must* die, as it doesn't have upstream support.
> > 
> > Why does legacy "*must*" die?
> 
> Any code that isn't updated to be able to run with the newest of
> everything it uses (library or interpreter) is in danger of becoming not
> maintainable in the long run. That's exactly what we're doing everywhere
> in Debian: each time a new version of something is out, all the reverse
> (build-)dependencies must be updated to support it.

We are not doing this everywhere in Debian.

For software like Python or Tcl we are shipping and security-supporting
two different versions in stable.

>...
> > Maintaining the Python 2 interpreter is actually reasonably trivial.
> 
> That's not the question I was asking. I was asking if someone is
> volunteering for the next 5 years (ie: Buster + LTS support, that's
> quite a huge commitment).

LTS is an effort by a 3rd party external company,
what and how they support in LTS is not our problem.

Our python2.7 maintainer has already stated in this thread:
  otoh, I would be fine to have a very reduced set of python2 apps in 
  buster+1, if that's needed.

> > there are other distributions who will create security fixes
> > for the Python 2 interpreter for many years to come).
> 
> There's no such thing (yet?) as a cross-distro security team, unfortunately.

An advantage of code that is dead upstream is that everyone ships the 
same sources.

This makes porting fixes from one distribution to another trivial.

> 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

Re: [Alioth-staff-replacement] alioth deprecation - next steps

[Daniele Nicolodi]

On 26/04/2018 02:42, Andrej Shadura wrote:
> On 26 April 2018 at 10:21, Alexander Wirt  wrote:
>> On Thu, 26 Apr 2018, Andrej Shadura wrote:
>>
>>> Could the steps including taking VCS repos offline be offset by at
>>> least two months? There are too many packages not yet migrated to
>>> Salsa or to Git in general, and completing that by the end of May is
>>> putting too much pressure on the maintainers.
>>
>> Nope, we announced that months, if not years ago.
> 
> That doesn’t seem like a reasonable reply. What was announced is one
> thing, but the plans have to be adjusted to the reality, which is that
> you cannot switch off the VCS hosting by the end of May.

Can you please elaborate on what exactly is blocking those projects to
migrate right away?  I think 5 weeks is a reasonable time to do the
migration and I haven't seen any call for help from maintainers that
feel overwhelmed by the task.  I volunteer to help migrate non-Git
repositories to Git, if that can be of any help.

Cheers,
Dan

Bug#896980: ITP: gemma -- Genome-wide Efficient Mixed Model Association

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: gemma
  Version : 0.97
* URL : http://www.xzlab.org/software.html
* License : GPL-3
  Description : Genome-wide Efficient Mixed Model Association

The package is team-maintained on salsa.debian.org/med-team/gemma.

Bug#896978: RFP: node-http-proxy -- full-featured http proxy for Node.js

[Philip Rinn]

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

* Package name: node-http-proxy
  Version : 1.17.0
  Upstream Author : Charlie Robbins 
* URL : https://github.com/nodejitsu/node-http-proxy
* License : MIT
  Programming Lang: JavaScript
  Description : full-featured http proxy for Node.js

 This Node.js package provides an HTTP programmable proxying library that 
supports
 websockets. It is suitable for implementing components such as reverse proxies
 and load balancers.
 .
 Node.js is an event-based server-side JavaScript engine.


This package is a dependency of shiny-server (which will be maintained by the
Debian-science group). As we assume that this package is of broader interest
for the Node.js community we'd like to see it maintained by someone who is more
into Node.js packaging than we are.




signature.asc
Description: OpenPGP digital signature

Re: Removing Python 2 support in OpenStack [was: Please do not drop Python 2 modules]

[Thomas Goirand]

On 04/26/2018 10:40 AM, Ondrej Novy wrote:
> problem is that nobody want's to cooperate with you, that's all. All
> other arguments are useless. I already explained to you many times what
> is problem.

Excuse my words, but that's plain bullshit. A year ago, I did nothing
for the OpenStack Ocata release, and officially announced that I would
stop doing the work. Then nobody uploaded the release to Debian.

Please stop finger pointing at me anywhere public.

Cheers,

Thomas Goirand (zigo)

Re: Please do not drop Python 2 modules

[Wouter Verhelst]

On Wed, Apr 25, 2018 at 09:16:06AM +0200, Thomas Goirand wrote:
> On 04/24/2018 07:39 AM, Vincent Bernat wrote:
> >  ❦ 23 avril 2018 23:54 +0200, Thomas Goirand  :
> > 
> >> Isn't 10 years of Python 3 enough time for a migration?
> > 
> > Python 3.3, the first release people could reasonably start migrating
> > to, is from 2012. Before that, it was very difficult to have a codebase
> > compatible with Python 2 and Python 3. Debian Wheezy didn't have
> > it. Python 3.4 was released with Debian Jessie (3 years ago). So, people
> > didn't have 10 years to migrate.
> 
> I do remember having done some work to have babel working on Python 3.2.
> It is my opinion that it was already possible to port to 3.2 when it was
> there, and that's one release earlier in Debian (ie: wheezy).

Still, wheezy is from may 2013; that's (soon to be) 5, not 10 years.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Removing Python 2 support in OpenStack [was: Please do not drop Python 2 modules]

[Chris Lamb]

Hi Scott,

> Bullseye will be Django 2.0, which is Python 3 only.

(Indeed. The only complication is that as we rejected having a
seperate source package for Django 2.x can't then upload this
version to unstable. It is, however, available in experimental.)


Regards,

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

Re: Removing Python 2 support in OpenStack [was: Please do not drop Python 2 modules]

[Ondrej Novy]

Hi,

2018-04-26 13:27 GMT+02:00 Scott Kitterman :

> I know very little about the details of OpenStack, but in case a somewhat
> parallel example is useful, that's approximately what Django will do.
> Bullseye will be Django 2.0, which is Python 3 only.  Buster is the pivot
> release where the third party elements of the Django ecosystem almost all
> support Python 3, so transition is possible to make ready for an all
> Python 3
> future. (AIUI anyway, I'm not a Django maintainer)
>

which is perfect for seamless migration. +1

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Re: Removing Python 2 support in OpenStack [was: Please do not drop Python 2 modules]

[Scott Kitterman]

On Thursday, April 26, 2018 10:40:49 AM Ondrej Novy wrote:
...
> we need Buster stable period for Py2->Py3 migration. We are going to be
> ready for Py3-only for Bullseye. Thousands of servers, millions lines of
> code.
...

I know very little about the details of OpenStack, but in case a somewhat 
parallel example is useful, that's approximately what Django will do.  
Bullseye will be Django 2.0, which is Python 3 only.  Buster is the pivot 
release where the third party elements of the Django ecosystem almost all 
support Python 3, so transition is possible to make ready for an all Python 3 
future. (AIUI anyway, I'm not a Django maintainer)

Scott K

Bug#896966: ITP: molecfit --Correcting Observations for Telluric Absorption

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-as...@lists.debian.org

* Package name : molecfit
  Version  : 1.5.1
  Upstream Author  : European Southern Observatory
* URL  : http://www.eso.org/sci/software/pipelines/skytools/molecfit
* License  : GPL-2
  Programming lang : C, Python
  Description  : Correcting Observations for Telluric Absorption

Molecfit is a software tool to correct astronomical observations for
atmospheric absorption features, based on fitting synthetic transmission
spectra to the astronomical data. It can also estimate molecular
abundances, especially the water vapour content of the Earth’s
atmosphere.

This is a new dependency of cpl-plugin-kmos.

I will maintain it within the Debian Astro team. A git repository will
be created at

https://salsa.debian.org/debian-astro-team/molecfit.git

Best regards

Ole

Bug#896955: RFP: node-memoizee -- Complete memoize/cache solution for JavaScript

[Paolo Greppi]

Package: wnpp
Severity: wishlist

* Package name: node-memoizee
  Version : 0.4.12
  Upstream Author : Mariusz Nowak  
(http://www.medikoo.com/)
* URL : https://github.com/medikoo/memoizee#readme
* License : ISC
  Programming Lang: JavaScript
  Description : Complete memoize/cache solution for JavaScript

 Node.js module that provides a complete memoize/cache solution for JavaScript.
 Memoization is a technique to save on memory or CPU cycles when dealing with
 repeated operations.
 It basically wraps function calls and return cached results when the function
 is called with the same arguments.
 .
 Node.js is an event-based server-side JavaScript engine.

This would be useful to make node-debug-fabulous faster (the dependency is
patched away in version 1.1.0-1).

Beware that npm2deb reports that the following dependencies are not in Debian:
- lru-queue
- next-tick
- timers-ext

Re: Removing Python 2 support in OpenStack [was: Please do not drop Python 2 modules]

[Ondrej Novy]

Hi,

2018-04-26 0:49 GMT+02:00 Thomas Goirand :

> > - faster build time (no need to test with Python 2, so less chances
> of
> > build failure).
> >
> > build is done once, customer happiness is for years (buster lifetime).
>
> More work ...
>

more work for machines (build time). I never seen build failure when Py3
tests was fine and Py2 wasn't. Because OpenStack upstream officially
support Py2.


> > - no chance to have any Python 2 packages installed, so we're sure
> we're
> > on a full Python 3 stack (in my current setup, unfortunately some
> Python
> > 2 packages are still pulled). This may go on for another 3 years if
> we
> > don't remove Python 2 now, with the added issue that it will pull
> > *older* version of clients if selecting Python 2 and if we still have
> > them in Buster (ie: case of OpenStack backports on top of Stable).
> >
> > so let's fix packages to not pull Py2 if it's not needed.
>
> More work...
>

we need to fix it in both cases. So it's same work.

> - packaging and decrufting will take a long time, so we'd better start
> > early. Especially if we want to do it the proper way, without
> breaking
> > any reverse (build-)dependency that are outside of OpenStack.
> >
> > more than one release cycle? I'm sure we can do it during Bullseye. And
> > we will do it for non-OS Python packages too. Better is to do removing
> > in earlier phase of development cycle.
>
> And even more work...
>

huh? Doing now or doing later. Same work.


> There's btw a bunch of RC bugs in the BTS that I would love to get
> fixed. Anyone up for contributing that?
>

problem is that nobody want's to cooperate with you, that's all. All other
arguments are useless. I already explained to you many times what is
problem.


> This was part of a non-formal discussion with Ubuntu people, I'm not
> sure it would be right to say with who, but I'm sure you can guess. We
> can discuss with that person again and see what he says now, as maybe
> things have changed since that last conversation. So no, I don't have
> any formal announcement/links to support that it will happen in Ubuntu
> for Rocky.
>

so it's just your opinion.

Now, what needs to be accounted, is how many people use Py2 clients (and
> of course, by that, I mean the Python modules, not the cli). To answer
> that question, we have unfortunately no data except your own case.
>

we have data:
https://qa.debian.org/popcon.php?package=python-openstackclient

Not ideal I know. But better than nothing.

But is the whole set made of just one? Or more? Impossible to say...
> Which is why I asked you how much time it would take for fixing the
> situation in your own company, as it could be a good example. How many
> months do you need? 6 months? A year? It'd be super nice if you could
> explain your use case in more details, and tell what your code base is
> about. Though maybe you can't do it publicly? Or even, maybe you can't
> tell me? I would understand in both cases. But if you can explain, it
> would help understanding at least your use case, which may be similar to
> others.
>

we need Buster stable period for Py2->Py3 migration. We are going to be
ready for Py3-only for Bullseye. Thousands of servers, millions lines of
code.

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Re: [Alioth-staff-replacement] alioth deprecation - next steps

[Alexander Wirt]

On Thu, 26 Apr 2018, Andrej Shadura wrote:

> On 26 April 2018 at 10:21, Alexander Wirt  wrote:
> > On Thu, 26 Apr 2018, Andrej Shadura wrote:
> >
> >> On 17 April 2018 at 13:00, Alexander Wirt  wrote:
> >> > Hi,
> >> >
> >> > as you should be aware, alioth.debian.org will be decommissioned with
> >> > the EOL of wheezy, which is at the end of May. The replacement for
> >> > the main part of alioth, git, is alive and out of beta, you know it
> >> > as salsa.debian.org. If you did not move your git repository yet,
> >> > hurry up, time is running out.
> >> >
> >> > The other important service from the alioth set, lists, moved to a
> >> > new host and is now live at https://alioth-lists.debian.net [1].
> >> > All public list archives moved over too and will continue to exist
> >> > under the old URL.
> >> >
> >> > ## decommissioning timeline
> >> >
> >> > 01.05.18:  DISABLE registration of new users on alioth. Until an 
> >> > improved SSO (GSOC Project, see [2]) is ready, new user registrations
> >> >needed for SSO services will be handled manually. More 
> >> > details on this will follow in a seperate announcement.
> >> > 10.-13.05.18: darcs, bzr and mercurial repositories will be exported as 
> >> > tarballs and made available readonly from a new archive host,
> >> >   details on that will follow.
> >> > 17.-20.05.18: During the Mini-DebConf Hamburg any existing cron jobs 
> >> > will be turned off, websites still on alioth will be disabled.
> >> > 31.05.18: All remaining repositories (cvs, svn and git) will be archived 
> >> > similar to the ones above.
> >> >   The host moszumanska, the home of alioth, will go offline!
> >>
> >> Could the steps including taking VCS repos offline be offset by at
> >> least two months? There are too many packages not yet migrated to
> >> Salsa or to Git in general, and completing that by the end of May is
> >> putting too much pressure on the maintainers.
> > Nope, we announced that months, if not years ago.
> 
> That doesn’t seem like a reasonable reply. What was announced is one
> thing, but the plans have to be adjusted to the reality, which is that
> you cannot switch off the VCS hosting by the end of May.
It is. The plans were announced, I blocked the dates (I am even on vacation
for that) and the system is EOL with end of may. It will go down then. 

Alex

Re: [Alioth-staff-replacement] alioth deprecation - next steps

[Alexander Wirt]

On Thu, 26 Apr 2018, Andrej Shadura wrote:

> On 17 April 2018 at 13:00, Alexander Wirt  wrote:
> > Hi,
> >
> > as you should be aware, alioth.debian.org will be decommissioned with
> > the EOL of wheezy, which is at the end of May. The replacement for
> > the main part of alioth, git, is alive and out of beta, you know it
> > as salsa.debian.org. If you did not move your git repository yet,
> > hurry up, time is running out.
> >
> > The other important service from the alioth set, lists, moved to a
> > new host and is now live at https://alioth-lists.debian.net [1].
> > All public list archives moved over too and will continue to exist
> > under the old URL.
> >
> > ## decommissioning timeline
> >
> > 01.05.18:  DISABLE registration of new users on alioth. Until an improved 
> > SSO (GSOC Project, see [2]) is ready, new user registrations
> >needed for SSO services will be handled manually. More details 
> > on this will follow in a seperate announcement.
> > 10.-13.05.18: darcs, bzr and mercurial repositories will be exported as 
> > tarballs and made available readonly from a new archive host,
> >   details on that will follow.
> > 17.-20.05.18: During the Mini-DebConf Hamburg any existing cron jobs will 
> > be turned off, websites still on alioth will be disabled.
> > 31.05.18: All remaining repositories (cvs, svn and git) will be archived 
> > similar to the ones above.
> >   The host moszumanska, the home of alioth, will go offline!
> 
> Could the steps including taking VCS repos offline be offset by at
> least two months? There are too many packages not yet migrated to
> Salsa or to Git in general, and completing that by the end of May is
> putting too much pressure on the maintainers.
Nope, we announced that months, if not years ago.

Alex

Re: [Alioth-staff-replacement] alioth deprecation - next steps

[Andrej Shadura]

On 17 April 2018 at 13:00, Alexander Wirt  wrote:
> Hi,
>
> as you should be aware, alioth.debian.org will be decommissioned with
> the EOL of wheezy, which is at the end of May. The replacement for
> the main part of alioth, git, is alive and out of beta, you know it
> as salsa.debian.org. If you did not move your git repository yet,
> hurry up, time is running out.
>
> The other important service from the alioth set, lists, moved to a
> new host and is now live at https://alioth-lists.debian.net [1].
> All public list archives moved over too and will continue to exist
> under the old URL.
>
> ## decommissioning timeline
>
> 01.05.18:  DISABLE registration of new users on alioth. Until an improved SSO 
> (GSOC Project, see [2]) is ready, new user registrations
>needed for SSO services will be handled manually. More details on 
> this will follow in a seperate announcement.
> 10.-13.05.18: darcs, bzr and mercurial repositories will be exported as 
> tarballs and made available readonly from a new archive host,
>   details on that will follow.
> 17.-20.05.18: During the Mini-DebConf Hamburg any existing cron jobs will be 
> turned off, websites still on alioth will be disabled.
> 31.05.18: All remaining repositories (cvs, svn and git) will be archived 
> similar to the ones above.
>   The host moszumanska, the home of alioth, will go offline!

Could the steps including taking VCS repos offline be offset by at
least two months? There are too many packages not yet migrated to
Salsa or to Git in general, and completing that by the end of May is
putting too much pressure on the maintainers.

-- 
Cheers,
  Andrej

Re: why hasn't the debian transition freeze been announced or shared in debin testing info. or bits.debian.org ?

[Laura Arjona Reina]

El 26 de abril de 2018 2:20:27 CEST, Luke Faraone  
escribió:
>On 26 April 2018 at 00:16, shirish शिरीष  wrote:
>> I had read
>https://lists.debian.org/debian-devel-announce/2018/04/msg6.html
>> so knew when the transition freeze is going to happen. For a blog
>> post/technical article I wanted to share about the transition freeze
>> and went to https://www.debian.org/releases/testing/ as well as
>> https://bits.debian.org/ but neither seems to have that info.
>>
>> Shouldn't be the milestone including perhaps info. on tentative alpha
>> releases be put somewhere or are the dates subject to change ?
>>
>> If the dates are locked down, it would be nicer to be able to
>> share/link to an official page on debian website rather than just an
>> e-mail.
>
>Messages to debian-devel-announce@ by DPL delegates within the scope
>of their responsibilities are official. This is explicitly called out
>in /releases/testing:
>
>|> In addition, general status reports are posted by the release
>manager to the debian-devel-announce mailing list.
>

We also have microblogged about it (micronews.debian.org) and it will be 
mentioned in the next Debian Project News issue (and thus, mailed and published 
in the website under /News).

BTW, the DPN is open for editions, contributions welcome (and needed).

Cheers
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
Sent with K-9 mail

Re: why hasn't the debian transition freeze been announced or shared in debin testing info. or bits.debian.org ?

[Emilio Pozuelo Monfort]

On 26/04/18 02:20, Luke Faraone wrote:
> On 26 April 2018 at 00:16, shirish शिरीष  wrote:
>> I had read 
>> https://lists.debian.org/debian-devel-announce/2018/04/msg6.html
>> so knew when the transition freeze is going to happen. For a blog
>> post/technical article I wanted to share about the transition freeze
>> and went to https://www.debian.org/releases/testing/ as well as
>> https://bits.debian.org/ but neither seems to have that info.
>>
>> Shouldn't be the milestone including perhaps info. on tentative alpha
>> releases be put somewhere or are the dates subject to change ?
>>
>> If the dates are locked down, it would be nicer to be able to
>> share/link to an official page on debian website rather than just an
>> e-mail.
> 
> Messages to debian-devel-announce@ by DPL delegates within the scope
> of their responsibilities are official. This is explicitly called out
> in /releases/testing:
> 
> |> In addition, general status reports are posted by the release
> manager to the debian-devel-announce mailing list.

Yes. In any case, those dates (as well as links to the announcement) are also
available from https://release.debian.org/

Emilio