Bug#1062257: [Debian-iot-maintainers] Bug#1062257: libcoap3: NMU diff for 64-bit time_t transition
Hello Steve, Am 31.01.24 um 21:59 schrieb Steve Langasek: ... Please find the patch for this NMU attached. If you have any concerns about this patch, please reach out ASAP. ^^ Although this package will be uploaded to experimental immediately, there will be a period of several days before we begin uploads to unstable; so if information becomes available that your package should not be included in the transition, there is time for us to amend the planned uploads. I'm a bit puzzled and disappointed. libcopap3 isn't a package that is within the QA group nor is it bit rotting. What is the rationale behind rising a bug report at 9:51pm my time and firing a *direct* NMU upload just 11min later (according to the time stamps from the emails)? I as the uploader for libcoap have no chance to do any action on this bug report! This behavior I'm not expecting within Debian. What are the plans now with forwarding the underlying issue to upstream? Upstream is very responsive and I've good contacts to the upstream authors, but who is doing this work now? I read the wiki page mentioned from the initial email again, also there I can't find a written plan that would explain me why the bug reporting together with a direct upload did happen. I see no plan there what will happen on what time. Why no usual muss bug filling did happen so groups and maintainers would have some knowledge about these planned changes? BTW: I've no problem with the technical thing what is happen, but I need to deal also with other things too like a CVE fix for libcopa3. -- Regards Carsten
Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
Hello Julian, Am 04.01.24 um 10:23 schrieb Julian Gilbey: ... The build of src:flask is depending on python3-werkzeug >= 3.x, which has itself a dependency on python3-markupsafe, so if you spot a missing direct dependency I'm interested how this comes to play as Markupsafe should be around at build time. In the debian/experimental branch of python-werkzeug, debian/control does not mention python3-markupsafe, but it should do. hmm, you were talking about Werkzeug, I was within the src:flask package. A bit of misunderstanding. If you spot a issue in src:python-werkzeug than of course that's great you fixed this! -- Regards Carsten
Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
Hello Julian,
Am 03.01.24 um 22:22 schrieb Julian Gilbey:
Just to throw in: these werkzeug failures are also causing a similar
FTBFS in debugpy; I've temporarily addressed it by skipping these unit
tests, but that's not a great solution.
I just took a quick look at upgrading the unstable/testing version of
werkzeug to 2.3.8 in the meantime. It was pretty quick, and the
package tests all pass. Shall I upload it to unstable?
in the end it's up to you. I personally still see no real gain in doing
such a version bump if we could spend the same time on fixing issues we
currently see for Flask/Werkzeug >= 3.x given that we need to migrate
any way in a not to far future. Why spend now time on things that could
happen already within the past 6 months? What do we really gain?
And, in case you decide to upload Werkzeug 2.3.8, my guess is you will
see almost the same fallout as that is still visible for the both
packages with the version bump to 3.x in experimental. With one
exception, it will produce pressure to fix out the issues we seen until
now even more.
I worked on a lot of packages that had FTBFS or test suite issues in the
past 2-3 weeks, the current queue of outstanding packages for
Flask/Werkzeug 3.x is down to 5 packages.
I've seen other Python team members who did also some upload to fix
packages, thank you all for working on that.
https://qa.debian.org/excuses.php?experimental=1=python-werkzeug
https://qa.debian.org/excuses.php?experimental=1=flask
flask-dance (python-werkzeug)
I've done several attempts to get it build with the newer versions, it's
tricky and in my opinion the upstream package isn't really ready for the
newer versions.
Would need open a upstream issue about the problems to get that addressed.
onionshare (python-werkzueg)
Did not look that much yet into the culprit, might be easy to fix.
https://github.com/onionshare/onionshare/pull/1677
It's tiring to work on a active upstream project that did the last
version update now more than one year ago.
beets (flask)
Fixed locally, waiting on response from Stefano due missing commits in
the Salsa tree.
flask-dance (flask)
Same as above.
flask-socketio (flask)
Might be fixed by a newer upstream version, I opened a wishlist bug
about updating (http://bugs.debian.org/1059538). Maybe someone can cross
check?
ironic-inspector (flask)
Did not look deep into that yet. Might be fixed by a newer available
upstream version. The package currently is marked for auto removal on
25th January, I guess Thomas Goirand is happily taking any help on this
package.
(Incidentally, while doing this, I spotted one bug with the current
experimental version: it is missing a Build-Depends on
python3-markupsafe.)
The only requirement for Markupsafe in Flask 3.0.0 is listed in
requirements/tests-pallets-min{.*}.
The build of src:flask is depending on python3-werkzeug >= 3.x, which
has itself a dependency on python3-markupsafe, so if you spot a missing
direct dependency I'm interested how this comes to play as Markupsafe
should be around at build time.
--
Regards
Carsten
Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
Hello Gregor, Am 22.12.23 um 00:04 schrieb Gregor Riepl: My point was that if, for whatever reason, werkzeug 3.0.1 is not yet fit for release, it should be enough to upgrade to 2.3.5 to address these unit test failures. I did come to the conclusion that Werkzeug 2.3.x has some bigger changes that will break most of the existing packages in some way. The main differences to Werkzeug 3.x than isn't that big. flask-login got recent updates which so far I've seen will fix these issues in the test suite. So if you want to push things further try to update/patch flask-login to a recent version targeting experimental. Just rebuilding flask-login against the version of python3-werkzeug in experimental will not fix the problems, so also not an intermediate update to 2.3.5, Python 3.12 is now very strict about deprecation warnings. That doesn't make any sense to me. These deprecations are obviously in werkzeug and not flask-login. Why would changes in flask-login fix them? Because a updated flask-login and other (updated) packages have also underlying changes that require than a updated package of Werkzeug. And some upstream projects did change their source in a way so they can deal different versions of Werkzeug. So a usual update is magical fixing build issues we did have in older versions against recent Flask/Werkzeug versions. I was able to fix not all of the current fallout, but quite a few of them. -- Regards Carsten
Bug#1058327: python-limits: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
Control: reassign -1 python3-protobuf 3.21.12-8 Control: affects -1 python-limits Dear maintainer, reassigning this issue as the current problem is happen in the package python3-protobuf from my current POV. The relevant part seems to this: > /usr/lib/python3/dist-packages/google/protobuf/internal/api_implementation.py:104: > in > from google.protobuf.pyext import _message > E SystemError: returned a result with an > exception set Trying to search for this error message got no useful findings. The only reports about similar issue where about some missing linking in some C++ library that is used by python3-protobuf. Maybe now the current seen issue is related to something similar. I tried also the current version of python3-protobuf from experimental 3.25-1 but the output is completly the same as with the version from unstable. Is it possible to see waht is within the 'exception set' mentione din the error output? OTOH I can call the import within a running python3 shell in testing without problems. So maybe some environment is missing or wrong withing the package build setup? Regards Carsten Am Tue, Dec 12, 2023 at 09:24:16AM +0100 schrieb Lucas Nussbaum: > Source: python-limits > Version: 3.6.0-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20231212 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > make[1]: Entering directory '/<>' > > dh_auto_build > > I: pybuild base:310: /usr/bin/python3.12 setup.py build > > running build > > running build_py > > creating /<>/.pybuild/cpython3_3.12_limits/build/limits > > copying limits/__init__.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits > > copying limits/version.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits > > copying limits/limits.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits > > copying limits/_version.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits > > copying limits/strategies.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits > > copying limits/errors.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits > > copying limits/util.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits > > copying limits/typing.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits > > creating /<>/.pybuild/cpython3_3.12_limits/build/limits/storage > > copying limits/storage/__init__.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits/storage > > copying limits/storage/redis_sentinel.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits/storage > > copying limits/storage/etcd.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits/storage > > copying limits/storage/memory.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits/storage > > copying limits/storage/base.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits/storage > > copying limits/storage/memcached.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits/storage > > copying limits/storage/mongodb.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits/storage > > copying limits/storage/redis_cluster.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits/storage > > copying limits/storage/registry.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits/storage > > copying limits/storage/redis.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits/storage > > creating /<>/.pybuild/cpython3_3.12_limits/build/limits/aio > > copying limits/aio/__init__.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits/aio > > copying limits/aio/strategies.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits/aio > > creating > > /<>/.pybuild/cpython3_3.12_limits/build/limits/aio/storage > > copying limits/aio/storage/__init__.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits/aio/storage > > copying limits/aio/storage/etcd.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits/aio/storage > > copying limits/aio/storage/memory.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits/aio/storage > > copying limits/aio/storage/base.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits/aio/storage > > copying limits/aio/storage/memcached.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits/aio/storage > > copying limits/aio/storage/mongodb.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits/aio/storage > > copying limits/aio/storage/redis.py -> > > /<>/.pybuild/cpython3_3.12_limits/build/limits/aio/storage > > running egg_info > > creating limits.egg-info > > writing limits.egg-info/PKG-INFO > > writing dependency_links to limits.egg-info/dependency_links.txt > > writing requirements to limits.egg-info/requires.txt > > writing top-level names to limits.egg-info/top_level.txt > > writing manifest file 'limits.egg-info/SOURCES.txt' > > reading manifest file 'limits.egg-info/SOURCES.txt' > > reading manifest template 'MANIFEST.in'
Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
Hello Gregor, Am Thu, Dec 21, 2023 at 02:00:40PM +0100 schrieb Gregor Riepl: > I don't see any other errors in the log except for the ast.Str deprecation > warnings, and they all come from python-werkezug and not this package. > > Reassiging the bug. > Upstream has already fixed this in in 2.3.5, by the way: > https://github.com/pallets/werkzeug/issues/2704 > > I can see that 3.0.1 is currently in experimental, but it would be enough to > upgrade to the latest 2.x to fix this issue. this makes not really sense to me. Flask 3.0.0 and Werkzeug 3.0.0 was released on 09-30-2023, so almost three months before. Putting energy into Flask 2.3.5 and fix other related packages while 3.x is on the way is a waste of time in my eyes as we would need to work at least twice on some packages... flask-login got recent updates which so far I've seen will fix these issues in the test suite. So if you want to push things further try to update/patch flask-login to a recent version targeting experimental. Just rebuilding flask-login against the version of python3-werkzeug in experimental will not fix the problems, so also not an intermediate update to 2.3.5, Python 3.12 is now very strict about deprecation warnings. Regards Carsten
Bug#1058698: mozilla-devscripts should be removed from testing/unstable
Hello Mechtilde, Am Thu, Dec 14, 2023 at 07:09:16PM +0100 schrieb Mechtilde: > Hello Mathias, > > thanks for the hint, > > At this time mozilla-devscript is needed when you want to build > Mozilla-AddOns from the *.xpi. > > So we need to elaborate another way to do it. I've dropped mozilla-devscripts as an dependency for thunderbird long ago. To get the l10n XPI files creatable I picked up the main part of mozilla-devscripts, the shell script xpi-pack.sh, and placed it within the debian/ folder. https://salsa.debian.org/mozilla-team/thunderbird/-/commit/b31360b05e048826571245a2fda26d56592da435 We call this shell script then directly in debian/rules, it's quite simple and straight forward to use. https://salsa.debian.org/mozilla-team/thunderbird/-/blob/debian/sid/debian/rules#L134 I think shipping this shell script now in only a few source packages is acceptable, otherwise we would need to fix mozilla-devscripts with a bit effort for not really big gain. Another option could be to move the XPI package build functionaliy into some debhelper package, but I haven't looked really seriously into any option. Regards Carsten
Bug#1058575: glogic: Fails to start due AttributeError
Package: glogic
Version: 2.6-6
Severity: serious
Dear Maintainer,
qlogic isn't usable any more in unstable and testing.
It fails to start as a calling of a Python function raises a
AttributeError.
$ glogic
/usr/lib/python3/dist-packages/glogic/MainFrame.py:4: PyGIWarning: Gtk was
imported without specifying a version first. Use gi.require_version('Gtk',
'4.0') before import to ensure that the right version gets loaded.
from gi.repository import Gtk, Gdk, GdkPixbuf
Traceback (most recent call last):
File "/usr/bin/glogic", line 20, in
from glogic.MainFrame import MainFrame
File "/usr/lib/python3/dist-packages/glogic/MainFrame.py", line 18, in
themed_icons = Gtk.IconTheme.get_default()
^
AttributeError: type object 'IconTheme' has no attribute 'get_default'
Rgards
Carsten
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.5.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages glogic depends on:
ii gir1.2-gtk-3.03.24.38-6
ii python3 3.11.4-5+b1
ii python3-gi3.46.0-1+b1
ii python3-gi-cairo 3.46.0-1+b1
glogic recommends no packages.
Versions of packages glogic suggests:
ii fonts-liberation 1:2.1.5-3
-- no debconf information
Bug#1042609: marked as pending in sphinxcontrib-mermaid
Control: tag -1 pending Hello, Bug #1042609 in sphinxcontrib-mermaid reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/sphinxcontrib-mermaid/-/commit/13670cdee62562c3fd74643f81639fa0dd449c1a Rebuild patches from patch queue branch Added patches: README.rst-Adopt-autoclasstree-examples-to-Sphinx-7.2.patch autoclassdiag.py-Use-sphinx.errors-for-importing.patch Closes: #1042609 (this message was generated automatically) -- Greetings https://bugs.debian.org/1042609
Bug#1055106: marked as pending in django-tables
Control: tag -1 pending Hello, Bug #1055106 in django-tables reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/django-tables/-/commit/52c39aaa33729f9183f89da15c5dbdd56c8972c4 autopkgtest: Adjust test syntax The root cause is that url() function was deprecated since Django 3.1 [3] and removed in Django 4.x Closes: #1055106 (this message was generated automatically) -- Greetings https://bugs.debian.org/1055106
Bug#1051368: python3-selenium: Selenium Python still can't find chromedriver
Control: tags -1 severity normal Hello Jonathan, Am Wed, Sep 06, 2023 at 04:37:28PM -0400 schrieb Jonathan Kamens: > Opening a new ticket since bug 1050378 is resolved and I don't know > how to reopen a resolved ticket (nor do I know if it is even possible > for me to reopen a resolved ticket). https://www.debian.org/Bugs/server-control#reopen if you use 'bts' this would become the following CLI command: $ bts 1050378 reopen If you prefer to use a MTA ensure to include the following line at the very beginning of the body. reopen 1050378 > python3-selenium 4.12.0+dfsg-1 still doesn't work. > > I get this when I try to create a selenium.webdriver.Chrome object: > > selenium.common.exceptions.NoSuchDriverException: Message: Unable to obtain > driver for chrome using Selenium Manager.; For documentation on this error, > please visit: > https://www.selenium.dev/documentation/webdriver/troubleshooting/errors/driver_location > > The ChangeLog for this release claims: > > * [5b22b76] d/README.Debian: Add section about the Selenium Manager > * [25b0d5f] d/NEWS moved to d/python-selenium.NEWS > (Closes: #1050378) > > But neither of those files exists in the python3-selenium package. Was > there an intention to add them to the package that wasn't followed > through on? This is indeed a issue, both file should be within the package python3-selenium but are not in 4.12.0-1. This slipped somehow through. The file are moved now into the correct binary package. > Incidentally, I took a look at README.Debian in the source package and > there are some issues with the text that may be worth fixing as well. > In particular: > > >While writing it's not packaged for Debian. In order to make python3-selenium > > I suggest changing "While writing" (which is not really an idiom that > is used in English) to "At this time". > > >usable with this new circumstance you will need to adjust your source in a > >way to choose the used driver directly and skip the calling of the manager > >code in Selenium. Please have a look at the following example how to archive > > I think you mean to say "achieve" here rather than "archive". Correct, I'm not a native english speaking person and all spelling and grammar tools do not not detect all common mistakes, I fixed the relevant parts which will get included in a next upload. > In any case I do not believe that documenting this deficiency in > README.Debian, even if/when it is included in the package, is a > sufficient fix for the issue. The issue IMO should remain unresolved > until Selenium Manager is properly packaged for Debian. And then? Who will package the required package? I'm not tend to do this. And adding at minimum two lines of additional code to your project/code/application that is intended to be running on a Debian system isn't a big thing to me. If you rely on Selenium Manager you should fill a RFP issue I suggest. If you think the problem (and also the possible solutions) aren't well enough explained and to less documentation is provided how to work around the new requirement for Selenium Manager is now needed as a middle layer we are happy to get suggestions and text snippets how this can be improved. To find out how to set the driver interface manually instead by the Selenium Manager took me about 30min on searching with my preferred search engine. I'm sure others will be able to find quite the same in a similar time. So no, I don't think your report is of severity grave nor is python3-selenium within Debian not working currently. Regards Carsten
Bug#1033667: verilator: Uninstallable in sid because of ${sphinxdoc:Built-Using} dependency
Hello Dimitry,
Am Wed, Mar 29, 2023 at 09:10:17PM +0300 schrieb Dmitry Shachnev:
> In a clean sid chroot, verilator is not installable:
...
> This is because that package has ${sphinxdoc:Built-Using} among its
> dependencies.
>
> That substitution variable is intended to be used in Built-Using field of
> architecture-dependent packages, NOT in Depends field.
>
> I have created a merge request [1] on salsa to fix this.
>
> [1]: https://salsa.debian.org/electronics-team/verilator/-/merge_requests/3
nice catch!
Thanks also for preparing a patch/MR on this!
I've to admit I haven't looked that much on th existing structure in
d/control while working on verilator weeks ago as the package could be
build successfully in the past.
Will have a look on this the next days!
Regards
Carsten
Bug#1032044: marked as pending in python-fastjsonschema
Control: tag -1 pending Hello, Bug #1032044 in python-fastjsonschema reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-fastjsonschema/-/commit/efd6ecf7ffee4a07ad02988f6a8076586bb19d75 autopkgtest: Add additional needed package Adding the package python3-pytest-benchmark to the list of depending packages for running the test. Closes: #1032044 (this message was generated automatically) -- Greetings https://bugs.debian.org/1032044
Bug#1031541: thunderbird: Thunderbird depends on obsolete package
Control: severity -1 normal Hello Abdallah, Am 18.02.23 um 09:37 schrieb Abdallah Yves Lambert: Package: thunderbird Version: 1:104.0~b2-1 Severity: grave Justification: renders package unusable I don't think so. Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? upgrding system, I could not remove libicu71 which is obsolete, because thunderbird 1:104.0~b2-1 depends on it (the conflict resolver suggest to downgrade thunderbird) The version you use is only available in experimental, and this for a very long time as the thunderbird package can't get updated to more recent versions for various reasons. Currently I don't think it makes sense to rebuild this rather old version to use a newer icu version, but you could do this by yourself e.g. if you really want to stay on this version. Otherwise I suggest to downgrade thunderbird and use the version available in ustable/testing. Due the started freeze for bookworm I will not spend a serious amount of time on getting the version in experimental updated to something new. -- Regards Carsten
Bug#1029594: Fails to authenticate mit o365
Dear bug submitters, I've build a test version amd64 of the current Mozilla upstream version for Thunderbird 102.7.1 which was push onto the release folder on 01-Feb-2023. https://download-origin.cdn.mozilla.net/pub/thunderbird/releases/102.7.1/source/ The previous used version 102.7.1 which was uploaded as Debian version 1:102.7.1-1 was taken from the upstream candidates folder build1 dated to 24-Jan-2023. https://download-origin.cdn.mozilla.net/pub/thunderbird/candidates/102.7.1-candidates/build1/source/ The test build can be found here https://people.debian.org/~tijuca/thunderbird-102.7.1+1/ Please test if the issue of broken OAuth authetification on Outlook365 is now fixed and Thunderbird is working again and give please some feedback. If the original issues is fixed I will preprare a final upload to the archive. Regards Carsten Am Wed, Jan 25, 2023 at 09:48:51AM +0100 schrieb Carsten Schoenert: > Control: tags -1 serious > > Hello Klaus, > > Am 25.01.23 um 08:38 schrieb Klaus Ethgen: > > After upgrading from 1:102.6.0-1 this morning, thunderbird fails to > > login into microsoft o365, making it impossible to access mails from > > that account. > > the current version 102.7.1 should normally fix exact this regression about > MS Outlook 365 that was introduced by 102.7.0. > > Upstream did announce that problem for the version 102.7.1 but unfortunately > too late as the the upload to unstable was already done. > > I've no estimated time line about a fixed version. > > -- > Regards > Carsten
Bug#1029594: Fails to authenticate mit o365
Am 05.02.23 um 19:56 schrieb Chandler Sobel-Sorenson: Carsten Schoenert wrote on 2/5/23 3:39 AM: If you need your laptop or your workstation for mission critical things than Debian unstable/sid isn't the right choice. If you do so then you will need some knowledge to handle situations like happen now.I'm not. The broken package has been released to testing already. In an ideal world I would have two separate computers but not everyone has ideal situations. testing release is good for my situation and have now added notifications of important bugs for apt-listbugs config as well, so thank you for mentioning that. However, that's not the default for users. I don't understand what you want from me. Is the world going down now? For sure not! Did such situations did happen in the past? Yes, several times while I maintaining Thunderbird. Do I have a life beside Debian? Yes I have. Did you use stable for your daily work as Debian is suggesting? I don't think so. Would you be affected by this issue if you use stable? No! Does your emails help preventing others? Also here I don't think so. You even don't have tried to use some pre-compiled version from Mozilla and did give some feedback, you still do nothing more than complaining how bad the situation is. So, live with the situation like I do. We are all volunteers and do the work in our free time. Once I got time I will try to look at situation. -- Regards Carsten
Bug#1029594: Fails to authenticate mit o365
Am 04.02.23 um 23:25 schrieb Chandler Sobel-Sorenson: Frankly, I'm glad it was increased to serious because otherwise listbugs wouldn't have let me stop it, then I have to spend more time figuring out why I suddenly can't retrieve my e-mail and tracking down a solution, downgrading packages, etc. There is only so much time in the day and so much coffee I can drink. ;-) We use O365 at the University and I have enough issues maintaining our Linux systems there. ;-) Last thing I need is problems with workstation to get in the way of my work. If you need your laptop or your workstation for mission critical things than Debian unstable/sid isn't the right choice. If you do so then you will need some knowledge to handle situations like happen now. > Quoting https://www.debian.org/Bugs/Developer.en.html > important > a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone > And that's what this issue is about, most of the users can use > Thunderbird without problems. Do you have statistics for that? What is "most"? The majority of users. :-) And these are obviously not users of Microsoft Cloud products. We haven got reports from GMail user e.g. Debian doesn't have any really resilient statistics as such statistics bases on completely free choice. Debian doesn't collect data from users without any confirmation. I'm pretty sure many Universities and other large organizations across the world are using Office however, if it's anything like our University, "most" of those users are using Windows version of Outlook or Outlook Online. Still, I could not be sure what "most" Thunderbird users are using. Sure the world is mostly owned by Microsoft Desktop systems, and using Exchange or now Outlook 365 is also decreasing the the free choice of a client to interact with the server instance. Most users of Thunderbird are not using M$ products or at least only using a small set of features of Exchange or Outlook.com. Further, the actual bug in mozilla is #1814536 (OAuth2 authentication | 102.7.1. | Linux - fails) - still Open. This is an even broader than just o365 as Google uses OAuth2 as well, etc. That bug was reported here in Debian as grave under #1030112 but you closed it as a duplicate of this bug. That was perhaps mistaken. No, it was not. Having dozen of issues open that are about the same problem is really not helpful to handle the issue. > serious > is a severe violation of Debian policy (roughly, it violates a "must" or "required" directive), > or, in the package maintainer's or release manager's opinion, makes the package unsuitable for release. I don't have the time to currently review the 609 instances of "must" or "required" in the policy, but I believe this makes the package unsuitable for release. I don't really understand your problem. What is the problem here? What does it help if we increase the severity even more? Even right now the the broken package will not migrate to testing. But it will also trigger a remove of the version in testing. What do we win? > grave > makes the package in question unusable or mostly so, or causes data loss, > or introduces a security hole allowing access to the accounts of users who use the package. I think #1030112 should be reopened and/or merged with this bug, with the title being updated to reflect broader issue with OAuth2. As the bug is much broader than is implied here, severity should be maintained at a minimum of serious. And what we get from doing so? The closed issue has added information that further talking is happen here. Since many these days are using Gmail as their only e-mail then could even be argued that thunderbird is now unusable or mostly so, therefore severity of grave is not out of the question either. My GMail account is working with the current version in testing means to me that Google doesn't has changed something on their side. Obviously only MS has changed something. So finally again as written in other answers: If you need to use Thunderbird in a critical environment you shouldn't use unstable/sid as long you don't know how to handle the potential breakage of packages. Debian is providing a stable release for productive use, if you need newer version of software you can add the backport suite. Or if you are more experienced switch to testing. -- Regards Carsten
Bug#1029594: New TB 1:102.7.1-1 from Mozilla
Hello Pete, Am 04.02.23 um 21:58 schrieb Pete Elliott: Hello, I'm ignorant as to how packages get updated. It appears that there is a newer version of TB 1:102.7.1-1 available from Mozilla than the one offered via the Debian package management system. Will this update at some point? we will update the package once the underlying issue is fixed. Mozilla is fist providing new version by a candidates/ tree and that is synced to releases/. If you compare the signatures for both files you will see they are equal, means both releases are equal. https://download-origin.cdn.mozilla.net/pub/thunderbird/releases/102.7.1/source/thunderbird-102.7.1.source.tar.xz.asc https://download-origin.cdn.mozilla.net/pub/thunderbird/candidates/102.7.1-candidates/build2/source/thunderbird-102.7.1.source.tar.xz.asc The current (new build) version of 102.7.1 might have fixed the OAuth issue on outlook.com, it's not confirmed by Mozilla. (It does seem odd that Mozilla's fix of the Oauth didn't generate a new version number as opposed to fixing a previously broken version.) Well, you can try out the Mozilla binary package to see if this version has a fixed behavior. https://download-origin.cdn.mozilla.net/pub/thunderbird/releases/102.7.1/linux-x86_64/ Just download the language you want to use, extract the binary and start it, it will pick up your configuration automatically. I don't use and ever want to use a email setup on outlook.com, so I can't test anything. As written previously in this issue tracking, it's always possible to downgrade Thunderbird to the previous version. -- Regards Carsten
Bug#1029594: Fails to authenticate mit o365
Am Wed, Feb 01, 2023 at 03:24:14PM + schrieb Nicola Chiapolini: > Control: severity -1 serious > > Hi Carsten > > I am increasing the severity again. This bit me today. > I rely on apt-listbugs to protect me from such problems and with the default > settings "normal" is not sufficient to trigger listbugs. > Yesterday, #1030112 triggered listbugs, so today I was happy to see that the > problem is fixed and upgraded. So I try to help others... > (Since the only reason I use Thunderbird in the first place is to access > o365, this bug might even be considered grave ;-) I'm considering this issue is normaly just of severity important. Quoting https://www.debian.org/Bugs/Developer.en.html important a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone And that's what this issue is about, most of the users can use Thunderbird without problems. But, using severity important would allow to migrate the package to testing and more users would be affected by the issue. So I'm fine with keeping the current severity. On the other hand you should consider to not use unstable as prefered Debian release in case you are depening an always usable packages. Currently I still don't have an idea when a fixed version will be available. Regards Carsten
Bug#1028885: thunderbird: FTBFS: ValueError: invalid mode: 'rU'
Control: tags -1 pending Hi, Am 22.01.23 um 18:26 schrieb James Addison: Source: thunderbird Followup-For: Bug #1028885 This looks like a similar/identical problem in the 'mozbuild' Python scripts under Python 3.11 as experienced in Debian bug #1028716 for the mozjs102 package. The contents of the (quilt) patch used to fix #1028716 can be cherry-picked (with one conflict to resolve in the 'debian/patches/series' file) and do apply cleanly using quilt against the thunderbird '1:102.6.0-1' tag using: git cherry-pick -x f51a1f902757c4f10f7c75dfa541fb673ecab6c2 (I haven't confirmed whether the build succeeds with those changes in place, though) I have locally already created a fix for this issue. Thunderbird 102.7.0 has a known regression issue and currently we waiting for 102.7.1 which should be released the next days. -- Regards Carsten
Bug#1028619: rich: autopkgtest is failng after updating pygments to 2.14.0+dfsg-1
tags -1 patch + upstream forwarded -1 https://github.com/Textualize/rich/pull/2751 Am 13.01.23 um 19:25 schrieb Sandro Tosi: yeah i'm wondering why you keep updating packages you dont maintain to new upstream releases and breaking revdeps as consequence It's seems to me you are the only person who who disagrees on the work I do. That rdeps are will fail on package update is quite normal not only to me. But it's a difference if a upstream project is doing a major version bump or some usual minor update. And we are not in any freeze state yet there I agree no uncoordinated and unneeded version updates should happen. So far possible I pointed in other reports I did open to the upstream fix that adjust the local tests for the different behavior pygments 2.14.0 is producing. Within rich this doesn't did happen yet by any other reporter or by upstream itself. So I created a PR [1] that will fix the issues within the tests. For your convenience I added the same patch here where I can rebuild the current version of rich in unstable successful again. [1] https://github.com/Textualize/rich/pull/2751 -- Regards CarstenFrom bea71b3ca0f7b5c22f0ed050eb125b32e8085a65 Mon Sep 17 00:00:00 2001 From: Carsten Schoenert Date: Sat, 14 Jan 2023 07:38:57 +0100 Subject: [PATCH] tests: Adjustments to run tests with pygments 2.14.0 The current most recent version of pygments produces some different output which provoke failing some of the the existing tests. --- tests/test_syntax.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/test_syntax.py b/tests/test_syntax.py index 5eff05ee..6b8cfd8b 100644 --- a/tests/test_syntax.py +++ b/tests/test_syntax.py @@ -110,7 +110,7 @@ def test_python_render_simple_indent_guides(): ) rendered_syntax = render(syntax) print(repr(rendered_syntax)) -expected = '\x1b[34mdef\x1b[0m \x1b[32mloop_first_last\x1b[0m(values: Iterable[T]) -> Iterable[Tuple[\x1b[36mb\x1b[0m\n\x1b[2m│ \x1b[0m\x1b[33m"""Iterate and generate a tuple with a flag for first an\x1b[0m\n\x1b[2m│ \x1b[0miter_values = \x1b[36miter\x1b[0m(values)\n\x1b[2m│ \x1b[0m\x1b[34mtry\x1b[0m:\n\x1b[2m│ │ \x1b[0mprevious_value = \x1b[36mnext\x1b[0m(iter_values)\n\x1b[2m│ \x1b[0m\x1b[34mexcept\x1b[0m \x1b[36mStopIteration\x1b[0m:\n\x1b[2m│ │ \x1b[0m\x1b[34mreturn\x1b[0m\n\x1b[2m│ \x1b[0mfirst = \x1b[34mTrue\x1b[0m\n\x1b[2m│ \x1b[0m\x1b[34mfor\x1b[0m value \x1b[35min\x1b[0m iter_values:\n\x1b[2m│ │ \x1b[0m\x1b[34myield\x1b[0m first, \x1b[34mFalse\x1b[0m, previous_value\n\x1b[2m│ │ \x1b[0mfirst = \x1b[34mFalse\x1b[0m\n\x1b[2m│ │ \x1b[0mprevious_value = value\n\x1b[2m│ \x1b[0m\x1b[34myield\x1b[0m first, \x1b[34mTrue\x1b[0m, previous_value\n' +expected = '\x1b[34mdef\x1b[0m \x1b[32mloop_first_last\x1b[0m(values: Iterable[T]) -> Iterable[Tuple[\x1b[36mb\x1b[0m\n\x1b[2;37m│ \x1b[0m\x1b[33m"""Iterate and generate a tuple with a flag for first an\x1b[0m\n\x1b[2m│ \x1b[0miter_values = \x1b[36miter\x1b[0m(values)\n\x1b[2m│ \x1b[0m\x1b[34mtry\x1b[0m:\n\x1b[2m│ │ \x1b[0mprevious_value = \x1b[36mnext\x1b[0m(iter_values)\n\x1b[2m│ \x1b[0m\x1b[34mexcept\x1b[0m \x1b[36mStopIteration\x1b[0m:\n\x1b[2m│ │ \x1b[0m\x1b[34mreturn\x1b[0m\n\x1b[2m│ \x1b[0mfirst = \x1b[34mTrue\x1b[0m\n\x1b[2m│ \x1b[0m\x1b[34mfor\x1b[0m value \x1b[35min\x1b[0m iter_values:\n\x1b[2m│ │ \x1b[0m\x1b[34myield\x1b[0m first, \x1b[34mFalse\x1b[0m, previous_value\n\x1b[2m│ │ \x1b[0mfirst = \x1b[34mFalse\x1b[0m\n\x1b[2m│ │ \x1b[0mprevious_value = value\n\x1b[2m│ \x1b[0m\x1b[34myield\x1b[0m first, \x1b[34mTrue\x1b[0m, previous_value\n' assert rendered_syntax == expected @@ -127,7 +127,7 @@ def test_python_render_line_range_indent_guides(): ) rendered_syntax = render(syntax) print(repr(rendered_syntax)) -expected = '\x1b[2m│ \x1b[0m\x1b[33m"""Iterate and generate a tuple with a flag for first an\x1b[0m\n\x1b[2m│ \x1b[0miter_values = \x1b[36miter\x1b[0m(values)\n' +expected = '\x1b[2;37m│ \x1b[0m\x1b[33m"""Iterate and generate a tuple with a flag for first an\x1b[0m\n\x1b[2m│ \x1b[0miter_values = \x1b[36miter\x1b[0m(values)\n' assert rendered_syntax == expected -- 2.39.0
Bug#1028622: sphinx-prompt: autopkgtest is failng after updating pygments to 2.14.0+dfsg-1
Source: sphinx-prompt
Version: 1.5.0-2
Severity: serious
Dear Maintainer,
after the upload of pygments 2.14.0+dfsg-1 your package is failung while
running the autopkgtest.
Some of the failing parts are:
autopkgtest [03:25:03]: test unittests: [---
= test session starts ==
platform linux -- Python 3.11.1, pytest-7.2.0, pluggy-1.0.0+repack
rootdir: /tmp/autopkgtest-lxc.k5oqcgm7/downtmp/build.h5g/src
collected 12 items
../build.h5g/src/tests/test_sphinx_prompt.py .FF...F.[100%]
=== FAILURES ===
_ test[arguments1-options1-content1-\nspan.prompt1:before {\n content: "$ ";\n}\none line\n] _
arguments = ['bash'], options = {'language': 'bash'}, content = ['one line']
expected = '\nspan.prompt1:before {\n
content: "$ ";\n}\none
line\n'
@pytest.mark.parametrize("arguments, options, content, expected", testdata)
def test(arguments, options, content, expected):
sphinx_prompt._cache.next_index = 1
sphinx_prompt._cache.prompts.clear()
stream = StringIO()
reporter = docutils.utils.Reporter("test data", 2, 4, stream, 1)
statemachine = docutils.statemachine.StateMachine([], None)
setattr(statemachine, "reporter", reporter)
directive = sphinx_prompt.PromptDirective(
"prompt", arguments, options, content, 0, 0, "", None, statemachine
)
result = directive.run()
> assert result[0].astext() == expected
E assert ''
E Skipping 159 identical leading characters in diff, use -v to show
E - ompt1">one line
E + ompt1">one line
E
../build.h5g/src/tests/test_sphinx_prompt.py:165: AssertionError
_ test[arguments2-options2-content2-\nspan.prompt1:before {\n content: "$ ";\n}\none line\n] _
arguments = [], options = {'language': 'bash'}, content = ['one line']
expected = '\nspan.prompt1:before {\n
content: "$ ";\n}\none
line\n'
@pytest.mark.parametrize("arguments, options, content, expected", testdata)
def test(arguments, options, content, expected):
sphinx_prompt._cache.next_index = 1
sphinx_prompt._cache.prompts.clear()
stream = StringIO()
reporter = docutils.utils.Reporter("test data", 2, 4, stream, 1)
statemachine = docutils.statemachine.StateMachine([], None)
setattr(statemachine, "reporter", reporter)
directive = sphinx_prompt.PromptDirective(
"prompt", arguments, options, content, 0, 0, "", None, statemachine
)
result = directive.run()
> assert result[0].astext() == expected
E assert ''
E Skipping 159 identical leading characters in diff, use -v to show
E - ompt1">one line
E + ompt1">one line
E
...
It might be enough to pick
https://github.com/sbrunner/sphinx-prompt/commit/f996f7ab96ec63b08e27f96559b759143ccff214
from the upstream git tree to fix the issues.
Regards
Carsten
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-6-amd64 (SMP w/20 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1028621: sphinx: autopkgtest is failng after updating pygments to 2.14.0+dfsg-1
Source: sphinx Severity: serious Dear Maintainer, after the upload of pygments 2.14.0+dfsg-1 your package is failung while running the autopkgtest. As the output of the failing parts are noisy it's not useful to paste them here. The full log of the autopkgtest on amd64 run can be found here: https://ci.debian.net/data/autopkgtest/testing/amd64/s/sphinx/30313691/log.gz Regards Carsten -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/20 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1028620: ruby-pygments: autopkgtest is failng after updating pygments to 2.14.0+dfsg-1
Source: ruby-pygments Version: 2.3.0+ds-2.1 Severity: serious Dear Maintainer, after the upload of pygments 2.14.0+dfsg-1 your package is failung while running the autopkgtest. The failed part in detail is: RUBYLIB=. GEM_PATH= ruby3.1 -S rake -f debian/ruby-tests.rake mv lib ./.gem2deb.lib /usr/bin/ruby3.1 -w -I"test" /usr/lib/ruby/gems/3.1.0/gems/rake-13.0.6/lib/rake/rake_test_loader.rb "test/test_pygments.rb" -v Loaded suite /usr/lib/ruby/gems/3.1.0/gems/rake-13.0.6/lib/rake/rake_test_loader Started PygmentsConfigTest: test_filters: .: (0.064462) test_formatters: .: (0.006962) test_lexers: .: (0.021366) test_styles: .: (0.000854) PygmentsCssTest: test_css: .: (0.001624) test_css_colorful:.: (0.001286) test_css_default: .: (0.000903) test_css_options: .: (0.000823) test_css_prefix: .: (0.000833) test_css_prefix_and_options: .: (0.000772) PygmentsHighlightTest: test_full_html_highlight: F === Failure: test_full_html_highlight(PygmentsHighlightTest) /tmp/autopkgtest-lxc.wcymigwk/downtmp/build.qG9/src/test/test_pygments.rb:31:in `test_full_html_highlight' 28: def test_full_html_highlight 29: code = P.highlight(RUBY_CODE) 30: assert_match '#!/usr/bin/ruby', code => 31: assert_equal %(#!/usr/bin/ruby 32: puts foo 33: ), code 34: end <"#!/usr/bin/ruby\n" + "puts foo\n" + ""> expected but was <"#!/usr/bin/ruby\n" + "puts foo\n" + ""> diff: #!/usr/bin/ruby ? puts foo === : (0.154840) test_highlight_defaults_to_html: .: (0.002140) test_highlight_formatter_bbcode: .: (0.001620) test_highlight_formatter_terminal:.: (0.001277) test_highlight_on_multi_threads: O === Omission: We do not actually support multithreading [test_highlight_on_multi_threads(PygmentsHighlightTest)] /tmp/autopkgtest-lxc.wcymigwk/downtmp/build.qG9/src/test/test_pygments.rb:114:in `test_highlight_on_multi_threads' === : (0.000826) test_highlight_options: .: (0.001922) test_highlight_still_works_with_invalid_code: .: (0.046896) test_highlight_works_on_utf8: .: (0.000949) test_highlight_works_on_utf8_all_chars_automatically: .: (0.000811) test_highlight_works_on_utf8_automatically: .: (0.000834) test_highlight_works_with_larger_files: .: (0.033287) test_highlight_works_with_multiple_newlines: .: (0.001873) test_highlight_works_with_multiple_utf8: .: (0.000864) test_highlight_works_with_multiple_utf8_and_trailing_newline: .: (0.000906) test_highlight_works_with_null_bytes: .: (0.000902) test_highlight_works_with_trailing_cr:.: (0.001775) test_highlight_works_with_trailing_newline: .: (0.001717) test_version: .: (0.000343) PygmentsLexerClassTest: test_find:.: (0.000268) test_find_by_alias: .: (0.000152) test_find_by_name:.: (0.000124) test_find_lexer_by_extname: .: (0.000178) test_find_lexer_by_mimetype: .: (0.000122) PygmentsLexerTest: test_lexer_by_content:.: (0.001258) test_lexer_by_filename: .: (0.420205) test_lexer_by_filename_and_content: .: (0.084091) test_lexer_by_mimetype: .: (0.000676) test_lexer_by_name: .: (0.014858) test_lexer_by_nothing:.: (0.002577) Finished in 0.881532932 seconds. --- 39 tests, 60 assertions, 1 failures, 0 errors, 0 pendings, 1 omissions, 0 notifications 97.3684% passed --- 44.24 tests/s, 68.06 assertions/s Updating to 2.3.1 and adding this commit might solve this issue. https://github.com/pygments/pygments.rb/commit/fe03c274a4b01fc9657a90dba5f16b3e9401082a Regards Carsten -- System Information: Debian Release: bookworm/sid
Bug#1028619: rich: autopkgtest is failng after updating pygments to 2.14.0+dfsg-1
Source: rich Version: 13.0.0-1 Severity: serious Dear Maintainer, after the upload of pygments 2.14.0+dfsg-1 your package is failung while running the autopkgtest. The failed part in detail is: === FAILURES === ___ test_python_render_simple_indent_guides def test_python_render_simple_indent_guides(): syntax = Syntax( CODE, lexer="python", line_numbers=False, theme="ansi_light", code_width=60, word_wrap=False, indent_guides=True, ) rendered_syntax = render(syntax) print(repr(rendered_syntax)) expected = '\x1b[34mdef\x1b[0m \x1b[32mloop_first_last\x1b[0m(values: Iterable[T]) -> Iterable[Tuple[\x1b[36mb\x1b[0m\n\x1b[2m│ \x1b[0m\x1b[33m"""Iterate and generate a tuple with a flag for first an\x1b[0m\n\x1b[2m│ \x1b[0miter_values = \x1b[36miter\x1b[0m(values)\n\x1b[2m│ \x1b[0m\x1b[34mtry\x1b[0m:\n\x1b[2m│ │ \x1b[0mprevious_value = \x1b[36mnext\x1b[0m(iter_values)\n\x1b[2m│ \x1b[0m\x1b[34mexcept\x1b[0m \x1b[36mStopIteration\x1b[0m:\n\x1b[2m│ │ \x1b[0m\x1b[34mreturn\x1b[0m\n\x1b[2m│ \x1b[0mfirst = \x1b[34mTrue\x1b[0m\n\x1b[2m│ \x1b[0m\x1b[34mfor\x1b[0m value \x1b[35min\x1b[0m iter_values:\n\x1b[2m│ │ \x1b[0m\x1b[34myield\x1b[0m first, \x1b[34mFalse\x1b[0m, previous_value\n\x1b[2m│ │ \x1b[0mfirst = \x1b[34mFalse\x1b[0m\n\x1b[2m│ │ \x1b[0mprevious_value = value\n\x1b[2m│ \x1b[0m\x1b[34myield\x1b[0m first, \x1b[34mTrue\x1b[0m, previous_value\n' > assert rendered_syntax == expected E assert '\x1b[34mdef\...vious_value\n' == '\x1b[34mdef\...vious_value\n' E Skipping 81 identical leading characters in diff, use -v to show E mb␛[0m E - ␛[2m│ ␛[0m␛[33m"""Iterate and generate a tuple with a flag for first an␛[0m E + ␛[2;37m│ ␛[0m␛[33m"""Iterate and generate a tuple with a flag for first an␛[0m E ?+++ E ␛[2m│ ␛[0miter_values = ␛[36miter␛[0m(values) E ␛[2m│ ␛[0m␛[34mtry␛[0m:... E E ...Full output truncated (10 lines hidden), use '-vv' to show tests/test_syntax.py:114: AssertionError - Captured stdout call - '\x1b[34mdef\x1b[0m \x1b[32mloop_first_last\x1b[0m(values: Iterable[T]) -> Iterable[Tuple[\x1b[36mb\x1b[0m\n\x1b[2;37m│ \x1b[0m\x1b[33m"""Iterate and generate a tuple with a flag for first an\x1b[0m\n\x1b[2m│ \x1b[0miter_values = \x1b[36miter\x1b[0m(values)\n\x1b[2m│ \x1b[0m\x1b[34mtry\x1b[0m:\n\x1b[2m│ │ \x1b[0mprevious_value = \x1b[36mnext\x1b[0m(iter_values)\n\x1b[2m│ \x1b[0m\x1b[34mexcept\x1b[0m \x1b[36mStopIteration\x1b[0m:\n\x1b[2m│ │ \x1b[0m\x1b[34mreturn\x1b[0m\n\x1b[2m│ \x1b[0mfirst = \x1b[34mTrue\x1b[0m\n\x1b[2m│ \x1b[0m\x1b[34mfor\x1b[0m value \x1b[35min\x1b[0m iter_values:\n\x1b[2m│ │ \x1b[0m\x1b[34myield\x1b[0m first, \x1b[34mFalse\x1b[0m, previous_value\n\x1b[2m│ │ \x1b[0mfirst = \x1b[34mFalse\x1b[0m\n\x1b[2m│ │ \x1b[0mprevious_value = value\n\x1b[2m│ \x1b[0m\x1b[34myield\x1b[0m first, \x1b[34mTrue\x1b[0m, previous_value\n' _ test_python_render_line_range_indent_guides __ def test_python_render_line_range_indent_guides(): syntax = Syntax( CODE, lexer="python", line_numbers=False, theme="ansi_light", code_width=60, word_wrap=False, line_range=(2, 3), indent_guides=True, ) rendered_syntax = render(syntax) print(repr(rendered_syntax)) expected = '\x1b[2m│ \x1b[0m\x1b[33m"""Iterate and generate a tuple with a flag for first an\x1b[0m\n\x1b[2m│ \x1b[0miter_values = \x1b[36miter\x1b[0m(values)\n' > assert rendered_syntax == expected E assert '\x1b[2;37m│ ...[0m(values)\n' == '\x1b[2m│ \...[0m(values)\n' E - ␛[2m│ ␛[0m␛[33m"""Iterate and generate a tuple with a flag for first an␛[0m E + ␛[2;37m│ ␛[0m␛[33m"""Iterate and generate a tuple with a flag for first an␛[0m E ?+++ E ␛[2m│ ␛[0miter_values = ␛[36miter␛[0m(values) tests/test_syntax.py:131: AssertionError - Captured stdout call - '\x1b[2;37m│ \x1b[0m\x1b[33m"""Iterate and generate a tuple with a flag for first an\x1b[0m\n\x1b[2m│ \x1b[0miter_values = \x1b[36miter\x1b[0m(values)\n' === short test summary info FAILED tests/test_syntax.py::test_python_render_simple_indent_guides - assert... FAILED tests/test_syntax.py::test_python_render_line_range_indent_guides - as... == 2 failed, 765 passed, 23 skipped in 5.86s === E: pybuild pybuild:388: test: plugin pyproject failed with: exit code=1: cd
Bug#1028618: retext: autopkgtest on s390x is failng after updating pygments to 2.14.0+dfsg-1
Source: retext Version: 8.0.0-1 Severity: serious Dear Maintainer, after the upload of pygments 2.14.0+dfsg-1 your package is failung while running the autopkgtest on s390x with python 3.10. The failed part in detail is: == FAIL: test_autoSave (test_window.TestWindow) -- Traceback (most recent call last): File "/usr/lib/python3.10/unittest/mock.py", line 1379, in patched return func(*newargs, **newkeywargs) File "/tmp/autopkgtest-lxc.ay0gd1cu/downtmp/autopkgtest_tmp/tests/test_window.py", line 382, in test_autoSave self.assertEqual(tempFile.read(), 'second content') AssertionError: 'first content' != 'second content' - first content + second content -- Regards Carsten -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/20 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1028617: ipython: autopkgtest is faling after updating pygments to 2.14.0+dfsg-1
Source: ipython Version: 8.5.0-3 Severity: serious Dear Maintainer, after the upload of pygments 2.14.0+dfsg-1 your package is failung while running the autopkgtest. The failed part in detail is: === FAILURES === _ TestLexers.testIPythonLexer __ self = def testIPythonLexer(self): fragment = '!echo $HOME\n' tokens = [ (Token.Operator, '!'), ] tokens.extend(self.bash_lexer.get_tokens(fragment[1:])) > self.assertEqual(tokens, list(self.lexer.get_tokens(fragment))) E AssertionError: Lists differ: [(Tok[78 chars] (Token.Name.Variable, '$HOME'), (Token.Text.Whitespace, '\n')] != [(Tok[78 chars] (Token.Name.Variable, '$HOME'), (Token.Text, '\n')] E E First differing element 4: E (Token.Text.Whitespace, '\n') E (Token.Text, '\n') E E [(Token.Operator, '!'), E (Token.Name.Builtin, 'echo'), E (Token.Text.Whitespace, ' '), E (Token.Name.Variable, '$HOME'), E - (Token.Text.Whitespace, '\n')] E ? --- E E + (Token.Text, '\n')] IPython/lib/tests/test_lexers.py:25: AssertionError Updating the package to version 8.8.0 should fix the issue, it's containing the commit https://github.com/ipython/ipython/commit/ed7f35f8b721d4b4dcafea173ce724bee25704c7 which addresses the changes done by recent pygments. Regards Carsten -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/20 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1028616: hovercraft: autopkgtest is faling after updating pygments to 2.14.0+dfsg-1
Source: hovercraft Version: 2.7-4 Severity: serious Dear Maintainer, after the upload of pygments 2.14.0+dfsg-1 your package is failung while running the autopkgtest. The failed part in detail is: autopkgtest [03:24:50]: test hovercraft: [--- [*] testing python3.11: = test session starts == platform linux -- Python 3.11.1, pytest-7.2.0, pluggy-1.0.0+repack -- /usr/bin/python3.11 cachedir: .pytest_cache rootdir: /tmp/autopkgtest-lxc.74de8cqg/downtmp/build.58j/src collecting ... collected 35 items tests/test_generator.py::GeneratorTests::test_big FAILED [ 2%] === FAILURES === ___ GeneratorTests.test_big self = def test_big(self): template = Template(os.path.join(TEST_DATA, "maximal")) html, deps = rst2html(os.path.join(TEST_DATA, "advanced.rst"), template) > self.assertEqual(html, HTML_OUTPUTS["advanced"]) E AssertionError: b'\n ' != b'\n# Comment\n[1236 chars]tml>' tests/test_generator.py:24: AssertionError === short test summary info FAILED tests/test_generator.py::GeneratorTests::test_big - AssertionError: b'... !! stopping after 1 failures !!! == 1 failed in 0.25s === Regards Carsten -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/20 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1026527: marked as pending in hiro
Control: tag -1 pending Hello, Bug #1026527 in hiro reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/hiro/-/commit/14fdc0fcea382bda265cbbcdb9a5e5f191723896 Rebuild patche queue from patch-queue branch Added patches: docs-Use-local-inventory-for-intersphinx.patch h-core.py-Use-getfullargspec-instead-of-getargspec.patch Closes: #1026527 Renamed patches: 0001-Remove-useless-sphinx-extensions.patch -> docs-Remove-not-exsting-sphinx-extensions.patch 0002-Remove-external-links-from-project-docs.patch -> docs-Remove-external-badge-linking-from-documentation.patch (this message was generated automatically) -- Greetings https://bugs.debian.org/1026527
Bug#1026643: marked as pending in astunparse
Control: tag -1 pending Hello, Bug #1026643 in astunparse reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/astunparse/-/commit/c1b04ef5a7908b68288915d75a4d733c61843bc7 Rebuild patch queue from patch-queue branch Added patch: tests-Skip-test_files-on-on-Python-3.10.patch Closes: #1026643 (this message was generated automatically) -- Greetings https://bugs.debian.org/1026643
Bug#1027137: kicad: FTBFS: #error "KICAD_USE_EGL can only be used when wxWidgets is compiled with the EGL canvas"
Hello Andreas, Am 29.12.22 um 18:00 schrieb Andreas Metzler: (Ideally the cmake setup should check wxWidgets's EGL-status and set KICAD_USE_EGL accordingly instead of failing at build-time.) KiCad upstream did have the same idea some time ago and added a wishlist report against wxWidgets. https://github.com/wxWidgets/wxWidgets/issues/22325 But given the development dynamics of wxWidgets I do not expect a quick solution for this. -- Regards Carsten
Bug#1025135: libcoap2: Do not ship in bookworm
Source: libcoap2 Version: 4.2.1-1 Severity: serious The API version 2 of libcoap was given up long ago and is replaced by API v3. The last version for v2 was released on 2019. Thus no upstream development and no updates will happen for this package and we should not ship libcoap2 packages in bookworm onward. There is a replacement avaialable - users should switch to libcoap3. https://tracker.debian.org/pkg/libcoap3 Regards Carsten
Bug#1016668: kicad-packages3d - Unreachable maintainer
Well, Am 13.08.22 um 10:56 schrieb Bastian Blank: On Sat, Aug 13, 2022 at 10:41:09AM +0200, Carsten Schoenert wrote: | Action: failed | Final-Recipient: rfc822;c.schoen...@t-online.de | Status: 5.0.0 | Remote-MTA: dns; mx02.t-online.de | Diagnostic-Code: smtp; 554 IP=194.177.211.212 - A problem occurred. (Ask your postmaster for help or to contact t...@rx.t-online.de to clarify.) this can only be some temporary problem I think. While working on various uploads for the kicad-* packagas I did receive all related information emails from DAK, except this one. Also I haven't noticed any similar problems with other uploads that did happen after the kicad-* packages. No, this is a ongoing problem. We see reject messages at the ftp-master alias quite regularly. you see more here as I'm ever possible to see. It is a known problem with your selected e-mail provider. They block at least on of the debian.org mail relays. T-Online isn't a niche provider in Germany as you for sure know. I had only few problems in the past were I was needed to go in contact with the T-Online. And maybe I had always luck then, I was getting support well and quick enough. So far my experience is quite good with T-Online. I only know of one specific email provider in France which has regularly issues delivering emails to T-Online due rejects. And only one to two times a year I hear from some own hosted foreign email domain which gets similar problems you have seen. There isn't much I can do about this, I normally don't even get noticed about such problems. It should be somehow possible for Debian to get in contact with T-Online, I can try to ask our mail systems administrators which do also encounter rejects from various other email domains and the systems they run on. Maybe they have a personal contact person. -- Regards Carsten
Bug#1014745: thunderbird: Reply all remove Cc participants
Hello Eric, Am 14.07.22 um 11:48 schrieb eric: I had the same problem on a specific exchnage account. Reply all did not copy the content and did remove all the CC. you could try out TB 1:103.0~b5-1 from experimental which should have included the fix which issue here is about. Keep in mind that the configuration will get bumped to the new main version and isn't backward compatible, so please make a backup of your config before starting the installed version from experimental. -- Regards Carsten
Bug#1014745: thunderbird: Using "Reply All" is sometimes removing all Cc recipients
Package: thunderbird Version: 1:102.0.1-1 Severity: grave Tags: upstream Justification: renders package mostly unusable Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1778840 This report is created to prevent the migration of Thunderbird into testing. In some cases it might happen that using "Reply All" will drop all Cc recipients. The issue is known and confirmed by upstream. Regards Carsten -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, aarch64, arm64 Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages thunderbird depends on: ii debianutils 5.7-0.2 ii fontconfig 2.13.1-4.4 ii libatk1.0-0 2.38.0-1 ii libbotan-2-192.19.1+dfsg-3 ii libbz2-1.0 1.0.8-5 ii libc62.33-7 ii libcairo-gobject21.16.0-5 ii libcairo21.16.0-5 ii libdbus-1-3 1.14.0-1 ii libdbus-glib-1-2 0.112-2 ii libevent-2.1-7 2.1.12-stable-5+b1 ii libffi8 3.4.2-4 ii libfontconfig1 2.13.1-4.4 ii libfreetype6 2.12.1+dfsg-3 ii libgcc-s112.1.0-2 ii libgdk-pixbuf-2.0-0 2.42.8+dfsg-1 ii libglib2.0-0 2.72.3-1 ii libgtk-3-0 3.24.34-1 ii libjson-c5 0.16-1 ii libnspr4 2:4.34-1 ii libnss3 2:3.79-1 ii libpango-1.0-0 1.50.7+ds-1 ii libstdc++6 12.1.0-2 ii libvpx7 1.11.0-2 ii libx11-6 2:1.7.5-1 ii libx11-xcb1 2:1.7.5-1 ii libxcb-shm0 1.14-3 ii libxcb1 1.14-3 ii libxext6 2:1.3.4-1 ii libxrender1 1:0.9.10-1.1 ii psmisc 23.5-1 ii x11-utils7.7+5 ii zenity 3.42.1-2 ii zlib1g 1:1.2.11.dfsg-4 Versions of packages thunderbird recommends: ii hunspell-de-at [hunspell-dictionary] 20161207-9 ii hunspell-de-ch [hunspell-dictionary] 20161207-9 ii hunspell-de-de [hunspell-dictionary] 20161207-9 ii hunspell-en-us [hunspell-dictionary] 1:2020.12.07-2 ii myspell-da [myspell-dictionary] 1.6.36-11.1 Versions of packages thunderbird suggests: ii apparmor 3.0.4-3 ii fonts-lyx 2.3.6.1-1 ii libgssapi-krb5-2 1.19.2-2+b2 -- no debconf information
Bug#1014650: autopkgtest: ModuleNotFoundError: No module named 'packaging'
Source: nbconvert Version: 6.4.4-1 Severity: serious Dear Maintainer, after updating python-bleach to 5.0.0 your package from testing fails together wich python3-bleach from unstable. e.g. on amd64 https://ci.debian.net/data/autopkgtest/testing/amd64/n/nbconvert/23478280/log.gz The error in detail looks like this: autopkgtest [20:13:04]: test autodep8-python3: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import nbconvert; print(nbconvert)" ; done autopkgtest [20:13:04]: test autodep8-python3: [--- Testing with python3.9: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/nbconvert/__init__.py", line 4, in from .exporters import * File "/usr/lib/python3/dist-packages/nbconvert/exporters/__init__.py", line 3, in from .html import HTMLExporter File "/usr/lib/python3/dist-packages/nbconvert/exporters/html.py", line 25, in from nbconvert.filters.highlight import Highlight2HTML File "/usr/lib/python3/dist-packages/nbconvert/filters/__init__.py", line 5, in from .latex import * File "/usr/lib/python3/dist-packages/nbconvert/filters/latex.py", line 17, in from nbconvert.utils.pandoc import pandoc File "/usr/lib/python3/dist-packages/nbconvert/utils/pandoc.py", line 12, in from nbconvert.utils.version import check_version File "/usr/lib/python3/dist-packages/nbconvert/utils/version.py", line 11, in from packaging.version import Version ModuleNotFoundError: No module named 'packaging' autopkgtest [20:13:05]: test autodep8-python3: ---] autopkgtest [20:13:05]: test autodep8-python3: - - - - - - - - - - results - - - - - - - - - - autodep8-python3 FAIL non-zero exit status 1 autopkgtest [20:13:05]: summary command1 FAIL non-zero exit status 2 autodep8-python3 FAIL non-zero exit status 1 It might be enough to add python3-packaging as new dependency? Regards Carsten -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/6 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1014638: thunderbird: 1:102.0.1-1 update breaks unser interface - no accounts, emails are shown in main window
Hello Vincas Am 09.07.22 um 12:19 schrieb Vincas Dargis: Please see screenshot attached - no account tree is visible after upgrade. In settings I do see all accounts set up as it was before though. AppArmor profile was always enabled, though after seeing this problem I've disabled AppArmor profile but problem persist. have you noticed the suggestions on the Debian wiki? https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues In about 80% of problems some external Add-ons are the root of problems. Sometimes it's harder to debug and requires the usage of the debugger. Downgranding to 1:91.11.0-1 is not workaround, as it complains that "You have launched an older version of Thunderbird". You can use the CLI option --allow-downgrade to downgrade an existing profile. -- Regards Carsten
Bug#1000684: python-django-modelcluster: autopkgtest fails with django-taggit >= 2.0.0
Source: python-django-modelcluster
Version: 5.2-1
Severity: serious
Control: found -1 python-django-modelcluster/5.2-1
Dear Maintainer,
the autopkgtesting is failing since the upload of python3-django-taggit
2.0.0-1 but was working with versions of python3-django-taggit less than
this version.
The relevant part from the autopkgtest is:
System check identified 25 issues (0 silenced).
ss.Ex...
==
ERROR: test_can_access_tags_on_unsaved_instance (tests.tests.test_tag.TagTest)
--
Traceback (most recent call last):
File
"/tmp/autopkgtest-lxc.4wu0r9tw/downtmp/autopkgtest_tmp/tests/tests/test_tag.py",
line 40, in test_can_access_tags_on_unsaved_instance
mission_burrito.tags.set('mexican', 'burrito')
File "/usr/lib/python3/dist-packages/taggit/utils.py", line 124, in inner
return func(self, *args, **kwargs)
File "/usr/lib/python3/dist-packages/modelcluster/contrib/taggit.py", line
78, in set
return super(_ClusterTaggableManager, self).set(*tags, clear=True)
File "/usr/lib/python3/dist-packages/taggit/utils.py", line 124, in inner
return func(self, *args, **kwargs)
TypeError: set() takes 2 positional arguments but 3 were given
--
The full log (for amd64) can be found here;:
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-django-modelcluster/17044291/log.gz
>From the changelog of django-taggit 2.0.0 I guess that the current
autopkgtest is breaking due a backwards incompatibility (hence that's
the main reason the version was bumped to 2.0.0).
https://github.com/jazzband/django-taggit/blob/2.0.0/CHANGELOG.rst#200-2021-11-14
I think python-django-modelcluster will need some adjustments to work
proper with the recent version of django-taggit, or at least an
adjustments of the used autopktest.
Regards
Carsten
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.14.0-4-amd64 (SMP w/6 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#997607: marked as pending in python-fudge
Control: tag -1 pending Hello, Bug #997607 in python-fudge reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-fudge/-/commit/9a97eccd0436fe6456f8d5c6401ea78962133057 Add a patch queue from a patchqueue branch Added patches: Porting-existing-code-over-to-Python3-by-using-2to3.patch Remove-version-check-in-setup.py.patch These patches are needed to get the source into Python3 compatible syntax. Closes: #997607 (this message was generated automatically) -- Greetings https://bugs.debian.org/997607
Bug#994257: marked as pending in django-ldapdb
Control: tag -1 pending Hello, Bug #994257 in django-ldapdb reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/django-ldapdb/-/commit/3b3ad57d01e07d0ac985f70d99a8b8f9d4f99a2f Adding patches from patch queue branch Added patches: 0001-Use-_base_manager-instead-of-objects-when-modifying-.patch 0002-router-disallow-migrations-on-ldap-connection-and-mo.patch 0003-Use-get_attname-instead-of-attname-attribute.patch 0004-tests-add-missing-contribute_to_class-to-fully-insta.patch 0005-Update-regex-to-be-compatible-with-django-2-to-Djang.patch Patches were picked from tge upstream git tree on GitHub. Closes: #994257 (this message was generated automatically) -- Greetings https://bugs.debian.org/994257
Bug#998114: Missing egg info directory prevents asciidoc cli tools from running
Hi Leon, Am Sat, Oct 30, 2021 at 06:45:28PM +0200 schrieb Leon Marz: > Thank you very much for finding the problem. I was quite confused since > everything was installed in the right place. As you already mentioned, > lintian doesn't like the egg-info directory and neither do I, so I wrote > custom scripts which call 'python3 -m asciidoc "$@"'. It seems to be > working according to autopkgtest and my own tests. > I uploaded the new version to https://mentors.debian.net/package/asciidoc/ adding the used autopkgtest to the package at all would help to detect failures like this reported one early by ci.d.n. So please consider to extend the current autopkgtests within the packaging. Regards Carsten
Bug#995465: django-restricted-resource: autopkgtest fails for python-django >= 3
Source: django-restricted-resource
Version: 2016.8-3
Severity: serious
Usertags: breaks needs-update
Control: found -1 python-django/2:3.2.7-4
Control: found -1 django-restricted-resource/2016.8-3
Dear Maintainer(s),
the latest upload of python-django is breaking the autopkgtest for
django-restricted-resource but was succeeding previously.
The broken autopkgtest is blocking python-django from migrating to
testing.
The relevant part of the broken testing is this:
==
ERROR: test_clean_is_okay_when_just_group_set
(django_restricted_resource.tests.ResourceCleanTests)
test_clean_is_okay_when_just_group_set
(django_restricted_resource.tests.ResourceCleanTests)
--
testtools.testresult.real._StringException: Traceback (most recent call last):
File
"/tmp/autopkgtest-lxc.r7b2wyms/downtmp/build.SBo/src/django_restricted_resource/test_project/../../django_restricted_resource/tests.py",
line 64, in test_clean_is_okay_when_just_group_set
resource = RestrictedResource(group=group)
File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 413, in
__init__
raise TypeError('Abstract models cannot be instantiated.')
TypeError: Abstract models cannot be instantiated.
==
ERROR: test_clean_is_okay_when_just_user_set
(django_restricted_resource.tests.ResourceCleanTests)
test_clean_is_okay_when_just_user_set
(django_restricted_resource.tests.ResourceCleanTests)
--
testtools.testresult.real._StringException: Traceback (most recent call last):
File
"/tmp/autopkgtest-lxc.r7b2wyms/downtmp/build.SBo/src/django_restricted_resource/test_project/../../django_restricted_resource/tests.py",
line 59, in test_clean_is_okay_when_just_user_set
resource = RestrictedResource(user=user)
File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 413, in
__init__
raise TypeError('Abstract models cannot be instantiated.')
TypeError: Abstract models cannot be instantiated.
==
ERROR: test_clean_raises_exception_when_both_user_and_group_is_set
(django_restricted_resource.tests.ResourceCleanTests)
test_clean_raises_exception_when_both_user_and_group_is_set
(django_restricted_resource.tests.ResourceCleanTests)
--
testtools.testresult.real._StringException: Traceback (most recent call last):
File
"/tmp/autopkgtest-lxc.r7b2wyms/downtmp/build.SBo/src/django_restricted_resource/test_project/../../django_restricted_resource/tests.py",
line 54, in test_clean_raises_exception_when_both_user_and_group_is_set
resource = RestrictedResource(user=user, group=group)
File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 413, in
__init__
raise TypeError('Abstract models cannot be instantiated.')
TypeError: Abstract models cannot be instantiated.
==
ERROR: test_clean_raises_exception_when_owner_is_not_set
(django_restricted_resource.tests.ResourceCleanTests)
test_clean_raises_exception_when_owner_is_not_set
(django_restricted_resource.tests.ResourceCleanTests)
--
testtools.testresult.real._StringException: Traceback (most recent call last):
File
"/tmp/autopkgtest-lxc.r7b2wyms/downtmp/build.SBo/src/django_restricted_resource/test_project/../../django_restricted_resource/tests.py",
line 48, in test_clean_raises_exception_when_owner_is_not_set
resource = RestrictedResource()
File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 413, in
__init__
raise TypeError('Abstract models cannot be instantiated.')
TypeError: Abstract models cannot be instantiated.
--
Ran 172 tests in 2.745s
The full log is visible under
https://ci.debian.net/data/autopkgtest/unstable/amd64/d/django-restricted-resource/15453285/log.gz
Regards
Carsten
Bug#994255: djangorestframework: autopkgtest needs update for new version of python-django: error changed
Control: forwarded -1
https://github.com/encode/django-rest-framework/issues/8160
Control: tags -1 upstream
Hi,
Am Tue, Sep 14, 2021 at 09:14:46PM +0200 schrieb Paul Gevers:
...
> _
> TestNaiveDayLightSavingTimeTimeZoneDateTimeField.test_invalid_inputs _
>
> self =
> object at 0x7fe05e8d3b80>
>
> def test_invalid_inputs(self):
> """
> Ensure that invalid values raise the expected validation error.
> """
> for input_value, expected_failure in get_items(self.invalid_inputs):
> with pytest.raises(serializers.ValidationError) as exc_info:
> self.field.run_validation(input_value)
> > assert exc_info.value.detail == expected_failure, \
> 'input value: {}'.format(repr(input_value))
> E AssertionError: input value: '2017-03-12T02:30:00'
> E assert [ErrorDetail(...de='invalid')] == ['Invalid
> dat...a/New_York".']
> E At index 0 diff: ErrorDetail(string='Datetime has wrong
> format. Use one of these formats instead:
> -MM-DDThh:mm[:ss[.uu]][+HH:MM|-HH:MM|Z].', code='invalid') !=
> 'Invalid datetime for the timezone "America/New_York".'
> E Use -v to get the full diff
>
there is an upstream issue opened which seems to be the same topic.
https://github.com/encode/django-rest-framework/issues/8160
Regards
Carsten
Bug#994256: django-axes: autopkgtest needs update for new version of python-django: warnings changed
Hi, Am Tue, Sep 14, 2021 at 09:18:18PM +0200 schrieb Paul Gevers: ... > Currently this regression is blocking the migration of python-django to > testing [1]. Of course, python-django shouldn't just break your > autopkgtest (or even worse, your package), but it seems to me that the > change in python-django was intended and your package needs to update to > the new situation. > > If this is a real problem in your package (and not only in your > autopkgtest), the right binary package(s) from python-django should > really add a versioned Breaks on the unfixed version of (one of your) > package(s). Note: the Breaks is nice even if the issue is only in the > autopkgtest as it helps the migration software to figure out the right > versions to combine in the tests. I did a quick import of the currently most recent version 5.24.0 and did afterwards a rebuild of this version. The built of the binary packages and also the autopkgtest works without further needed adjustments so updating django-axes to a recent version would be enough to fix this issue. Regards Carsten
Bug#989839: Bug#989843: thunderbird: Problem loading page: NS_ERROR_NET_INADEQUATE_SECURITY
Control: tags 989839 severity important Control: tags 989843 severity important Control: merge 989843 989839 thanks Hello *, decreasing the severity as Thunderbird isn't *completely* unusable. Am 14.06.21 um 19:31 schrieb Todor Tsankov: > Dear Maintainer, > > Since the update to 78.11.0 Thunderbird cannot load various webpages. To > reproduce the error, try to do a search in the Add-ons Manager (type > something in the search box and press Enter). > > The error message is > > "The website tried to negotiate an inadequate level of security. > ... > Error code: NS_ERROR_NET_INADEQUATE_SECURITY" > > There is perhaps a more useful error message in the error console: > > addons.thunderbird.net : server does not support RFC 5746, see CVE-2009-3555 Well, both messages are almost enough information to step into an analysis and search for data on various internet web sites. There are quite some web resources out there that explain what's going wrong here (beside we don't know exactly why). I'm quoting from https://support.mozilla.org/en-US/questions/1312785 -%<- > NS_ERROR_NET_INADEQUATE_SECURITY indicates that the server initiates > a HTTP/2 connection, but Firefox detects an invalid TLS configuration > in the server response (server negotiated HTTP/2 with blacklisted > cipher suites). This is likely not an issue with the certificate, but > this is a problem with the server setup and there are invalid cipher > suites for HTTP/2 claimed (INADEQUATE_SECURITY).> > http://httpwg.org/specs/rfc7540.html#TLSUsage There might also be > other software that acts as a MITM and is interfering. When HTTP/2 is > enabled and used then the requirements are much stricter than with > HTTP/1.1 You can get the NS_ERROR_NET_INADEQUATE_SECURITY error > message in case the server isn't configured properly.> > A workaround to fix this ANNOYING issue is; > network.http.spdy.enabled.http2 = false in about:config ->%- So, to recap: The server is sending over a HTTP/2 connection, but Thunderbird, or more precisely the NSS3 library (depending on the configuration of Thunderbird) is detecting some invalid TLS data and is stopping the communication by presenting this message about NS_ERROR_NET_INADEQUATE_SECURITY because the settings are that strict to not going further. > The problem also appears when trying to load other pages or using > certain add-ons (for example, calendar-google-provider). > > The problem goes away if one sets network.http.spdy.enforce-tls-profile > to false in the preferences. This makes me think that there is an issue > with the TLS library. This isn't a problem solution, it's a workaround that disables the TLS validation check. And if Thunderbird is instructed to ignore any security settings related to SSL/TLS it's not really surprising that the previously seen issues seems to have gone. Currently I've no real idea what's the reason why 78.11.0 is working differently than the previous version 78.10.x. And further more it's also possible that the external resources have a real problem regarding the TLS settings. This needs clarification and analysis of the underlying data flow. Both Thunderbird versions 78.10.x and 78.11.x are using the same underlying libnss3 version, that hasn't changed since 2021-02-18. That's the main difference to the Thunderbird version in stable-security, there we use the internal shipped NSS3 source to build the packages and so far we haven't seen bug reports from stable users. The build checks for a minimum required NSS3 version. > 0:10.34 checking for nss >= 3.53.1... yes In the archive we have 3.61 so it's clear the check is passing. The upstream source for Thunderbird 78.11.0 comes with NSS3 version 3.51.1 and this hasn't changed since the introducing of Thunderbird ESR series 78.x. In can currently only think of some other different internal behavior of 78.11.0 together with NSS3 from the system. The changelog from Mozilla for 78.11.0 isn't giving any hint that some upstream modification might be the reason for the different behavior. Closed bug reports between 78.10.2 and 78.11.0 > https://bugzilla.mozilla.org/buglist.cgi?bug_id=1709046%2C1697252%2C1712469%2C1700279%2C1695592%2C1709492%2C1704161%2C1707569%2C1712610%2C1712632%2C1712293 Closed bug reports between 78.10.1 and 78.10.2 > https://bugzilla.mozilla.org/buglist.cgi?bug_id=1673241%2C1701924%2C1709261%2C1654893%2C1658216%2C1701908%2C1707408%2C1702582%2C1697075%2C1707021%2C1691297%2C1701356%2C1710290%2C1692616%2C1671051%2C1686984%2C1681131%2C1673277%2C1679713%2C1704435 So to work around the problems users can do the following modification to their profile settings. Set network.http.spdy.enforce-tls-profile = false If this isn't working this setting can set to false also set network.http.spdy.enabled.http2 = false But please note! This decreases the transport security and should later get get reset to the default, if not Thunderbird will use the insecure setting for ever! -- Regards
Bug#989657: Current sogo-connector does not work with current Mozilla Thunderbird
Hello Narcis, Am Wed, Jun 09, 2021 at 05:17:39PM +0200 schrieb Narcis Garcia: > thunderbird(68) + lightning(68) + webext-sogo-connector(68) do show > "Subscribe to addressbook" button at Address book page. > I suppose webext-sogo-connector needs to be packaged as version(78) > compatible with thunderird 78. if upstream would release a newer version than the current avialable I'm happy to package it. https://github.com/inverse-inc/sogo-connector But there isn't any newer version than the one in the archive released by upstream in between. So it's probably better to remove the current package from the archive. Regards Carsten
Bug#985195: qemu-system 1:5.2+dfsg-6+b1 isn't installable
Package: qemu-system Severity: serious Dear Maintainer, while working with a fresh created pbuilder based chroot I encountered that the package qemu-system is not installable currently since the recently happen NMU. root@x260:/# apt install qemu-system Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: qemu-system-data : Depends: qemu-system-x86 (= 1:5.2+dfsg-6) but 1:5.2+dfsg-6+b1 is to be installed or qemu-system-arm (= 1:5.2+dfsg-6) but 1:5.2+dfsg-6+b1 is to be installed or qemu-system-mips (= 1:5.2+dfsg-6) but 1:5.2+dfsg-6+b1 is to be installed or qemu-system-ppc (= 1:5.2+dfsg-6) but 1:5.2+dfsg-6+b1 is to be installed or qemu-system-sparc (= 1:5.2+dfsg-6) but 1:5.2+dfsg-6+b1 is to be installed or qemu-system-misc (= 1:5.2+dfsg-6) but 1:5.2+dfsg-6+b1 is to be installed or qemu-system-s390x (= 1:5.2+dfsg-6) or qemu-system-x86-xen (= 1:5.2+dfsg-6) but it is not installable E: Unable to correct problems, you have held broken packages. This strict dependency won't be solvable without modifications to version requirements. One possible solution would the usage of '=>' instead of '='. But this decision to make is up to the maintainer of this package. Regards Carsten -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, aarch64, arm64 Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qemu-system depends on: pn qemu-system-arm pn qemu-system-mips pn qemu-system-misc pn qemu-system-ppc pn qemu-system-sparc ii qemu-system-x861:5.2+dfsg-6 qemu-system recommends no packages. qemu-system suggests no packages.
Bug#982130: rust-cbindgen_0.17.0-1_s390x.changes REJECTED
Hi, Am Sat, Feb 06, 2021 at 06:48:34PM +0100 schrieb Aurelien Jarno: > Source: rust-cbindgen > Version: 0.17.0-1 > Severity: serious > > - Forwarded message from Debian FTP Masters > - > > From: Debian FTP Masters > To: s390x Build Daemon > Date: Sat, 06 Feb 2021 17:18:49 + > Subject: rust-cbindgen_0.17.0-1_s390x.changes REJECTED > Message-Id: > > > > cbindgen_0.17.0-1_s390x.deb: has 1 file(s) with a timestamp too far in the > past: > usr/share/doc/cbindgen/changelog.gz (Thu Jan 1 00:00:00 1970) this looks like a hickup on the buildd, shouldn't a give back potentially fix this issue? But maybe I don't see the whole picture. Regards Carsten
Bug#981300: arduino-core-avr breaks arduino-mk
Hi, Am Wed, Feb 03, 2021 at 06:50:26AM +0100 schrieb Carsten Schoenert: > the most safe action currently would be to just update the Depends > fields so that arduino-mk would also get shipped within the bullseye > release without doubt. I will do a NMU with delayed/3 later today with that option so the arduino tranistion will not longer than needed blocked. Regards Carsten
Bug#981300: arduino-core-avr breaks arduino-mk
Hello, the most safe action currently would be to just update the Depends fields so that arduino-mk would also get shipped within the bullseye release without doubt. Updating to a newer version could be done anyway until the hard freeze is starting. Regards Carsten
Bug#981300: arduino-core-avr breaks arduino-mk
Hi again,
Am Mon, Feb 01, 2021 at 07:54:51PM +0100 schrieb Carsten Schoenert:
> > the problem tends to be getting arduino-mk updated, think last time it
> > needed a team upload (python3 fixes).
>
> If you need help let me know, currently I can't that Python3 fixes you
> mean.
hrhr, I need to read my writing again before start sending this...
I meant here I can't see what fixes will get needed.
O.k., I quickly imported 1.6.0 and there is one more .py file added to
the bin/ folder.
Running 2to3 on the folder shows just small further needed adjustments.
$ 2to3-2.7 bin/*
RefactoringTool: Skipping optional fixer: buffer
RefactoringTool: Skipping optional fixer: idioms
RefactoringTool: Skipping optional fixer: set_literal
RefactoringTool: Skipping optional fixer: ws_comma
RefactoringTool: Refactored bin/ard-reset-arduino
--- bin/ard-reset-arduino (original)
+++ bin/ard-reset-arduino (refactored)
@@ -1,6 +1,6 @@
#!/usr/bin/env python
-from __future__ import print_function
+
import serial
import os.path
import argparse
RefactoringTool: Refactored bin/robotis-loader
--- bin/robotis-loader (original)
+++ bin/robotis-loader (refactored)
@@ -25,7 +25,7 @@
def progressBar(percent, precision=65):
threshold=precision*percent/100.0
sys.stdout.write('[ ')
-for x in xrange(0, precision):
+for x in range(0, precision):
if x < threshold: sys.stdout.write('#')
else: sys.stdout.write(' ')
sys.stdout.write(' ] ')
@@ -36,7 +36,7 @@
stat = os.stat(binary)
size = stat.st_size
firmware = file(binary, 'rb')
-print('* Opening %s, size=%d' % (binary, size))
+print(('* Opening %s, size=%d' % (binary, size)))
except:
exit('! Unable to open file %s' % binary)
@@ -80,7 +80,7 @@
break
print('')
s.setDTR(True)
-print('* Checksum: %d' % (cs))
+print(('* Checksum: %d' % (cs)))
s.write(chr(cs))
print('* Firmware was sent')
else:
@@ -91,4 +91,4 @@
s.close()
exit()
else:
-print('Board -> '+line)
+print(('Board -> '+line))
RefactoringTool: Files that need to be modified:
RefactoringTool: bin/ard-reset-arduino
RefactoringTool: bin/robotis-loader
Seems doable without big headaches. Let me know how you like to proceed.
Regards
Carsten
Bug#981300: arduino-core-avr breaks arduino-mk
Hello Simon, you need to add me to the recipients please, then I get the emails for this report too. :) Am Fri, Jan 29, 2021 at 12:22:18PM + schrieb Simon John: > Hello Carsten, > > i rebuilt arduino-mk and removed its Depends and it worked, so changing it > to "arduino-core (>= 2:1.8.13+dfsg1-1)" would be the proper fix. I need to correct myself a bit, please do not use the old package name here, please use the real package. This would be this: arduino (>= 2:1.8.13+dfsg1-1 > the problem tends to be getting arduino-mk updated, think last time it > needed a team upload (python3 fixes). If you need help let me know, currently I can't that Python3 fixes you mean. If youe need a sponsor then I'm also willing to help. Regards
Bug#951770: libpam-radius-auth: do not release in bullseye without active maintainer
retitle -1 ITA: picking up maintenance of libpam-radius-auth Hello Salvatore, Am Fri, Feb 21, 2020 at 03:03:12PM +0100 schrieb Salvatore Bonaccorso: > Source: libpam-radius-auth > Version: 1.4.0-3 > Severity: serious > Justification: should not be released in bullseye without active maintainer > > libpam-radius-auth has been orphaned in Debian since several years and > QA maintained. It did had at least the CVE-2015-9542 security issue. > > There are no packages blocking a potential removal, so the package > should get an active maintainer to be part of bullseye ideally. Christoph Goehre and myself are taking over the maintenace of this package, we use RADIUS authentication daily on our day job and we have a strong interrest that this package will stay in Debian. ;) Regards Carsten
Bug#977891: opencascade: library package names do not follow SOVERSION
Hello, the latest information about the piuparts run with version 7.5.0+dfsg1-3 says this issue isn't any longer existing. The issue was already addressed in the -2 upload so far I can see. https://piuparts.debian.org/sid/source/o/opencascade.html Simplay forgotten to close the report by the -2 upload? Regards Carsten Am Tue, Dec 22, 2020 at 02:25:31PM +0100 schrieb Andreas Beckmann: > Source: opencascade > Version: 7.5.0+dfsg1-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package fails to upgrade from > 'stable'. > It installed fine in 'stable', then the upgrade to 'sid' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. > > See policy 7.6 at > https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces > > This test intentionally skipped 'testing' to find file overwrite > problems before packages migrate from 'unstable' to 'testing'. > > From the attached log (scroll to the bottom...): > > Preparing to unpack .../0-libocct-foundation-7.5_7.5.0+dfsg1-1_amd64.deb ... > Unpacking libocct-foundation-7.5:amd64 (7.5.0+dfsg1-1) ... > dpkg: error processing archive > /tmp/apt-dpkg-install-ytPrh7/0-libocct-foundation-7.5_7.5.0+dfsg1-1_amd64.deb > (--unpack): >trying to overwrite '/usr/lib/x86_64-linux-gnu/libTKMath.so.7', which is > also in package libocct-foundation-7.3:amd64 7.3.0+dfsg1-5 > Preparing to unpack .../1-libocct-modeling-data-7.5_7.5.0+dfsg1-1_amd64.deb > ... > Unpacking libocct-modeling-data-7.5:amd64 (7.5.0+dfsg1-1) ... > dpkg: error processing archive > /tmp/apt-dpkg-install-ytPrh7/1-libocct-modeling-data-7.5_7.5.0+dfsg1-1_amd64.deb > (--unpack): >trying to overwrite '/usr/lib/x86_64-linux-gnu/libTKBRep.so.7', which is > also in package libocct-modeling-data-7.3:amd64 7.3.0+dfsg1-5 > Preparing to unpack > .../2-libocct-modeling-algorithms-7.5_7.5.0+dfsg1-1_amd64.deb ... > Unpacking libocct-modeling-algorithms-7.5:amd64 (7.5.0+dfsg1-1) ... > dpkg: error processing archive > /tmp/apt-dpkg-install-ytPrh7/2-libocct-modeling-algorithms-7.5_7.5.0+dfsg1-1_amd64.deb > (--unpack): >trying to overwrite '/usr/lib/x86_64-linux-gnu/libTKBO.so.7', which is > also in package libocct-modeling-algorithms-7.3:amd64 7.3.0+dfsg1-5 > Preparing to unpack .../3-libocct-visualization-7.5_7.5.0+dfsg1-1_amd64.deb > ... > Unpacking libocct-visualization-7.5:amd64 (7.5.0+dfsg1-1) ... > dpkg: error processing archive > /tmp/apt-dpkg-install-ytPrh7/3-libocct-visualization-7.5_7.5.0+dfsg1-1_amd64.deb > (--unpack): >trying to overwrite '/usr/lib/x86_64-linux-gnu/libTKMeshVS.so.7', which is > also in package libocct-visualization-7.3:amd64 7.3.0+dfsg1-5 > Preparing to unpack .../4-libocct-ocaf-7.5_7.5.0+dfsg1-1_amd64.deb ... > Unpacking libocct-ocaf-7.5:amd64 (7.5.0+dfsg1-1) ... > dpkg: error processing archive > /tmp/apt-dpkg-install-ytPrh7/4-libocct-ocaf-7.5_7.5.0+dfsg1-1_amd64.deb > (--unpack): >trying to overwrite '/usr/lib/x86_64-linux-gnu/libTKBin.so.7', which is > also in package libocct-ocaf-7.3:amd64 7.3.0+dfsg1-5 > Preparing to unpack .../5-libocct-data-exchange-7.5_7.5.0+dfsg1-1_amd64.deb > ... > Unpacking libocct-data-exchange-7.5:amd64 (7.5.0+dfsg1-1) ... > dpkg: error processing archive > /tmp/apt-dpkg-install-ytPrh7/5-libocct-data-exchange-7.5_7.5.0+dfsg1-1_amd64.deb > (--unpack): >trying to overwrite '/usr/lib/x86_64-linux-gnu/libTKBinXCAF.so.7', which > is also in package libocct-data-exchange-7.3:amd64 7.3.0+dfsg1-5 > Errors were encountered while processing: > > /tmp/apt-dpkg-install-ytPrh7/0-libocct-foundation-7.5_7.5.0+dfsg1-1_amd64.deb > > /tmp/apt-dpkg-install-ytPrh7/1-libocct-modeling-data-7.5_7.5.0+dfsg1-1_amd64.deb > > /tmp/apt-dpkg-install-ytPrh7/2-libocct-modeling-algorithms-7.5_7.5.0+dfsg1-1_amd64.deb > > /tmp/apt-dpkg-install-ytPrh7/3-libocct-visualization-7.5_7.5.0+dfsg1-1_amd64.deb >/tmp/apt-dpkg-install-ytPrh7/4-libocct-ocaf-7.5_7.5.0+dfsg1-1_amd64.deb > > /tmp/apt-dpkg-install-ytPrh7/5-libocct-data-exchange-7.5_7.5.0+dfsg1-1_amd64.deb > > From looking the the file list of libocct-data-exchange-7.5 I observed > that there are multiple shared libraries (and nothing else), but all have > the same SOVERSION (7). So why is the package naming following MAJOR.MINOR > instead of SOVERSION? The latter would ease maintenance by avoiding lots > of Breaks+Replaces in the future. > This is probably the same for all the packages shipping opencascade shared > libraries. > > cheers, > > Andreas > > PS: If the libraries from 7.3 and 7.5 are not exchangeable (i.e. not API and > ABI > compatible), they should not have the same SOVERSION.
Bug#968102: [Pkg-mozext-maintainers] Bug#968102: Bug#968102: new upstream release (2.16)
Hello Mechtilde, Am 07.10.20 um 10:34 schrieb Mechtilde: > Hello, > > I will do a update-proposal for buster ASAP. > > Do I still have to consider something to get it drectly into buster and > not just with the next point release. that's a decision finally made by the RT. https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#upload-stable I'm sure if you kindly ask and can describe why an upload to stable-update instead of proposed-updates is useful for Debian and it's users the RT will probably follow your request. -- Regards Carsten Schoenert
Bug#971737: lightning: all calendars disappeared (and throws errors when double-clicked)
Hi, Am 06.10.20 um 09:06 schrieb IOhannes m zmölnig (Debian/GNU): > I'm using thunderbird/lightning to show a few of my online calendars > (iCal, caldav,... you name it). > i recently (2 weeks ago) wiped my harddisk and setup a brand new system. > all the calendars showed up nicely (afaict, this was with > thunderbird-1:68.12.0-1). > > when i did a routine upgrade a few days ago (now running > thunderbird-1:78.3.1-1), > i found none of my calendars are displaying any appointments any more > (nice: nothing to do! ;-() > > when i double click the calendar, i get a tiny window (10x10px or so) > which i can resize to normal. then it shows: > > ``` > The file > /usr/share/lightning/chrome/calendar/content/calendar/calendarCreation.xul > cannot be found. Please check the location and try again. > > Check the file name for capitalization or other typing errors. > Check to see if the file was moved, renamed or deleted. > ``` > > indeed that file is not there. > > as such, the calendar functionality of thunderbird is severely broken. you are sure you all done this within a clean environment? I can't reproduce this if I start from scratch with a complete new profile. Works here locally as expected. I can setup an email account and can afterwards add more than one new local calendar. lightning is since version 1:76.0_b1-1 a transitional package so there aren't any files within this package except the default Debian specific files. > $ dpkg -L lightning > /. > /usr > /usr/share > /usr/share/doc > /usr/share/doc/lightning > /usr/share/doc/lightning/changelog.Debian.gz > /usr/share/doc/lightning/copyright Any Add-ons installed locally within the copied profile? Any Add-on not disabled while working on the profile? -- Regards Carsten Schoenert
Bug#966582: thunderbird: Thunderbird user interface is inconrrectly displayed after changing language of display menus to Spanish (Spain) or English (UK). It shows a wrong resolution and red tags belo
Control: severity -1 important Decreasing the sevrity as the potential issue doesn't render Thunderbird unusable for all users. Hello Gustavo, On Thu, Jul 30, 2020 at 09:18:12PM -0500, Gustavo Adolfo Gutiérrez Enriquez wrote: >* What led up to the situation? > After installing Thunderbird from the Store, I opened thunderbird preferences > and changed the Languages used to display menus, messages and notifications, > particularly, I added Spanish (Spain) and English (UK) in that order using the > Set Alternative button. can you a bit explain what do you mean installing Thunderbird from the store? Debian has noch such thing, it only provides packages from various archives. So the only supported way within Debian is to use the packages from the archive. The output of the reportbug colloections doesn't show any language specific package installed. What is the output of 'LANG= dpkg -l thunderbird* lightning*'? Regards Carsten
Bug#955638: cargo: please package recent version
Hi Ximin, Am 18.04.20 um 21:01 schrieb Ximin Luo: Sorry, I had a brain-fart here. We have 2 cargo packages, 1 (rust-cargo) that is part of our rust crate packaging ecosystem with its web of dependencies, and 1 (cargo) that explicitly embeds its dependencies to avoid this type of issue. > The latter is what you want, and I've just uploaded it too, so there should be no need to wait for the below packages. I got confused earlier because we use rust-cargo to update cargo, and I temporarily forgot my own instructions on updating the packaging. > So Thunderbird should now be unblocked on this front. thanks! In the between time I've untangled the remaining build issues (and removed the version check for cargo for now) within the latest beta and could create working packages. I uploaded these a few hours ago and TB 1:76.0~b1-1 waits for review in NEW too. I'm happy I did make some remarkable process on this! -- Regards Carsten Schoenert
Bug#953549: kopanocore: FTBFS with Python 3.8
Hello Graham, Am 15.03.20 um 10:23 schrieb Graham Inggs: > On Sun, 15 Mar 2020 at 10:55, Carsten Schoenert > wrote: >> Look's like the check to find Python is now failing for Python 3.8. >> The relevant part in configure.ac (line 676 to 688) is this: > > I think you'll need at least this patch from Ubuntu: > https://launchpad.net/ubuntu/+source/kopanocore/8.7.0-5ubuntu8 ahh, cool! Thanks for this pointer. I've tried to look into some new upstream modification related to Python 3.8 but did not find anything yet. I'll keep this fix from Matthias and prepare a new upload. -- Regards Carsten Schoenert
Bug#953549: kopanocore: FTBFS with Python 3.8
On Tue, Mar 10, 2020 at 03:27:59PM +0200, Graham Inggs wrote: > Hi Maintainer > > kopanocore FTBFS when rebuilt with Python 3.8 [1] > I hope the following is the relevant part of the log: > > checking for PYTHON... yes > configure: error: python requested but not satisfiable > cd debian/build && tail -v -n \+0 config.log Look's like the check to find Python is now failing for Python 3.8. The relevant part in configure.ac (line 676 to 688) is this: AC_ARG_ENABLE([python], [AS_HELP_STRING([--enable-python], [Enable building of Python bindings (default: auto)])], [want_python="$enableval"], [want_python=auto]) AS_IF([test "$want_python" != no], [ PKG_CHECK_MODULES([PYTHON], [$PYTHON_PC], [], [:]) AS_IF([test -n "$PYTHON_LIBS"], [ AC_PATH_PROG([SWIG_EXEC], [swig]) AM_PATH_PYTHON([2.5]) AS_IF([test -z "$SWIG_EXEC"], [AC_MSG_ERROR([swig is required for Python])]) AC_DEFINE([ENABLE_PYTHON], [1]) ], [test "$want_python" = yes], [ AC_MSG_ERROR([python requested but not satisfiable]) ]) ])
Bug#950512: quotecolors: not usable anymore with TB>= 68.x
Source: quotecolors Severity: serious Hello Christoph, xul-ext-quotecolors isn't usable with Thunderbird 68.x due API incompatibilities. There is no new version provided by upstream which is usable again with recent Thunderbird versions so this package is useless now. The whole package should be removed from the archives. Regards Carsten -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, aarch64, arm64 Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#949703: severity of 949703 is serious, closing 949703
severity 949703 serious close 949703 thanks
Bug#940906: make autopkgtest working
Hello Graham, Am 10.12.19 um 08:24 schrieb Graham Inggs: > This bug is RC, feel free to prepare an NMU. > Even better, join Debian Science and team upload. :-) I wont have much time to work active on the wide area of science packages except the glm package but I'm fine if you are o.k. if I join the science team on Salsa if this make things also easier for you. At least for me is it useful if I can work on glm in a more comfortable way as I'd also need a backported version of the current glm package for buster e.g. Will request team access on Salsa. -- Regards Carsten Schoenert
Bug#946347: Thunderbird: After dist-upgrade thunderbird thinks it is too old.
Control: severity -1 normal Hello Robert, On Sat, Dec 07, 2019 at 05:25:22PM +0100, Robert Pommrich wrote: > After a dist-upgrade from stretch to buster with thunderbird installed > in version 68.2.2-1~deb9u1 and being upgraded to version > 68.2.2-1~deb10u1 thunderbird shows a message at the start: > > "A newer version of Thunderbird may have made changes to your profile which > are no longer > compatible with this older version. > Use this profile only with that newer version, or create a new profile for > this installation of > Thunderbird. Creating a new profile requires setting up your accounts, > calendars and add-ond again." > > This is strange and should not happen, as the version of Thunderbird > is practically the same. this usaly happen if users have used some pre-built version from Mozilla. Seeing this message isn't something you can blame the Thunderbird package from Debian as you have used non packaged software on your own. https://support.mozilla.org/en-US/kb/unable-launch-older-version-profile Please adjust your local profile settings by reading the ressource I've linked above. Regards Carsten
Bug#918163: Broken in Stretch
Control: tags -1 stretch Control: tags -1 buster Control: tags -1 sid Control: severity - 1 serious Hi, and once again this package isn't working anymore due the API change for AddOns that are introduced by Thunderbird 68.x Thunderbird now requires AddOns that are build as webextension. So far I've seen this package needs to get updated to version 0.3.1 to get it working in Thunderbird 68.x. This will requiring changes to the Debian packaging. Examples how the packaging needs to be done to fit the requirements to get system wide installed Thunderbird AddOns recognized by Thunderbird can be found on these packages e.g. https://salsa.debian.org/webext-team/compactheader/tree/debian/sid/debian https://salsa.debian.org/webext-team/tbsync/tree/debian/experimental/debian Please also move over the binary package name to webext-sieve-extension as this was discussed and wantied naming schema within the Mozilla Packaging Team. This will require to make the old binary name a transitional package. If you want or need help please say so. Thanks! Regards Carsten
Bug#944263: python-releases: FTBFS in unstable
Control: tags -1 patch Hi, I tried to use the newer upstream version to see if this issue might be fixed here. But no, it's still existing also in version 1.6.1. But there is an MR in the upstream poject that fixes this build issue. https://github.com/bitprophet/releases/pull/86 The origin of this MR can be found here. https://github.com/rbarrois/releases/commit/8787236dffb7383427b3e1448ece9a5b3eaf5257 I can confirm that this patch fixes the FTBFS for 1.4.0 but also with the current most recent upstream version 1.6.1. Regards Carsten
Bug#945061: uninstallable due to Thunderbird security update to version 68
Hello Philipp, Am 19.11.19 um 08:43 schrieb Philipp Huebner: > Hi, > > due to the security update introducing Thunderbird 68, > xul-ext-sogo-connector has become uninstallable and thus unusable in all > suites from oldstable to unstable. > > Could you please package sogo-connector 68? > > (old-)stable updates would also be greatly appreciated. > I'd be happy to help test updated packages. I'd like to do so but unfortunately my time for doing so is really limited right now. The free time I have is mainly focused on working n Thunderbird itself. Also upstream has released a fixed version just a few weeks ago. For now I just can suggest to use the upstream version of this AddOn. -- Regards Carsten Schoenert
Bug#944715: thunderbird ftbfs on mips64el during rebuild for libevent 2.1.7
meh, also the second email with the correct recipient got bounced by T-Online ... :-/ Using now the Give-Back web interface by calling https://buildd.debian.org/auth/giveback.cgi?pkg=thunderbird=sid=mips64el More on give back service: https://debblog.philkern.de/2019/08/alpha-self-service-buildd-givebacks.html -- Regards Carsten Schoenert
Bug#944715: thunderbird ftbfs on mips64el during rebuild for libevent 2.1.7
Dear buildd admins, could you please reschedule the thunderbird build in unstable for misp64el? I've tested a rebuild without any changes on eller.d.o and the build went fine there. My guess is that the buildd had some hiccup while the configure run of Thunderbird. Thanks! Carsten Am 14.11.19 um 09:56 schrieb Paul Gevers: > Source: thunderbird > Version: 1:68.2.2-1 > Severity: serious > Tags: ftbfs sid bullseye > Justification: ftbfs > > Dear maintainers, > > Your package is part of the libevent transition. I binNMU'ed your package but > if fails to build on mips64el. Can you please investigate the situation? > > Paul > > https://buildd.debian.org/status/package.php?p=thunderbird > > Tail of log for thunderbird on mips64el: > > 3:26.57 js/src> checking whether the C++ compiler supports > -Wno-gnu-zero-variadic-macro-arguments... yes > 3:27.08 js/src> checking whether the C++ compiler supports > -Wno-noexcept-type... yes > 3:27.60 js/src> checking whether the C++ compiler supports > -fno-sized-deallocation... yes > 3:27.63 js/src> checking for rustc... /usr/bin/rustc > 3:27.63 js/src> checking for cargo... /usr/bin/cargo > 3:30.11 js/src> checking rustc version... 1.37.0 > 3:30.30 js/src> checking cargo version... 1.36.0 > 3:30.45 js/src> ERROR: Command `/usr/bin/rustc --print target-list` failed > with exit status -10. > 3:30.83 *** Fix above errors and then restart with\ > 3:30.83"./mach build" > 3:30.83 make[2]: *** [client.mk:115: configure] Error 1 > 3:30.83 make[2]: Leaving directory '/<>' > make[1]: *** [debian/rules:112: override_dh_auto_configure] Error 2 > make[1]: Leaving directory '/<>' > make: *** [debian/rules:83: build-arch] Error 2 > > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'testing-debug') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US:en (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > -- no debconf information > >
Bug#944715: thunderbird ftbfs on mips64el during rebuild for libevent 2.1.7
resend after fixing main recipient :-) Am 16.11.19 um 16:38 schrieb Carsten Schoenert: > Dear buildd admins, > > could you please reschedule the thunderbird build in unstable for misp64el? > > I've tested a rebuild without any changes on eller.d.o and the build > went fine there. > > My guess is that the buildd had some hiccup while the configure run of > Thunderbird. > > Thanks! > Carsten > > Am 14.11.19 um 09:56 schrieb Paul Gevers: >> Source: thunderbird >> Version: 1:68.2.2-1 >> Severity: serious >> Tags: ftbfs sid bullseye >> Justification: ftbfs >> >> Dear maintainers, >> >> Your package is part of the libevent transition. I binNMU'ed your package but >> if fails to build on mips64el. Can you please investigate the situation? >> >> Paul >> >> https://buildd.debian.org/status/package.php?p=thunderbird >> >> Tail of log for thunderbird on mips64el: >> >> 3:26.57 js/src> checking whether the C++ compiler supports >> -Wno-gnu-zero-variadic-macro-arguments... yes >> 3:27.08 js/src> checking whether the C++ compiler supports >> -Wno-noexcept-type... yes >> 3:27.60 js/src> checking whether the C++ compiler supports >> -fno-sized-deallocation... yes >> 3:27.63 js/src> checking for rustc... /usr/bin/rustc >> 3:27.63 js/src> checking for cargo... /usr/bin/cargo >> 3:30.11 js/src> checking rustc version... 1.37.0 >> 3:30.30 js/src> checking cargo version... 1.36.0 >> 3:30.45 js/src> ERROR: Command `/usr/bin/rustc --print target-list` failed >> with exit status -10. >> 3:30.83 *** Fix above errors and then restart with\ >> 3:30.83"./mach build" >> 3:30.83 make[2]: *** [client.mk:115: configure] Error 1 >> 3:30.83 make[2]: Leaving directory '/<>' >> make[1]: *** [debian/rules:112: override_dh_auto_configure] Error 2 >> make[1]: Leaving directory '/<>' >> make: *** [debian/rules:83: build-arch] Error 2 >> >> >> -- System Information: >> Debian Release: bullseye/sid >> APT prefers testing >> APT policy: (990, 'testing'), (500, 'testing-debug') >> Architecture: amd64 (x86_64) >> >> Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores) >> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, >> TAINT_UNSIGNED_MODULE >> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), >> LANGUAGE=en_US:en (charmap=UTF-8) >> Shell: /bin/sh linked to /bin/dash >> Init: systemd (via /run/systemd/system) >> LSM: AppArmor: enabled >> >> -- no debconf information >> >> -- Mit freundlichen Grüßen Carsten Schönert
Bug#943584: xul-ext-dispmua: AddOn does not work with Thunderbird 68.x
Package: xul-ext-dispmua Version: 1.8.2-1 Severity: grave Dear Maintainer, the extension does not work with TB 68 anymore. The AddOn is not detected by the curent new TB ESR version. Regards Carsten -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, aarch64, arm64 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xul-ext-dispmua depends on: ii thunderbird 1:68.2.0-1 xul-ext-dispmua recommends no packages. xul-ext-dispmua suggests no packages. -- no debconf information
Bug#941542: [Pkg-electronics-devel] Bug#941542: ngspice: build-depend on texlive-plain-generic, not obsolete texlive-generic-recommended
Control: tags -1 + pending Hello Steve, Am 01.10.19 um 23:33 schrieb Steve Langasek: > Dear maintainers, > > The texlive-generic-recommended transitional package has been dropped from > texlive-base in sid. Please update your build-dependency to > texlive-plain-generic instead. thanks for the diff. I applied your modification. I wasn't aware of this change. -- Regards Carsten Schoenert
Bug#925837: systemc: ftbfs with GCC-9
Am 18.08.19 um 03:13 schrieb أحمد المحمودي: > And a bit of access to architecturesthat I don't have access to (arm64 > for example) Even if you are not a DD you can get access to the porterboxes. For exactly this reason like here. https://dsa.debian.org/doc/guest-account/ If this is all to much work for you drop me a note you need help with the symbols file. I'll have a look at this of course. systemc isn't moving that fast this additional work isn't possible for me. BTW: The main mess with the symbols file would go away it upstream would use versioned symbols! That would decrease the amount of content within the symbols file to a minimum. > As far as I understand the symnols files is to track symbol changes due > to changes in the library itself, not the compiler used to build that > library ! To track symbol changes within the library itself it isn't really helpful if these changes aren't visible for other tools. So the main goal is that dh-mkshlibdeps can get information about the depending minimal version for the depending library while building the list of the depending libraries for a package. This all has nothing to do directly with the used compiler or linker. The libsystemc package isn't a central library like libc e.g. for sure, otoh it's not that complicated to keep track of the symbol name changes and provide a symbols file. -- Regards Carsten Schoenert
Bug#925837: systemc: ftbfs with GCC-9
Control: tags -1 patch On Thu, Aug 15, 2019 at 03:35:04PM +0200, أحمد المحمودي wrote: > On Wed, Mar 27, 2019 at 07:48:14PM +, Matthias Klose wrote: > > The package fails to build in a test rebuild on at least amd64 with > > gcc-9/g++-9, but succeeds to build with gcc-8/g++-8. The > > http://gcc.gnu.org/gcc-9/porting_to.html > > > > [...] > > - > > _ZN5sc_dt13b_xor_assign_INS_10sc_bv_baseENS_10sc_lv_baseEEERT_RNS_8sc_proxyIS3_EERKNS5_IT0_EE@Base > > 2.3.3 > > +#MISSING: 2.3.3-2# > > _ZN5sc_dt13b_xor_assign_INS_10sc_bv_baseENS_10sc_lv_baseEEERT_RNS_8sc_proxyIS3_EERKNS5_IT0_EE@Base > > 2.3.3 > > [...] > ---end quoted text--- > > The wierd symbol mangling in C++ ks causing this proble, with rvery > gcc/g++ update, I tried using c++filt symbols (using c++ tag), but it > was of no use. This doesn't help, this just makes the symbols a bit more human readable. dpkg-gensymbols generates a patch file output that helps to adjust the symbols file, why not just use this with a bit of brain? > Hence, I think the best solution is to remove the symbols file for this > package. It took me about a hour to adjust the symbols file so dpkg-gensymbols is happy. It's really not that hard! The symbols file has an intention and this is to make life easier while libraries transiontions e.g. The added patch is only taking care about the RC architectures, it might possible that the kfreebsd platforms are still not fully adjusted. Regards Carsten >From 7b3a0f59d19702c8dec05ee5e8adb42cce7dcffe Mon Sep 17 00:00:00 2001 From: Carsten Schoenert Date: Sat, 17 Aug 2019 21:26:05 +0200 Subject: [PATCH] libsystemc.symbols: update after GCC update As usual with every new GCC version we have changed symbol names, updating the symbols file for new GCC 9 in the archive. --- debian/libsystemc.symbols | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/debian/libsystemc.symbols b/debian/libsystemc.symbols index 2e850c3..4db676c 100644 --- a/debian/libsystemc.symbols +++ b/debian/libsystemc.symbols @@ -92,7 +92,7 @@ libsystemc-2.3.3.so libsystemc #MINVER# _ZN5sc_dt10sc_lv_base10clean_tailEv@Base 2.3.3 _ZN5sc_dt10sc_lv_base18assign_from_stringERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 2.3.3 _ZN5sc_dt10sc_lv_base4initEiRKNS_8sc_logicE@Base 2.3.3 - (arch-bits=32)_ZN5sc_dt10sc_lv_base7set_bitEiNS_16sc_logic_value_tE@Base 2.3.3 +#MISSING: 2.3.3-2# (arch-bits=32)_ZN5sc_dt10sc_lv_base7set_bitEiNS_16sc_logic_value_tE@Base 2.3.3 _ZN5sc_dt10sc_lv_baseC1EPKc@Base 2.3.3 _ZN5sc_dt10sc_lv_baseC1EPKci@Base 2.3.3 _ZN5sc_dt10sc_lv_baseC1ERKS0_@Base 2.3.3 @@ -294,7 +294,7 @@ libsystemc-2.3.3.so libsystemc #MINVER# _ZN5sc_dt11scfx_csd2tcERNS_11scfx_stringE@Base 2.3.3 _ZN5sc_dt11scfx_stringD1Ev@Base 2.3.3 _ZN5sc_dt11scfx_stringD2Ev@Base 2.3.3 - _ZN5sc_dt11scfx_stringpLEc@Base 2.3.3 + (arch=arm64)_ZN5sc_dt11scfx_stringpLEc@Base 2.3.3 _ZN5sc_dt11scfx_tc2csdERNS_11scfx_stringEi@Base 2.3.3 _ZN5sc_dt11vec_add_on2EiPjiPKj@Base 2.3.3 _ZN5sc_dt11vec_reverseEiiPjii@Base 2.3.3 @@ -344,9 +344,9 @@ libsystemc-2.3.3.so libsystemc #MINVER# _ZN5sc_dt12sc_uint_baseaSERKNS_9sc_signedE@Base 2.3.3 _ZN5sc_dt12sub_scfx_repERKNS_8scfx_repES2_i@Base 2.3.3 _ZN5sc_dt12vec_from_strEiiPjPKcNS_9sc_numrepE@Base 2.3.3 - _ZN5sc_dt13b_and_assign_INS_10sc_bv_baseENS_10sc_lv_baseEEERT_RNS_8sc_proxyIS3_EERKNS5_IT0_EE@Base 2.3.3 + (arch=i386 arm64)_ZN5sc_dt13b_and_assign_INS_10sc_bv_baseENS_10sc_lv_baseEEERT_RNS_8sc_proxyIS3_EERKNS5_IT0_EE@Base 2.3.3 _ZN5sc_dt13b_and_assign_INS_10sc_lv_baseES1_EERT_RNS_8sc_proxyIS2_EERKNS4_IT0_EE@Base 2.3.3 - _ZN5sc_dt13b_xor_assign_INS_10sc_bv_baseENS_10sc_lv_baseEEERT_RNS_8sc_proxyIS3_EERKNS5_IT0_EE@Base 2.3.3 + (arch=i386 arm64)_ZN5sc_dt13b_xor_assign_INS_10sc_bv_baseENS_10sc_lv_baseEEERT_RNS_8sc_proxyIS3_EERKNS5_IT0_EE@Base 2.3.3 _ZN5sc_dt13b_xor_assign_INS_10sc_lv_baseES1_EERT_RNS_8sc_proxyIS2_EERKNS4_IT0_EE@Base 2.3.3 _ZN5sc_dt13sc_fxnum_fast4castEv@Base 2.3.3 _ZN5sc_dt13sc_fxnum_fast4scanERSi@Base 2.3.3 @@ -509,7 +509,7 @@ libsystemc-2.3.3.so libsystemc #MINVER# _ZN5sc_dt16vec_add_small_onEiPjj@Base 2.3.3 _ZN5sc_dt16vec_mul_small_onEiPjj@Base 2.3.3 _ZN5sc_dt16vec_rem_on_smallEiPjj@Base 2.3.3 - _ZN5sc_dt16vec_skip_and_cmpEiPKjiS1_@Base 2.3.3 + (arch=arm64)_ZN5sc_dt16vec_skip_and_cmpEiPKjiS1_@Base 2.3.3 _ZN5sc_dt16vec_sub_small_onEiPjj@Base 2.3.3 _ZN5sc_dt17add_signed_friendEiiiPKjiiiS1_@Base 2.3.3 _ZN5sc_dt17and_signed_friendEiiiPKjiiiS1_@Base 2.3.3 @@ -848,7 +848,7 @@ libsystemc-2.3.3.so libsystemc #MINVER# _ZN5sc_dt9sc_signed10concat_setExi@Base 2.3.3 _ZN5sc_dt9sc_signed10concat_setEyi@Base 2.3.3 _ZN5sc_dt9sc_signed14set_packed_repEPj@Base 2.3.3 - _ZN5sc_dt9sc_signed22convert_SM_to_2C_to_SMEv@Base 2.3.3 + (arch=arm64)_ZN5sc_dt9sc_signed22convert_SM_to_2C_to_SMEv@Base 2.3.3 _ZN5sc_dt9sc_signed3setEi@Base 2.3.3 _ZN5sc_dt9sc_signed4sca
Bug#933643: librust-cbindgen-dev: unsatisfied dependency librust-toml-0.4+default-dev on librust-cbindgen-dev
Package: librust-cbindgen-dev Severity: serious Dear Maintainers, I got some time and tried up to package the latest beta version of Thunderbird 68.0 aka 68.0b5. Unfortunately I'm unable to start any build as a dependency on the package librust-toml-0.4+default-dev can't be solved. > 0 packages upgraded, 452 newly installed, 0 to remove and 0 not upgraded. > Need to get 320 MB of archives. After unpacking 1715 MB will be used. > The following packages have unmet dependencies: > librust-cbindgen-dev : Depends: librust-toml-0.4+default-dev which is a > virtual package and is not provided by any available package > > Unable to resolve dependencies! Giving up... I guess the required package is librust-toml-dev in the end, looking more into the virtual package librust-cbindgen-dev it seems to me there are more such insolvable package dependencies. https://packages.debian.org/unstable/librust-cbindgen-dev Regards Carsten -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/6 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages librust-cbindgen-dev depends on: pn librust-clap-2+default-dev pn librust-log-0.4+default-dev pn librust-proc-macro2-0.4+default-dev pn librust-quote-0.6+default-dev pn librust-serde-1+default-dev pn librust-serde-1+derive-dev pn librust-serde-derive-1+default-dev pn librust-serde-json-1+default-dev pn librust-syn-0.15+clone-impls-dev pn librust-syn-0.15+extra-traits-dev pn librust-syn-0.15+full-dev pn librust-syn-0.15+parsing-dev pn librust-syn-0.15+printing-dev pn librust-tempfile-3+default-dev pn librust-toml-0.4+default-dev librust-cbindgen-dev recommends no packages. librust-cbindgen-dev suggests no packages.
Bug#932592: [Pkg-giraffe-maintainers] Bug#932592: kopano-webapp: autopkgtest regression
Hello Jelle, it would be great if you on upstream could have a look at this! Looking at the history in ci.d.n it's visible this problem is alive since the Chromium version 76.0.3809.62-1, the previous version works fine. Maybe some kid of lovely API change ... https://ci.debian.net/packages/k/kopano-webapp/testing/amd64/ Am 21.07.19 um 02:27 schrieb Michael Gilbert: > package: src:kopano-webapp > severity: serious > version: 3.5.6+dfsg1-1 > > kopano-webapp currently has a failing autopkgtest [0]. This currently > blocks migration of chromium since it is listed as an autopkgtest > dependency for this package. > > == > ERROR: test_login (test_webapp.TestWebApp) > -- > Traceback (most recent call last): > File > "/tmp/autopkgtest-lxc.720_qx5v/downtmp/build.vfl/src/debian/tests/test_webapp.py", > line 70, in test_login > elem.click() > File > "/usr/lib/python3/dist-packages/selenium/webdriver/remote/webelement.py", > line 80, in click > self._execute(Command.CLICK_ELEMENT) > File > "/usr/lib/python3/dist-packages/selenium/webdriver/remote/webelement.py", > line 633, in _execute > return self._parent.execute(command, params) > File > "/usr/lib/python3/dist-packages/selenium/webdriver/remote/webdriver.py", > line 321, in execute > self.error_handler.check_response(response) > File > "/usr/lib/python3/dist-packages/selenium/webdriver/remote/errorhandler.py", > line 242, in check_response > raise exception_class(message, screen, stacktrace) > selenium.common.exceptions.JavascriptException: Message: javascript > error: circular reference > (Session info: headless chrome=76.0.3809.62) > > It looks like a selenium issue, but I haven't debugged further than > reading this log. If it has to do with chromium-driver, please create > a chromium bug with more information. > > Best wishes, > Mike > > [0] https://ci.debian.net/packages/k/kopano-webapp/testing/amd64/ -- Regards Carsten Schoenert
Bug#929588: usat: source tarballs are missing the source of the configure script
Hi, please use 'Reply All' next time so your answer will also get into the bug tracking system. Thanks! Am 31.05.19 um 17:50 schrieb badd...@gmail.com: > Ah I see. > > Well, I am about to put out a new release with a lot of updates. In > fact, the current release has some debian issues that I am working > on. I will ensure that it is fixed in that release. Thanks! Once it's released the package maintainers can keep it up then. > If I have some time, I will go back to the current release and add > the configure.in. I am not sure where it got lost to... I guess it's mostly about hand crafted (Make)files, otherwise at least one part -f the -local targets should get a bit of a reworking. Please do a reply again about some ready to use updates to this email so the information about a new or updated archive will be announced into the Debian issue tracker. -- Regards Carsten Schoenert
Bug#929588: usat: source tarballs are missing the source of the configure script
Hi, thanks for your quick answer! Am 31.05.19 um 12:26 schrieb badd...@gmail.com: > I am sending this from my other account, as your email service is blocking > my main email telling me I have been blacklisted. > > Those packages are astronomically out of date. I had problems with > Sourceforge when they changed hands, and still have password issues. > Use the official site:> > http://dimlight.org/lsat/ > > 0.9.8.5 is the latest version. > > Thanks. O.k. that's an important information for the package maintainers. I've looked quickly into the zipped file for the version you have mentioned, the issue is still here also existing. I can't find a configure.in script nor some similar autogen.sh file. The configure script has some content that it was created from a configure.in file. > #! /bin/sh > > # Guess values for system-dependent variables and create Makefiles. > # Generated automatically using autoconf version 2.13 > # Copyright (C) 1992, 93, 94, 95, 96 Free Software Foundation, Inc. > # > # This configure script is free software; the Free Software Foundation > # gives unlimited permission to copy, distribute and modify it. > > # Defaults: > ac_help= > ac_default_prefix=/usr/local > # Any additions from configure.in: Please add the configure.in file to the next release or even better update the existing archives. > On 2019-05-30 10:58, Carsten Schoenert wrote: > > Hi, > > previous and the most recent release of the usat tarballs is missing the > source for the configure script. > > http://usat.sourceforge.net/code/lsat-0.9.8.2.zip > > For Debian this makes the package [1 <https://tracker.debian.org/pkg/lsat>] > non-free due the regulation of the > Debian Free Software Guidelines [2 > <https://www.debian.org/social_contract.en.html#guidelines>]. > It also makes it impossible to build the package on platforms that are > not supported by the provided configure script. > > Could you please include the source for the generated configure script? > > [1] https://tracker.debian.org/pkg/lsat > [2] https://www.debian.org/social_contract.en.html#guidelines > -- Regards Carsten Schoenert
Bug#929588: usat: source tarballs are missing the source of the configure script
Hi, previous and the most recent release of the usat tarballs is missing the source for the configure script. http://usat.sourceforge.net/code/lsat-0.9.8.2.zip For Debian this makes the package [1] non-free due the regulation of the Debian Free Software Guidelines [2]. It also makes it impossible to build the package on platforms that are not supported by the provided configure script. Could you please include the source for the generated configure script? [1] https://tracker.debian.org/pkg/lsat [2] https://www.debian.org/social_contract.en.html#guidelines -- Regards Carsten Schoenert
Bug#929588: lsat missing source for configure
Control: tags -1 upstream On Sun, May 26, 2019 at 08:16:19PM +0200, Helmut Grohne wrote: > The lsat source package is missing the source code for the file > ./configure. That file identifies itself as being generated using > autoconf. The source tarball does not contain any corresponding source. > This is a DFSG #2 violation and thus justifies severity serious. This is not only happen within the version in the Debian archive, this is also a recent issue in the most recent version 0.9.8.2 in the upstream tarball. Seems upstream should rework their process to create the tarball. http://usat.sourceforge.net/code/lsat-0.9.8.2.zip Regards Carsten
Bug#928178: apparmor: thunderbird fails to start, saying that is already running
Control: severity -1 important Control: usertags -1 tb-apparmor Control: user thunderb...@packages.debian.org Hello Piviul, downgrading severity as AppArmor isn't officially supported and activated for the Thunderbird package. Am 29.04.19 um 15:21 schrieb Piviul: > Package: thunderbird > Version: 1:60.6.1-1~deb9u1 > Severity: grave > Tags: d-i > Justification: renders package unusable > > Dear Maintainer, > after recently updates thunderbird fails to start with the message: > "Thunderbird is already running, but is not responding. To open a new window, > you must first close the existing Thunderbird process, or restart your > system." > > In /var/log/syslog I can find: > Apr 29 12:06:40 psala-lx2 kernel: [ 5131.606429] audit: type=1400 > audit(1556532400.993:264): apparmor="DENIED" operation="file_lock" > profile="thunderbird" > name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock" The path to your profile looks unusual. In the past we had other reports that have show that AA isn't happy if the Thunderbird profile can't be found in the typical folder. > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=tb-apparmor;users=thunderb...@packages.debian.org Maybe you will find similar issues here. > If I disable apparmor for thunderbird (aa-disable > /etc/apparmor.d/usr.bin.thunderbird) the problem seems to be solved. I added Vincas to the recipients who is working in the AppArmor team, maybe he has some useful ideas to encircle the problem. Seems to be a AA issue or AA TB profile issue in the end. -- Regards Carsten Schoenert
Bug#924047: FTBFS: package don't build successful after new GCC version
Am 12.03.19 um 04:57 schrieb أحمد المحمودي: > Yes, but this needs to be done for every gcc update ! Mostly, yes. I remember I've have written this information early in one of our starting conversation about systemc packaging. > I tried unmangling the c++ symbols and using c++ tag in symbols file > (see c++sym branch), but that failed too. This doesn't help much in the end as the symbols are still the same in the end. As long upstream isn't doing a versioning there is the mess that every symbols needs to be listed. A common problem unfortunately. :/ > Anyways, I updated std ver to 4.3.0, amd pushed 2.3.3-2, here's the > changelog entry: > > systemc (2.3.3-2) unstable; urgency=medium > > [ أحمد المحمودي (Ahmed El-Mahmoudy) ] > * [625f662] Revert "uscan: update watch file to catch new versions" > This reverts commit 83ab9e15a4138b76fadd9d6ada5d0893a12f0ae8. > * [3886a0b] Bumped standards version to 4.3.0, no changes needed > > [ Carsten Schoenert ] > * [d3c60cd] libsystemc.symbols: update after GCC update Fine, will do an upload later the day. -- Regards Carsten Schoenert
Bug#924047: FTBFS: package don't build successful after new GCC version
Am 10.03.19 um 05:39 schrieb أحمد المحمودي: > I'd rather remove the symbols file. That's the last option in my eyes as it's a step backwards and is absolutely not needed as I fixed the problem already. The main problem with the symbols is that the symbols are simply not versioned and that's an upstream problem. -- Regards Carsten Schoenert
Bug#924047: FTBFS: package don't build successful after new GCC version
Package: src:systemc Version: 2.3.3-1 Severity: grave Hello Ahmed, the systemc package is currently failing to build from source basically related due a newer GCC version and changed symbols introduced by the newer GCC. I've fixed the reason of the FTBFS by modifying and adopting the symbols file so the package is building again on all RC platforms. I've pushed the adopted symbols file to Salsa after I've tested the builds. If you can also have a look on a update of Standards-Version to 4.3.0 and prepare a new changelog entry I can offer a sponsored upload. I see no problem with a later unblock request so the updated package can go into the Buster release. Regards Carsten -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/6 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#923713: Regression: kicad not available for ppc64el after Stretch
Control: severity -1 wishlist Hi, Am 04.03.19 um 10:17 schrieb tpear...@raptorengineering.com: Package: kicad Version: 5.0.2+dfsg1-1 Severity: grave the severity for this report can't be grave or similar to other RC severities. I tagged this report now as wishlist. While evaluating a potential upgrade of our engineering systems from Stretch to Buster, we noticed that kicad is no longer available for ppc64el. This is a deal breaker for us as kicad is a critical part of the engineering workflow. The lack of ppc64el as supported platform is owed by the decisions of upstream maintainers, it wasn't made by me or any other person involved in packaging KiCad. So in fact the current stable version of KiCad (5.0.2) isn't buildable for ppc64el. I also noticed that the latest versions of kicad include the required assembler routines (the lack of which presumably caused the build to be dropped). At minimum, a backport of these patches and reenabling of the ppc64el builds should be attempted for testing. At one day a backported version for ppc64* and mips* will be available. For now there is not much I can do. We are just a few day away from the full freeze and it's simply to late to do anything now about the newly re-added supported platforms for KiCad as package would need to go through NEW first. And right now 5.1.0 isn't released. If the final version 5.1.0 will get released within the next days I plan to upload this version to unstable and ask also the Release Team to accept a migration to testing once the required delay is over, but without supporting the new added platforms. If I got some time I can provide a extra builded binary version for ppc64el created on a porterbox. -- Regards Carsten Schoenert
Bug#922261: python-sunlight: FTBFS (Could not import extension sphinx.ext.pngmath)
Hi, On Wed, Feb 13, 2019 at 08:16:36PM +, Santiago Vila wrote: ... > make[2]: Entering directory '/<>/docs' > sphinx-build -b html -d build/doctrees source build/html > Running Sphinx v1.8.3 > > Extension error: > Could not import extension sphinx.ext.pngmath (exception: No module named > pngmath) > make[2]: *** [Makefile:40: html] Error 2 > make[2]: Leaving directory '/<>/docs' > make[1]: *** [debian/rules:21: override_dh_auto_build] Error 2 > make[1]: Leaving directory '/<>' > make: *** [debian/rules:13: build-indep] Error 2 > dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit > status 2 > the fix is rather trivial. The file docs/source/conf.py neededs to be modified as sphinx.ext.pngmath is now been dropped in favour of sphinx.ext.imgmath. Please see attached patch for applying on top the packagig branch. Regards Carsten >From 376ce69f5f4748fd077b13e84243078f86a172b4 Mon Sep 17 00:00:00 2001 From: Carsten Schoenert Date: Sat, 23 Feb 2019 20:08:41 +0100 Subject: [PATCH] adding a patch queue to fix FTBFS added patch: 0001-Fix-FTBFS-with-sphinx-1.8.patch --- .../0001-Fix-FTBFS-with-sphinx-1.8.patch | 23 +++ debian/patches/series | 1 + 2 files changed, 24 insertions(+) create mode 100644 debian/patches/0001-Fix-FTBFS-with-sphinx-1.8.patch create mode 100644 debian/patches/series diff --git a/debian/patches/0001-Fix-FTBFS-with-sphinx-1.8.patch b/debian/patches/0001-Fix-FTBFS-with-sphinx-1.8.patch new file mode 100644 index 000..4c3787e --- /dev/null +++ b/debian/patches/0001-Fix-FTBFS-with-sphinx-1.8.patch @@ -0,0 +1,23 @@ +From: Carsten Schoenert +Date: Sat, 23 Feb 2019 19:50:52 +0100 +Subject: Fix-FTBFS-with-sphinx-1.8 + +sphinx.ext.pngmath has been removed in favor of sphinx.ext.imgmath. +replace the former with the latter in docs/source/conf.py. +--- + docs/source/conf.py | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/docs/source/conf.py b/docs/source/conf.py +index 8ec8ee0..c0c7dd5 100644 +--- a/docs/source/conf.py b/docs/source/conf.py +@@ -17,7 +17,7 @@ version = sunlight.__version__ + # Add any Sphinx extension module names here, as strings. They can be extensions + # coming with Sphinx (named 'sphinx.ext.*') or your custom ones. + extensions = ['sphinx.ext.autodoc', 'sphinx.ext.intersphinx', +-'sphinx.ext.todo', 'sphinx.ext.coverage', 'sphinx.ext.pngmath', ++'sphinx.ext.todo', 'sphinx.ext.coverage', 'sphinx.ext.imgmath', + 'sphinx.ext.ifconfig', 'sphinx.ext.viewcode'] + + # Add any paths that contain templates here, relative to this directory. diff --git a/debian/patches/series b/debian/patches/series new file mode 100644 index 000..4ef579c --- /dev/null +++ b/debian/patches/series @@ -0,0 +1 @@ +0001-Fix-FTBFS-with-sphinx-1.8.patch -- 2.20.1
Bug#918164: Broken with Thunderbird 60
Hello Matthias, On Thu, Jan 03, 2019 at 11:21:19PM +0100, Moritz Muehlenhoff wrote: > The plugin is broken with Thunderbird 60 in stretch and sid, after > installation > it's disabled and only prints "Timeline is incompatible with Thunderbird > 60.4". > > TB 60 was uploaded to stretch over two months ago (and three months ago to > sid), > given that noone filed a bug so far, it makes me wonder whether this package > is > used at all... currently the package xul-ext-timeline is useless as it isn't usable in any release of Debian any more. Upstream seems to have given up the development not only this extension for Thunderbird. https://addons.thunderbird.net/en-us/thunderbird/user/teester/ The last supported Thunderbird version is mainly on all of the provided extension staying at 31.*. We should remove this package completely from the Debian archives. Regards Carsten
Bug#921258: thunderbird FTBFS on 32bit: memory exhausted
Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1526744
Control: severity -1 important
Control: retitle -1 build fails on mips{,el}
Hello Adrian,
Am 03.02.19 um 18:04 schrieb Adrian Bunk:
> ...
> 49:37.16 /usr/bin/ld: libxul.so: final close failed: memory exhausted
> 49:37.16 collect2: error: ld returned 1 exit status
> 49:37.16 make[6]: *** [/<>/config/rules.mk:709: libxul.so] Error
> 1
>
> Seems some change in -2 had the opposite effect than desired.
meeh, the changes I've picked from Mike wasn't usable directly and
indeed I should have tested them more carefully at least by a testing
build with a i386 chroot. But this did not happen due some time constrains.
Unfortunately the changes made by upstream in this ESR version are much
more than usual and a lot of parts on internal build setup have been
changed too.
Seems we will have to "fight" more depending on physical architecture
borders on the 32bit platforms in the future for FF and TB.
The current state on mips and mipsel is a bit better than before, the
build process is succeeding a bit more and isn't breaking right in the
middle.
I opened up a bug report 1526744 on bugzilla.m.o about the outstanding
issue on building Thunderbird on mips and mipsel and decrease the
severity of this issue to important as all RC platforms are building
successful now (again) except the two mips 32bit architectures.
--
Regards
Carsten Schoenert
Bug#862199: changed severity to serious, why?
Hello Stew, Am 17.12.18 um 15:00 schrieb Debian Bug Tracking System: > Processing commands for cont...@bugs.debian.org: > >> severity 862199 serious > Bug #862199 [thunderbird] thunderbird: Thunderbird crashes when removing > massively mails > Severity set to 'serious' from 'normal' could you please elaborate why you think this issue needs to have a severity of serious? Also it would be better get in contact with the package maintainer before doing such things. The meanings of the severity are explained here: https://www.debian.org/Bugs/Developer#severities I see absolutely no need to adjust the severity as no data loss is given, no Debian policy is violated nor the is thunderbird doing any damage on the installed system. Yes, a crash isn't nice at all, but here on this bug report this isn't not enough to increase the severity to anything RC. -- Regards Carsten Schoenert
Bug#915236: ngspice FTBFS: dh_install: Cannot find "doc/*build_ngspice*.png"
Control: severity -1 important Control: retile -1 ngspice: FTBR: dh_install: Cannot find "doc/*build_ngspice*.png Hello Adrian, On Sun, Dec 02, 2018 at 01:05:56AM +0200, Adrian Bunk wrote: > Source: ngspice > Version: 29-1 > Severity: serious > Tags: ftbfs > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ngspice.html > > ... > dh_install > dh_install: Cannot find (any matches for) "doc/*build_ngspice*.png" (tried in > ., debian/tmp) > > dh_install: ngspice-doc missing files: doc/*build_ngspice*.png > dh_install: missing files, aborting > make[1]: *** [debian/rules:124: override_dh_install-indep] Error 25 as much I like your work in Debian I disagree on the used severity for this report. ngspice isn't failing on any buildd, *all* platforms Debian is currently supporting have build successfully the ngspice packages. So I really don't see a FTBFS! I agree that ngspice isn't building reproducible for some reason. Policy is saying that a package SHOULD be buildable reproducible but not it MUST, so a report against a package due not buildable reproducible can't be RC. Because of this I've downgraded the severity to important. Without some debugging why the second build of ngspice in the reproducible build environment is failing it's unlikely to find the reason for the failing build. I don't have any reproducible build environment running, I wont find out something useful. Instead I will try to make the ngspice manual source be better supported by the autotool environment. This will need some talking to upstream first. Regards Carsten
Bug#907396: kopano-server: Tools all fail with: MAPI error 80040111 (MAPI_E_LOGON_FAILED)
Hello David, Am 02.12.18 um 21:51 schrieb David Gabriel: >> No, this is not planned. > > Happy to hear that - I was referring to the statement on > https://tracker.debian.org/pkg/kopanocore (...removal on Dec 8...) > must have mis-interpreted that. these removals are happen automatically to ensure the packages from Testing are mostly useful. It also helps, like now, to reduce potential broken packages go into the next stable release. So yes, if the maintainers don't act the packages will not go into Buster. >> Please note the packages here might get changed or get dropped later. If >> you could do some testing we would like to get some feedback if possible. > > I understand - that's a lot of changes, thank you all for your hard work! I'll > gladly test the provided packages and report back. However since I'm traveling > abroad at the moment (and I'll have to revert my kopano install for which I > used > the .deb packages provided by download.kopano.io for now) this might take me > about 2 weeks. Oh, this sounds like a install from scratch (except the import of your existing database at some point). Good possibility to see then if all is running as you might expect. For sure there is room for improvements in Readme's or package descriptions e.g. Please make notes where you have figured out some problems or issues. > Whom/were should I report back? This bug is probably not the > right place to continue to talk about packaging issues. Yes, this bug report isn't about the original issue which is fixed a while ago as Mark already mentioned. There are two mailing list were we discuss problems, plannings or packaging things. The amount of emails is rather slow, so you wont be flooded by a lot of traffic from here. List for talking about the what things and how them to do, the list we typically do most of discussions https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-giraffe-discuss Talking about packaging related things, also the list for emails from the archive (used address for the Maintainer field) https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-giraffe-maintainers And there is also a wiki site in the Debian Wiki with a lot of partial information. It's not that up2date, it was the place were we have written down the various status of the interaction packages. https://wiki.debian.org/Groupware/Kopano > Br and thanks again for the comprehensive update, You are welcome! -- Regards Carsten Schoenert
Bug#907396: kopano-server: Tools all fail with: MAPI error 80040111 (MAPI_E_LOGON_FAILED)
Hello Mark, hello David, Am 02.12.18 um 11:35 schrieb Mark Dufour: > Hi David, > >> any update on this? a lot of updates did happen. https://qa.debian.org/cgi-bin/vcswatch?package=kopanocore >> kopano-core and its deps are scheduled for removal in testing in a >> couple of days, and the package has not been updated ever since >> 8.6.5. has kopano been abandoned for debian buster? No, this is not planned. But kopanocore isn't one of a more simple package. Also upstream is moving fast (yeah!) and for mainly basically just two persons on the packaging side it's not always easy to follow all the upstream changes nor did we have plenty of times to track the changes closely. > There has actually been quite some effort going into preparing new > 8.7 packages, and we are hoping to upload new packages very soon.. > This bug was fixed somewhere in 8.6, so should also be fixed with the > new packages. The current changes that happen in the past week are more than the usual updates between package versions. It's not that far away from a complete re-create of the packaging from scratch due the massive changes that had taken place. The current preparations for the next upload are holding a drop of the Python2 based packages and will introduce Python3 based packages that have required some changes to the source too. This has happen in cooperation with upstream. Also PHP has changed in unstable to version 7.2 which will require changes to the webapp later too. So it's all a bit complex. David, if you like to test the current packages I've uploaded a snapshot version to https://people.debian.org/~tijuca/kopanocore/ Please note the packages here might get changed or get dropped later. If you could do some testing we would like to get some feedback if possible. -- Regards Carsten Schoenert
Bug#915236: ngspice FTBFS: dh_install: Cannot find "doc/*build_ngspice*.png"
Hello Juhani, Am 02.12.18 um 10:45 schrieb Juhani Numminen: > I can't reproduce the failure on my pbuilder setup, but the relevant > part of debian/rules look suspicious because the semicolon ; rather > than && is used when chaining shell commands. With semicolon, a > failure to e.g. change directory can go unnoticed and lyx would > be run in an unexpected dir. Not sure if that's the case here. if the folder doc/ wouldn't exist make would also fail on this step, so that's not the root for the bug report Adrian has created. For sure something isn't working as expected but I don't see why is working with sbuild and pbuilder and also on the first run of the reproducible setup but not on the second. Since version 29 (or was it also in 28) the documentation comes with the files configure.ac and Makefile.am which are the base for configuring a project by the autotools. Instead of doing some manual lyx calls to create the documentation we should fix the current poor implementation of the autotools files. -- Regards Carsten Schoenert
Bug#913645: Oldstable also affected
Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1505038 Hello Bastian, Am 20.11.18 um 17:44 schrieb Bastian Neuburger: > Hi, > >> I have however not yet tested what happens if you start thunderbird >> aftter the upgrade and close it right away (i.e. not trying to sign >> anything but also not entering the master password). I will try to test >> this later but now I need a working mail client. >> > > I also tested this variant now: > > 1. Have berkeley DB based profile that works fine with thunderbird 52 in > Jessie > 2. Upgrade thunderbird > 3. Start thunderbird > 4. Close it without doing anything (I am not prompted for the master > password) > 5. Start thunderbird again > > Expected results: > Either key3.db is still there or I am getting prompted for a master > password during step 4. > > Actual results: > Everything under "Your certificates" and "People" in the Certificate > Manager gone, all saved passwords gone. > > So the problem we encountered did not only wipe private keys, but also > certificates of other people I already corresponded with AND stored > passwords. > > How should reporting with upstream be handled? Should I take care of it > myself or would you like to forward it? I haven't forwarded that all into a new upstream bug report, but I was able to talk about that issue with upstream. Initially upstream (in that case the NSS/Firefox team) has decided about 6 years ago to stop using the old database option [1] and use the newer NSS implementations for storing stuff within a database. Your are not the only person who is experience such problems. There is the report 1505038 [2] which is from a user with the same problems. The issue has some workaround mentioned in comment #25 which should be "solve" your current problem, could you please test this suggestion? [1] https://bugzilla.mozilla.org/show_bug.cgi?id=783994 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1505038 -- Regards Carsten Schoenert
Bug#914175: lightning is not installable after binNMUs
Control: tags -1 pending
Hello Adrian,
Am 20.11.18 um 08:52 schrieb Adrian Bunk:
> Package: lightning
> Version: 1:60.3.0-1
> Severity: serious
>
> thunderbird : Breaks: lightning (< 1:60.3.0-1+b1) but 1:60.3.0-1 is to be
> installed
>
> lightning is binary-all, ${source:Version} should be used
> for Breaks and Recommends.
indeed, good catch!
Thanks for raising this problem! Will get fixed by the next upload.
--
Regards
Carsten Schoenert
Bug#913645: Oldstable also affected
Hello Bastian, Am 20.11.18 um 17:44 schrieb Bastian Neuburger: > Hi, > >> I have however not yet tested what happens if you start thunderbird >> aftter the upgrade and close it right away (i.e. not trying to sign >> anything but also not entering the master password). I will try to test >> this later but now I need a working mail client. >> > > I also tested this variant now: > > 1. Have berkeley DB based profile that works fine with thunderbird 52 in > Jessie > 2. Upgrade thunderbird > 3. Start thunderbird > 4. Close it without doing anything (I am not prompted for the master > password) > 5. Start thunderbird again > > Expected results: > Either key3.db is still there or I am getting prompted for a master > password during step 4. > > Actual results: > Everything under "Your certificates" and "People" in the Certificate > Manager gone, all saved passwords gone. > > So the problem we encountered did not only wipe private keys, but also > certificates of other people I already corresponded with AND stored > passwords. thanks for testing this, I'm unable to this as I don't use any of these features. > How should reporting with upstream be handled? Should I take care of it > myself or would you like to forward it? I'd prefer if you could do the interaction with upstream as I only would act as a man in the middle. And I haven't much time to work on Thunderbird now. Please give a note back about the upstream bug number so we can add a forwarding to this issue. Thanks! -- Regards Carsten Schoenert
Bug#909000: Thunderbird 60 cannot STILL be at stretch normal repository
Hi, Am 16.10.18 um 11:00 schrieb Narcis Garcia: > An obvious vulnerability for user is to not be able to use Enigmail for > encryption. yes, the problem here is Enigmail, not Thunderbird! But I don't see that this as a vulnerability per se from a security perspective. And you still can install the Mozilla AddOns manually into FF and TB. It's a loosing of comfort and easy usage of the system provided packages, but not more for the typical single user cases on a machine or laptop. The AddOns for FF and TB will always be special as these software is in a heavy flow and development. Packaging such software is by this also always a walk on the edge because you will need to follow the upstream development really closely. And happily dkg is taking this challenge really seriously! > Repository inconsistency is a major (and more clear) vulnerability. I see no inconsistency, at maximum we have some lag behind upstream versions. How will you do automatic encryption *without* the enigmail package? And is this a security problem? And being not able to send automated encrypted email is not a vulnerability as you still can use gpg on the command line and encrypt your content obviously with less comfort, and it's your decision. And again, you can still install Enigmail from upstream. So hey, that's life. For all other things we have Conflicts and Breaks in the package management system. Debian is made by people in their free time, so it will happen again and again that some parts are not completely on the edge. And the decisions what will happen in Debian is made by their participants, I invite you to become a member so you can help actively to make Debian better for your needs. > Next versions of Mozilla software should not be at "main" repository, > same as with HPLIP occurs. The main criteria for main is DFSG clean software not if a software are made by a specific vendor or group. The hplib package is in main because it fulfills the DFSG requirements. I suggest you take a look into the DFSG to understand better how Debian is working. -- Regards Carsten Schoenert
Bug#909313: [xul-ext-sogo-connector] Not compatible with thunderbird 60 (New version exists)
Hi, Am 27.09.18 um 21:52 schrieb Michael Meier: >> What did you mean by 'nightly build'? I don't see any new commit after >> the tagged version 31.0.6 on GitHub. >> >> https://github.com/inverse-inc/sogo-connector.tb31 >> > The commits are here: > > https://github.com/inverse-inc/sogo-connector > > Nightly Build: > > http://packages.inverse.ca/SOGo/thunderbird/nightly/ oh, yes. Looks promising. Except once more the release wasn't tagged by SOGo. I will look into it the next days. -- Regards Carsten Schoenert
Bug#909313: [xul-ext-sogo-connector] Not compatible with thunderbird 60 (New version exists)
Am 21.09.18 um 17:36 schrieb Michael Meier: >> Before doing all this we need to be sure that the new version of >> sogo-connector is really working with TB >= 60.x. >> > I've just tested out the nightly build, and it seems to be working. I've > created some events, tried to sync them in both ways, delete them. > > So at least basic functionality seems to be working. The rest time will > show... > > The new version is not compatibly to thunderbird version <60. I did some testing for the released version 31.0.6 and I don't get this version installed into my local profile nor if I've build this version as a deb package. What did you mean by 'nightly build'? I don't see any new commit after the tagged version 31.0.6 on GitHub. https://github.com/inverse-inc/sogo-connector.tb31 -- Regards Carsten Schoenert
Bug#909464: thunderbird: Thunderbird crash : Fontconfig error: failed reading config file
Hello, Am 24.09.18 um 11:11 schrieb Frederic MASSOT: > Dear Maintainer, > > After upgrading Thunderbird from version 1:52.9.1-1 to version > 1:60.0-3~deb9u1, Thunderbird crash at startup with error message: > > $ thunderbird --verbose > INFO -> [[ ... using verbose mode ... ]] > DEBUG -> Found folder /home/toto/.icedove, found a symlink > /home/toto/.thunderbird pointing to /home/toto/.icedove > DEBUG -> call '/usr/lib/thunderbird/thunderbird ' > Fontconfig error: failed reading config file > alloc factor 0,90 0,90 > alloc factor 0,90 0,90 > ExceptionHandler::GenerateDump cloned child 4962 > ExceptionHandler::SendContinueSignalToChild sent continue signal to child > ExceptionHandler::WaitForContinueSignal waiting for continue signal... you have seen #909039 and have checked your bug is a different behavior? I don't think the message about some Fontconfig error is related to this crash (we never have seen this before). You would need to wrap the start of Thunderbird within a strace call, or run this all through the debugger. You also have installed AppArmor, the profile for Thunderbird is disabled? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909039 -- Regards Carsten Schoenert
