[Python-modules-team] Bug#863267: Bug#863267: Associated removals

[Scott Kitterman]

On May 26, 2017 12:30:17 AM EDT, Neil Williams  wrote:
>On Fri, 26 May 2017 04:11:49 +
>Scott Kitterman  wrote:
>
>> I don't see any way to completely resolve this before stretch
>> releases other than removing lava-server.
>
>This is a *django* bug! There is no evidence that lava-server is
>responsible for this - it just has to use multiple django apps. Any
>other system outside Debian using multiple apps will suffer the same
>bug.
>
>Note: once this bug occurs, unless the user is *clearly* warned to look
>for and install 1.8, *data loss* will occur. We have already had one
>user lose data covering 6 months of tests due to this error. The
>process must halt when the exception is seen, the app will be down and
>unusable and users will get a 503.

Sounds like a great input for the release notes.  You should submit it.

If you'd filed this bug months ago, back when you found it, maybe something 
could have been done.  Given short time before release, there's not a lot of 
options.

It really doesn't matter whose fault the bug is.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] Bug#863267: Associated removals

[Neil Williams]

On Fri, 26 May 2017 04:11:49 +
Scott Kitterman  wrote:

> I don't see any way to completely resolve this before stretch
> releases other than removing lava-server.

This is a *django* bug! There is no evidence that lava-server is
responsible for this - it just has to use multiple django apps. Any
other system outside Debian using multiple apps will suffer the same
bug.

Note: once this bug occurs, unless the user is *clearly* warned to look
for and install 1.8, *data loss* will occur. We have already had one
user lose data covering 6 months of tests due to this error. The
process must halt when the exception is seen, the app will be down and
unusable and users will get a 503.



-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgp6tNNrmxA_D.pgp
Description: OpenPGP digital signature
___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#863267: Associated removals

[Scott Kitterman]

I don't see any way to completely resolve this before stretch releases other 
than removing lava-server.

Scott K

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Processed: Miscalculates MigrationHistory dependencies between multiple django apps - regression from 1.8

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reopen 863267
Bug #863267 {Done: Scott Kitterman } [src:python-django] 
python-django: Upgrades from jessie to stretch
Bug reopened
Ignoring request to alter fixed versions of bug #863267 to the same values 
previously set
> retitle 863267 Miscalculates MigrationHistory dependencies between multiple 
> django apps - regression from 1.8
Bug #863267 [src:python-django] python-django: Upgrades from jessie to stretch
Changed Bug title to 'Miscalculates MigrationHistory dependencies between 
multiple django apps - regression from 1.8' from 'python-django: Upgrades from 
jessie to stretch'.
> block 847277 by 863267
Bug #847277 [lava-server] django migrations in jessie require django from 
jessie-backports to upgrade to stretch
847277 was blocked by: 863267
847277 was not blocking any bugs.
Ignoring request to alter blocking bugs of bug #847277 to the same blocks 
previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
847277: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847277
863267: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863267
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Processed: Bug was introduced in 1.3.0-1

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> found 794461 1.3.0-1
Bug #794461 {Done: Thomas Goirand } [python-mock] 
RequirementParseError: Expected version spec in funcsigs; python_version<"3.3" 
at ; python_version<"3.3"
Marked as found in versions python-mock/1.3.0-1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
794461: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794461
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Processed: [bts-link] source package src:python-feather-format

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> #
> # bts-link upstream status pull for source package src:python-feather-format
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> #
> user bts-link-upstr...@lists.alioth.debian.org
Setting user to bts-link-upstr...@lists.alioth.debian.org (was 
bts-link-de...@lists.alioth.debian.org).
> # remote status report for #819997 (http://bugs.debian.org/819997)
> # Bug title: python-feather-format: FTBFS on i386: low is out of bounds for 
> int32
> #  * https://github.com/wesm/feather/issues/105
> #  * remote status changed: open -> closed
> #  * closed upstream
> tags 819997 + fixed-upstream
Bug #819997 [src:python-feather-format] python-feather-format: FTBFS on i386: 
low is out of bounds for int32
Added tag(s) fixed-upstream.
> usertags 819997 - status-open
Usertags were: status-open.
Usertags are now: .
> usertags 819997 + status-closed
There were no usertags set.
Usertags are now: status-closed.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
819997: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819997
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] [bts-link] source package src:python-feather-format

[bts-link-upstream]

#
# bts-link upstream status pull for source package src:python-feather-format
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#

user bts-link-upstr...@lists.alioth.debian.org

# remote status report for #819997 (http://bugs.debian.org/819997)
# Bug title: python-feather-format: FTBFS on i386: low is out of bounds for 
int32
#  * https://github.com/wesm/feather/issues/105
#  * remote status changed: open -> closed
#  * closed upstream
tags 819997 + fixed-upstream
usertags 819997 - status-open
usertags 819997 + status-closed

thanks

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] python-iso3166_0.8.git20170319-1_amd64.changes is NEW

[Debian FTP Masters]

binary:python-iso3166 is NEW.
binary:python3-iso3166 is NEW.
binary:python3-iso3166 is NEW.
binary:python-iso3166 is NEW.
source:python-iso3166 is NEW.

Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid), so please be patient.

Packages are routinely processed through to the archive, and do feel
free to browse the NEW queue[1].

If there is an issue with the upload, you will receive an email from a
member of the ftpteam.

If you have any questions, you may reply to this email.

[1]: https://ftp-master.debian.org/new.html
 or https://ftp-master.debian.org/backports-new.html for *-backports

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Processing of python-iso3166_0.8.git20170319-1_amd64.changes

[Debian FTP Masters]

