[Python-modules-team] knack 0.7.1-1 MIGRATED to testing

[Debian testing watch]

FYI: The status of the knack source package
in Debian's testing distribution has changed.

  Previous version: 0.6.3-3
  Current version:  0.7.1-1

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

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

[Python-modules-team] python-markdown 3.2.2-1 MIGRATED to testing

[Debian testing watch]

FYI: The status of the python-markdown source package
in Debian's testing distribution has changed.

  Previous version: 3.2.1-1
  Current version:  3.2.2-1

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

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

[Python-modules-team] pyutilib 5.8.0-1 MIGRATED to testing

[Debian testing watch]

FYI: The status of the pyutilib source package
in Debian's testing distribution has changed.

  Previous version: 5.7.3-1
  Current version:  5.8.0-1

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

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

[Python-modules-team] python-django-netfields 1.2.2-2 MIGRATED to testing

[Debian testing watch]

FYI: The status of the python-django-netfields source package
in Debian's testing distribution has changed.

  Previous version: 1.2.2-1
  Current version:  1.2.2-2

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

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

[Python-modules-team] javaproperties 0.7.0-1 MIGRATED to testing

[Debian testing watch]

FYI: The status of the javaproperties source package
in Debian's testing distribution has changed.

  Previous version: 0.6.0-2
  Current version:  0.7.0-1

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

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

[Python-modules-team] python-django-storages is marked for autoremoval from testing

[Debian testing autoremoval watch]

python-django-storages 1.9.1-2 is marked for autoremoval from testing on 
2020-06-01

It is affected by these RC bugs:
959547: python-django-storages: FTBFS: dh_auto_test: error: pybuild --test 
--test-pytest -i python{version} -p 3.8 returned exit code 13


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

[Python-modules-team] python-toml 0.10.1-1 MIGRATED to testing

[Debian testing watch]

FYI: The status of the python-toml source package
in Debian's testing distribution has changed.

  Previous version: 0.10.0-3
  Current version:  0.10.1-1

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

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

[Python-modules-team] python-django-storages 1.9.1-2 MIGRATED to testing

[Debian testing watch]

FYI: The status of the python-django-storages source package
in Debian's testing distribution has changed.

  Previous version: 1.9.1-1
  Current version:  1.9.1-2

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

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

[Python-modules-team] python-sievelib is marked for autoremoval from testing

[Debian testing autoremoval watch]

python-sievelib 1.1.1-3.1 is marked for autoremoval from testing on 2020-06-12

It is affected by these RC bugs:
960577: python-sievelib: python-sievelib FTBFS with python3-pip 20.1


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

[Python-modules-team] Bug#961250: Bug#961250: anorack: incorrect suggestion: a src package -> an src package

[Emmanuel Arias]

Hi,

I open the issue on upstream [0]

[0] https://github.com/jwilk/anorack/issues/5

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El jue., 21 de may. de 2020 a la(s) 22:21, Paul Wise (p...@debian.org) escribió:
>
> Package: anorack
> Version: 0.2.4-1
> Severity: normal
>
> The suggestion "an src" is incorrect since most people will be
> internally translating "src" to "source" and pronouncing that rather
> than pronouncing each individual character as in "an s.r.c.".
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing-debug
>   APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
> 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
> 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), 
> LANGUAGE=en_AU:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages anorack depends on:
> ii  espeak-ng  1.50+dfsg-6
> ii  python33.8.2-3
>
> anorack recommends no packages.
>
> anorack suggests no packages.
>
> -- no debconf information
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
> ___
> Python-modules-team mailing list
> Python-modules-team@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

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

[Python-modules-team] Processed: bug 961250 is forwarded to https://github.com/jwilk/anorack/issues/5

[Debian Bug Tracking System]

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

> forwarded 961250 https://github.com/jwilk/anorack/issues/5
Bug #961250 [anorack] anorack: incorrect suggestion: a src package -> an src 
package
Set Bug forwarded-to-address to 'https://github.com/jwilk/anorack/issues/5'.
> thanks
Stopping processing here.

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

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