python-iso3166_0.8.git20170319-1_amd64.changes uploaded successfully to 
localhost
along with the files:
  python-iso3166_0.8.git20170319-1.dsc
  python-iso3166_0.8.git20170319.orig.tar.gz
  python-iso3166_0.8.git20170319-1.debian.tar.xz
  python-iso3166_0.8.git20170319-1_all.deb
  python-iso3166_0.8.git20170319-1_amd64.buildinfo
  python3-iso3166_0.8.git20170319-1_all.deb

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Ian Campbell]

On Thu, 2017-05-25 at 17:41 +1000, Brian May wrote:
> Ian Campbell  writes:
> 
> > Yet 1.10.x is going to be in Stretch, according to [0]? If users
> > want
> > LTS then why aren't we shipping that in our upcoming stable release
> > (whether its instead of or in addition to the latest release)?
> 
> In general the Django LTS releases occur after on a cycle, several
> months after the Debian Freeze.
> 
> Django 1.11 LTS was released in April 2017 for example. Even if we
> could
> get Django 1.11 in the freeze, as Raphael Hertzog was suggesting in
> another email, not sure how the release team would feel about this -
> and
> it would be up to them I think. There may be ways to ease the pain,
> however it would still be up to the release team.
> 
> I seem to recall the same thing happened when Django 1.8 LTS was
> released, Jessie was already in freeze.
> 
> The alternative option is that we use the previous LTS Django
> release. However, that would mean Jessie would still be on Django 1.4,
> which lost upstream support in 2015.

Jessie actually shipped with (non LTS) 1.7 which left support extended
support on December 1 2015, which is not all that different from the
end of extended support for 1.4 which was October 1, 2015.

> Similarly, if Stretch was released with 1.8 LTS (yes I know, this is not
> really an option anymore), Django 1.8 will loose support April next year
> - when Stretch is still supported.

Stretch is actually shipping 1.10 which ends December 2017, compared
with 1.8 which is "at least April 2018", so 1.8 is at least a bit
longer.

> We would basically be releasing Debian with a old LTS version of Django
> that is obsolete before Debian is even released.

The reality is we are shipping non-LTS versions which expire around the
same sort of times as the LTS version du-jour at the time of release.

Ian.

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Adrian Bunk]

On Thu, May 25, 2017 at 05:41:39PM +1000, Brian May wrote:
> Ian Campbell  writes:
> 
> > Yet 1.10.x is going to be in Stretch, according to [0]? If users want
> > LTS then why aren't we shipping that in our upcoming stable release
> > (whether its instead of or in addition to the latest release)?
> 
> In general the Django LTS releases occur after on a cycle, several
> months after the Debian Freeze.
> 
> Django 1.11 LTS was released in April 2017 for example. Even if we could
> get Django 1.11 in the freeze, as Raphael Hertzog was suggesting in
> another email, not sure how the release team would feel about this - and
> it would be up to them I think. There may be ways to ease the pain,
> however it would still be up to the release team.
> 
> I seem to recall the same thing happened when Django 1.8 LTS was
> released, Jessie was already in freeze.
> 
> The alternative option is that we use the previous LTS Django
> release. However, that would mean Jessie would still be on Django 1.4,
> which lost upstream support in 2015.
> 
> Similarly, if Stretch was released with 1.8 LTS (yes I know, this is not
> really an option anymore), Django 1.8 will loose support April next year
> - when Stretch is still supported.
> 
> We would basically be releasing Debian with a old LTS version of Django
> that is obsolete before Debian is even released.

So what are you planning for buster?

The options seem to be:
- 1.11 LTS (already released, supported until April 2020), or
- 2.1 non-LTS (released in August 2018, supported until December 2019)

The full freeze of buster is expected to start in December 2018,
so when 2.2 LTS gets released in April 2019 buster is expected
to be just a few weeks away from being released.

It is pretty obvious that this makes 2.2 LTS a non-option for buster.

I fully agree that neither option is nice, but you have to make that 
decision for buster.

stable is supposed to be stable and backports a workaround when a user
has a good reason for cherry-picking packages from the next stable.

If stable contains the non-LTS version that is less popular in your 
ecosystem and backports contains the more popular LTS, then that's
not how it is supposed to be.

One positive aspect of "old LTS version":

Django 1.11 will be eligible for stretch-backports one or few weeks 
after the release of stretch.

With the "1.11 LTS in buster" option, a user upgrading to 1.11 from 
stretch-backports will get up to 7 years security support for 1.11
from Debian.

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


___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED

[Brian May]

Ian Campbell  writes:

> Yet 1.10.x is going to be in Stretch, according to [0]? If users want
> LTS then why aren't we shipping that in our upcoming stable release
> (whether its instead of or in addition to the latest release)?

In general the Django LTS releases occur after on a cycle, several
months after the Debian Freeze.

Django 1.11 LTS was released in April 2017 for example. Even if we could
get Django 1.11 in the freeze, as Raphael Hertzog was suggesting in
another email, not sure how the release team would feel about this - and
it would be up to them I think. There may be ways to ease the pain,
however it would still be up to the release team.

I seem to recall the same thing happened when Django 1.8 LTS was
released, Jessie was already in freeze.

The alternative option is that we use the previous LTS Django
release. However, that would mean Jessie would still be on Django 1.4,
which lost upstream support in 2015.

Similarly, if Stretch was released with 1.8 LTS (yes I know, this is not
really an option anymore), Django 1.8 will loose support April next year
- when Stretch is still supported.

We would basically be releasing Debian with a old LTS version of Django
that is obsolete before Debian is even released.

Reference: https://www.djangoproject.com/download/
-- 
Brian May 

___
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team