[Python-modules-team] Bug#961250: anorack: incorrect suggestion: a src package -> an src package

[Paul Wise]

Package: anorack
Version: 0.2.4-1
Severity: normal

The suggestion "an src" is incorrect since most people will be
internally translating "src" to "source" and pronouncing that rather
than pronouncing each individual character as in "an s.r.c.".

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages anorack depends on:
ii  espeak-ng  1.50+dfsg-6
ii  python33.8.2-3

anorack recommends no packages.

anorack suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part
___
Python-modules-team mailing list
Python-modules-team@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Processed: python-django-registration: Not compatible with Django 3.x

[Debian Bug Tracking System]

Processing control commands:

> affects -1 mini-buildd
Bug #961239 [src:python-django-registration] python-django-registration: Not 
compatible with Django 3.x
Added indication that 961239 affects mini-buildd

-- 
961239: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961239
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

[Python-modules-team] Processed: python-django-crispy-forms: Not compatible with Django 3.x

[Debian Bug Tracking System]

Processing control commands:

> affects -1 django-filter
Bug #961242 [src:python-django-crispy-forms] python-django-crispy-forms: Not 
compatible with Django 3.x
Added indication that 961242 affects django-filter

-- 
961242: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961242
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

[Python-modules-team] Bug#961242: python-django-crispy-forms: Not compatible with Django 3.x

[Chris Lamb]

Source: python-django-crispy-forms
Version: 1.7.2-2
Severity: normal
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x
Control: affects -1 django-filter

Dear maintainer,

The version of Django experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version and 114
of these build & pass their testsuite successfully. For more
information, see:

http://bugs.debian.org/960890

Please use the above bug report for queries or questions regarding
Django 3.x that are not specific to this particular package in order
to reduce duplicated work across all of the bugs.

Whilst python-django-crispy-forms itself builds from source, it causes
other packages (eg. django-filter) to FTBFS.

Here is the FTBFS from django-filter:

  […]

  --
  Traceback (most recent call last):
File 
"/home/lamby/temp/cdt.20200517001459.aCZ5FBFbhk.ags.lamby-debian-experimental.python3-django-filters/django-filter-2.1.0/tests/test_views.py",
 line 56, in test_view_with_model_no_filterset
  self.assertContains(response, b)
File "/usr/lib/python3/dist-packages/django/test/testcases.py", line 454, 
in assertContains
  self.assertTrue(real_count != 0, msg_prefix + "Couldn't find %s in 
response" % text_repr)
  AssertionError: False is not true : Couldn't find 'Enders Game' in 
response
  
  ==
  FAIL: test_view (tests.test_views.GenericFunctionalViewTests)
  --
  Traceback (most recent call last):
File 
"/home/lamby/temp/cdt.20200517001459.aCZ5FBFbhk.ags.lamby-debian-experimental.python3-django-filters/django-filter-2.1.0/tests/test_views.py",
 line 146, in test_view
  self.assertContains(response, b)
File "/usr/lib/python3/dist-packages/django/test/testcases.py", line 454, 
in assertContains
  self.assertTrue(real_count != 0, msg_prefix + "Couldn't find %s in 
response" % text_repr)
  AssertionError: False is not true : Couldn't find 'Enders Game' in 
response
  
  --
  Ran 487 tests in 0.688s
  
  FAILED (failures=5, errors=1, skipped=14, expected failures=3)
  Destroying test database for alias 'default'...
  System check identified no issues (0 silenced).
  E: pybuild pybuild:352: test: plugin custom failed with: exit code=1: 
python3.8 ./runtests.py
  dh_auto_test: error: pybuild --test -i python{version} -p 3.8 --system=custom 
"--test-args={interpreter} ./runtests.py" returned exit code 13
  make[1]: *** [debian/rules:21: override_dh_auto_test] Error 25
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20200517001459.aCZ5FBFbhk.ags.lamby-debian-experimental.python3-django-filters/django-filter-2.1.0'
  make: *** [debian/rules:7: build] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

  […]

The full build log is attached.


Regards,

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


django-filter.2.1.0-1.unstable.amd64.log.txt.gz
Description: Binary data
___
Python-modules-team mailing list
Python-modules-team@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#961239: python-django-registration: Not compatible with Django 3.x

[Chris Lamb]

Source: python-django-registration
Version: 2.2-3
Severity: normal
User: python-modules-t...@lists.alioth.debian.org
Usertags: django-3.x
Control: affects -1 mini-buildd

Dear maintainer,

The version of Django experimental is currently 3.0.6-1. I have built
the 153 reverse-dependencies in unstable against this version and 114
of these build & pass their testsuite successfully. For more
information, see:

http://bugs.debian.org/960890

Please use the above bug report for queries or questions regarding
Django 3.x that are not specific to this particular package in order
to reduce duplicated work across all of the bugs.

Whilst python-django-registration itself builds from source, it causes
other packages (eg. mini-buildd) to FTBFS.

Here is the FTBFS from mini-buildd:

  […]

File 
"/home/lamby/temp/cdt.20200517004829.Xc0msV8pPb.ags.lamby-debian-experimental.python3-mini-buildd/mini-buildd-1.1.31/src/mini_buildd/django_settings.py",
 line 168, in pseudo_configure
  django.setup()
File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in setup
  apps.populate(settings.INSTALLED_APPS)
File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 114, in 
populate
  app_config.import_models()
File "/usr/lib/python3/dist-packages/django/apps/config.py", line 211, in 
import_models
  self.models_module = import_module(models_module_name)
File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module
  return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1014, in _gcd_import
File "", line 991, in _find_and_load
File "", line 975, in _find_and_load_unlocked
File "", line 671, in _load_unlocked
File "", line 783, in exec_module
File "", line 219, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/registration/models.py", line 23, in 

  from django.utils.encoding import python_2_unicode_compatible
  ImportError: cannot import name 'python_2_unicode_compatible' from 
'django.utils.encoding' 
(/usr/lib/python3/dist-packages/django/utils/encoding.py)
  
  make[1]: *** [debian/rules:21: override_dh_auto_build] Error 2
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20200517004829.Xc0msV8pPb.ags.lamby-debian-experimental.python3-mini-buildd/mini-buildd-1.1.31'
  make: *** [debian/rules:4: build] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

  […]

The full build log is attached.


Regards,

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


mini-buildd.1.1.31.experimental.amd64.log.txt.gz
Description: Binary data
___
Python-modules-team mailing list
Python-modules-team@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#960899: paramiko: autopkgtests failures

[Brian Murray]

I'm pretty sure its because the configs folder from usptream isn't
included in the package at all.

https://github.com/paramiko/paramiko/tree/master/tests/configs

--
Brian Murray @ubuntu.com

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

[Python-modules-team] Bug#961206: improve sphinx usage for cross building

[Simon McVittie]

On Thu, 21 May 2020 at 13:43:42 +0200, Helmut Grohne wrote:
> A very rough
> sketch for this would be moving sphinx-build and the other tools to a
> new binary package maybe called simply "sphinx". Of course "sphinx"
> would depend on python3-sphinx, but given that sphinx would only cover
> the command line interface, sphinx could be marked Multi-Arch: foreign.
> Does this make sense in principle when one ignores the transition cost?

This would be reversing the recent recommendation to
call `python3 -m sphinx` in preference to `sphinx-build` (e.g. in
 and
). I don't
fully understand what the reason for that recommendation was; does it
still apply?

smcv

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

[Python-modules-team] Bug#961206: improve sphinx usage for cross building

[Helmut Grohne]

Package: python3-sphinx
Version: 2.4.3-2
Severity: wishlist
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

sphinx is becoming ever more popular and these days it is often used for
generating manual pages. That makes it required for building arch:any
packages (as opposed to arch:all *-doc) packages more often and this
affects cross building as a dependency on python3-sphinx is generally
not cross satisfiable. We cannot easily mark python3-sphinx Multi-Arch:
foreign either, so this leaves us in a difficult place.

This bug asks for improving the situation. It comes without a patch as I
seek consensus on how to make this work.

Generally, the rough idea would be marking python3-sphinx Multi-Arch:
foreign. Unfortunately, that is out of question, because the interface
of the python3-sphinx package inludes the sphinx Python module, which
happens to depend on markupsafe via jinja2. Since markupsafe is
architecture-dependent, there is no way to make python3-sphinx
Multi-Arch: foreign.

So the only option for improving the situation is making the interface
"smaller". In essence, this means providing the sphinx module and the
sphinx command line tools via different package names. A very rough
sketch for this would be moving sphinx-build and the other tools to a
new binary package maybe called simply "sphinx". Of course "sphinx"
would depend on python3-sphinx, but given that sphinx would only cover
the command line interface, sphinx could be marked Multi-Arch: foreign.
Does this make sense in principle when one ignores the transition cost?

Now getting there is not trivial. Simply moving sphinx-build an friends
to a new binary package is going to make a lot of packages FTBFS.
Obviously, that's not what we want. So the transition would roughly work
like this:
 1. python3-sphinx starts providing sphinx.
 2. We ask downstream packages to switch their python3-sphinx dependency
to sphinx iff they call it via sphinx-build.  This affects at most
1200 source packages. A lot of them are python modules and could be
quickly fixed in git by some DPMT member. The actual affected
packages could be determined with a partial archive rebuild.
 3. After a while and getting that number of 1200 down a little, we
could start a MBF at severity normal.
 4. Once the number of broken rdeps is down to around 100, we could do
the actual split and bump the remaining bugs to rc severity.

I doubt that this would finish in time for bullseye.

This does not solve cross building for advanced sphinx users where
sphinx extensions are involved. However that is not the majority of
sphinx users.

Since moving alternatives from one binary package to another is
difficult, I wonder whether we can rid of it now. Doing so would greatly
easy the projected steps.

Now the questions are:
 * Is the requested sphinx (the cli) and python3-sphinx (the module)
   split a reasonable thing to do?
 * Is the transition plan a reasonable thing to do?
 * Is this transition worth the cost (cross building vs changing lots of
   packages)?
 * Can we get rid of the use of update-alternatives?

Helmut

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

[Python-modules-team] Bug#955612: python3-pyqt5: Cannot import Qt from QtCore

[Dmitry Shachnev]

Control: tags -1 moreinfo

Hi,

On Fri, Apr 03, 2020 at 11:40:26AM +0200, mathieu wrote:
> I tried to run this sample code:
>
> #! /usr/bin/python3
> from PyQt5.QtCore import Qt
> print("Hello")
>
> And I instantly get this error:
>
> Traceback (most recent call last):
>   File "./test-1.py", line 5, in 
> from PyQt5.QtCore import Qt
> ImportError: 
> /usr/lib/python3/dist-packages/PyQt5/QtCore.cpython-37m-x86_64-linux-gnu.so:
> symbol _ZN23QOperatingSystemVersion11MacOSMojaveE version Qt_5 not defined in 
> file libQt5Core.so.5
> with link time reference

It is strange, because this symbol is present in libqt5core5a since version
5.11.2+dfsg-1.

Can it be that you have a custom Qt installation somewhere? E.g. from the
Qt website or installed with some other package manager?

Can you check where libQt5Core.so.5 points to in the output of this command?

ldd /usr/lib/python3/dist-packages/PyQt5/QtCore.cpython-37m-x86_64-linux-gnu.so

--
Dmitry Shachnev


signature.asc
Description: PGP signature
___
Python-modules-team mailing list
Python-modules-team@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Processed: Re: Bug#955612: python3-pyqt5: Cannot import Qt from QtCore

[Debian Bug Tracking System]

Processing control commands:

> tags -1 moreinfo
Bug #955612 [python3-pyqt5] python3-pyqt5: Cannot import Qt from QtCore
Added tag(s) moreinfo.

-- 
955612: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955612
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

[Python-modules-team] Processed: Re: Bug#960073: Package:python-pyqt5 Run the example code with Trace and crash (SIGABRT)

[Debian Bug Tracking System]

Processing control commands:

> tags -1 moreinfo
Bug #960073 [python-pyqt5] Package:python-pyqt5 Run the example code with Trace 
and crash (SIGABRT)
Added tag(s) moreinfo.

-- 
960073: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960073
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

[Python-modules-team] Bug#960073: Package:python-pyqt5 Run the example code with Trace and crash (SIGABRT)

[Dmitry Shachnev]

Control: tags -1 moreinfo

Hi!

On Sat, May 09, 2020 at 10:48:42AM +0800, pengzongli wrote:
> When ever I run the example code on the arm machine, It results in the error
> below:
>
> / Could not initialize GLX/
> /Aborted (core dumped)/
> but when I run the same example code on the x86 machine(Debian 8.3.0-6),
> there is no error.

This is because the OpenGL hardware/drivers are different on ARM and x86.

I think I have seen similar issues before with old Qt versions. Can you
please check the following two things:

- Whether installing libglvnd-dev package helps?
- Whether exporting QT_XCB_GL_INTEGRATION=xcb_egl environment variable helps?

--
Dmitry Shachnev


signature.asc
Description: PGP signature
___
Python-modules-team mailing list
Python-modules-team@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

[Python-modules-team] Bug#958979: marked as done (azure-cli: az ecr login crash)

[Debian Bug Tracking System]

Your message dated Thu, 21 May 2020 09:33:37 +
with message-id 
and subject line Bug#958979: fixed in azure-cli 2.6.0-1
has caused the Debian Bug report #958979,
regarding azure-cli: az ecr login crash
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
958979: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958979
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: azure-cli
Version: 2.0.81+ds-5
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

$ az acr login  
The 'azure-devops' extension is not compatible with this version of the CLI.
You have CLI core version 2.0.81 and this extension requires a min of 2.2.0.

  
The command failed with an unexpected error. Here is the traceback:

cannot import name 'BlockBlobService' from 'azure.storage.blob' 
(/usr/lib/python3/dist-packages/azure/storage/blob/__init__.py)
Traceback (most recent call last):  

  
  File "/usr/lib/python3/dist-packages/knack/cli.py", line 206, in invoke   

  
cmd_result = self.invocation.execute(args)  

  
  File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", 
line 528, in execute
 
self.commands_loader.load_arguments(command)

  
  File "/usr/lib/python3/dist-packages/azure/cli/core/__init__.py", line 299, 
in load_arguments
self.command_table[command].load_arguments()  # this loads the arguments 
via reflection
  File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", 
line 291, in load_arguments
super(AzCliCommand, self).load_arguments()
  File "/usr/lib/python3/dist-packages/knack/commands.py", line 97, in 
load_arguments
cmd_args = self.arguments_loader()
  File "/usr/lib/python3/dist-packages/azure/cli/core/__init__.py", line 496, 
in default_arguments_loader
op = handler or self.get_op_handler(operation, 
operation_group=kwargs.get('operation_group'))
  File "/usr/lib/python3/dist-packages/azure/cli/core/__init__.py", line 536, 
in get_op_handler
op = import_module(mod_to_import)
  File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1014, in _gcd_import
  File "", line 991, in _find_and_load
  File "", line 975, in _find_and_load_unlocked
  File "", line 671, in _load_unlocked
  File "", line 783, in exec_module
  File "", line 219, in _call_with_frames_removed
  File 
"/usr/lib/python3/dist-packages/azure/cli/command_modules/acr/custom.py", line 
10, in 
from ._utils import (
  File 
"/usr/lib/python3/dist-packages/azure/cli/command_modules/acr/_utils.py", line 
28, in 
from ._archive_utils import upload_source_code, check_remote_source_code
  File 
"/usr/lib/python3/dist-packages/azure/cli/command_modules/acr/_archive_utils.py",
 line 15, in 
from azure.storage.blob import BlockBlobService
ImportError: cannot import name 'BlockBlobService' from 'azure.storage.blob' 
(/usr/lib/python3/dist-packages/azure/storage/blob/__init__.py)


Note that latest azure-cli version on github is 2.4.0 which may fix
this issue.

All the best


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.5.0-2-amd64 (SMP w/16 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:fr (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages azure-cli depends on:
ii  python33.8.2-3
ii  python3-azure-cli  2.0.81+ds-5

azure-cli recommends no packages.

azure-cli suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
Source: azure-cli

[Python-modules-team] azure-cli_2.6.0-1_source.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 21 May 2020 09:37:29 +0100
Source: azure-cli
Architecture: source
Version: 2.6.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Python Modules Team 

Changed-By: Luca Boccassi 
Closes: 958979 959630
Changes:
 azure-cli (2.6.0-1) unstable; urgency=medium
 .
   * Merge tag 'azure-cli-2.6.0' into debian/sid
 (Closes: #959630, #958979)
   * Drop patches, merged upstream
   * Exclude new tests that require working connection to Azure
   * Patch unit test to avoid global import of test module
   * Add new build-deps for tests
Checksums-Sha1:
 13dbc94fbb8b5eb70a304758b7fe0fe5560cf66c 2863 azure-cli_2.6.0-1.dsc
 88ac9cadfe883df8e9533297ec84f6b30cccacbd 39714446 azure-cli_2.6.0.orig.tar.gz
 3cb1c23f47591cf62a017385d8f7d15da1f5566e 5444 azure-cli_2.6.0-1.debian.tar.xz
 823faee927edd5330d11b34e72f6511d6d203bb6 7824 
azure-cli_2.6.0-1_source.buildinfo
Checksums-Sha256:
 7fc9d241794321d9b07a892a3c32134fe70930eadbc1f5cb1c7d9d5824d07700 2863 
azure-cli_2.6.0-1.dsc
 dd943750f077fb185c89d94063946e2b5e500d4f979e78707b3231d633ee027a 39714446 
azure-cli_2.6.0.orig.tar.gz
 7ef4f44edf9513c6de6bf1486ef8f8a5f9ae826142575e8029963d8d1e7c5a17 5444 
azure-cli_2.6.0-1.debian.tar.xz
 3d215e2c18062de0ce9025fb8316e336fd5b798f88310a458a161d3e69c3b32b 7824 
azure-cli_2.6.0-1_source.buildinfo
Files:
 6fcbf18e7b4fbc272523a1a5d8c887b7 2863 python optional azure-cli_2.6.0-1.dsc
 072c7fab59c137e277542ee6ccdf6be8 39714446 python optional 
azure-cli_2.6.0.orig.tar.gz
 f37c2d7f2340c5f5f589ed50409fc69f 5444 python optional 
azure-cli_2.6.0-1.debian.tar.xz
 627f4c3ce339bb197b9b51761dc5b970 7824 python optional 
azure-cli_2.6.0-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEE6g0RLAGYhL9yp9G8SylmgFB4UWIFAl7GRT0RHGJsdWNhQGRl
Ymlhbi5vcmcACgkQSylmgFB4UWKfDAf/XyRizf8UPIzOoiMUauk8EGssJT9KNEws
jnMun/Frk02o2rzfoYHNy0HrHOCgucsLmo6w6kVj3mZWBYgqAO2ZLYc5K5Pnqbff
MSBHzb5cAPffIDoXwjqqrnBiMBLDtNKb2UvhU1hkEdlujwTPvEWPYkzClzV9Ly4J
38HDZlJrOl63mL3RaZ+xwaEK/QrF4wnTCkZAD3w5kRZJQ2qeJB/JpP6cFr0vjLUR
c1XYB/Q0jIZdEj1I32guKiV5qqgJQXpJFee0O9XBQx7o5rvprAENBzmrd+vyR1vU
NgcgbW/9YSH1r7moj1t9rz8sns4s2lh/EghRVZ4Zp9s6KXmu0mbezA==
=GnbH
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

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

[Python-modules-team] Processing of azure-cli_2.6.0-1_source.changes

[Debian FTP Masters]

azure-cli_2.6.0-1_source.changes uploaded successfully to localhost
along with the files:
  azure-cli_2.6.0-1.dsc
  azure-cli_2.6.0.orig.tar.gz
  azure-cli_2.6.0-1.debian.tar.xz
  azure-cli_2.6.0-1_source.buildinfo

Greetings,

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

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