qt6-sensors_6.2.1-1_amd64.changes is NEW
binary:libqt6sensors6 is NEW. binary:libqt6sensors6-dev is NEW. binary:libqt6sensorsquick6 is NEW. binary:qml6-module-qtsensors is NEW. binary:libqt6sensors6-dev is NEW. binary:libqt6sensors6 is NEW. binary:libqt6sensorsquick6 is NEW. binary:qml6-module-qtsensors is NEW. source:qt6-sensors is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will receive an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html or https://ftp-master.debian.org/backports-new.html for *-backports
Processing of qt6-sensors_6.2.1-1_amd64.changes
qt6-sensors_6.2.1-1_amd64.changes uploaded successfully to localhost along with the files: qt6-sensors_6.2.1-1.dsc qt6-sensors_6.2.1.orig.tar.xz qt6-sensors_6.2.1-1.debian.tar.xz libqt6sensors6-dbgsym_6.2.1-1_amd64.deb libqt6sensors6-dev_6.2.1-1_amd64.deb libqt6sensors6_6.2.1-1_amd64.deb libqt6sensorsquick6-dbgsym_6.2.1-1_amd64.deb libqt6sensorsquick6_6.2.1-1_amd64.deb qml6-module-qtsensors-dbgsym_6.2.1-1_amd64.deb qml6-module-qtsensors_6.2.1-1_amd64.deb qt6-sensors_6.2.1-1_amd64.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#996614: Removed package(s) from unstable
We believe that the bug you reported is now fixed; the following package(s) have been removed from unstable: kf5-kdepim-apps-libs | 4:20.08.3-1 | source kf5-kdepim-apps-libs-data | 4:20.08.3-1 | all libkf5kaddressbookgrantlee-dev | 4:20.08.3-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x libkf5kaddressbookgrantlee5 | 4:20.08.3-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x libkf5kaddressbookimportexport-dev | 4:20.08.3-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x libkf5kaddressbookimportexport5 | 4:20.08.3-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x --- Reason --- ROM; dropped source from upstream -- Note that the package(s) have simply been removed from the tag database and may (or may not) still be in the pool; this is not a bug. The package(s) will be physically removed automatically when no suite references them (and in the case of source, when no binary references it). Please also remember that the changes have been done on the master archive and will not propagate to any mirrors until the next dinstall run at the earliest. Packages are usually not removed from testing by hand. Testing tracks unstable and will automatically remove packages which were removed from unstable when removing them from testing causes no dependency problems. The release team can force a removal from testing if it is really needed, please contact them if this should be the case. We try to close bugs which have been reported against this package automatically. But please check all old bugs, if they were closed correctly or should have been re-assigned to another package. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 996...@bugs.debian.org. The full log for this bug can be viewed at https://bugs.debian.org/996614 This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org. Debian distribution maintenance software pp. Scott Kitterman (the ftpmaster behind the curtain)
Bug#996610: Removed package(s) from experimental
We believe that the bug you reported is now fixed; the following package(s) have been removed from experimental: cantor | 4:21.04.0-1 | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x cantor-backend-julia | 4:21.04.0-1 | amd64 cantor-backend-kalgebra | 4:21.04.0-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x cantor-backend-lua | 4:21.04.0-1 | amd64, i386 cantor-backend-maxima | 4:21.04.0-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x cantor-backend-octave | 4:21.04.0-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x cantor-backend-python3 | 4:21.04.0-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x cantor-backend-qalculate | 4:21.04.0-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x cantor-backend-r | 4:21.04.0-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x cantor-backend-sage | 4:21.04.0-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x cantor-backend-scilab | 4:21.04.0-1 | amd64, arm64, ppc64el, s390x libcantor-dev | 4:21.04.0-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x libcantorlibs28 | 4:21.04.0-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x --- Reason --- ROM; NVIU -- Note that the package(s) have simply been removed from the tag database and may (or may not) still be in the pool; this is not a bug. The package(s) will be physically removed automatically when no suite references them (and in the case of source, when no binary references it). Please also remember that the changes have been done on the master archive and will not propagate to any mirrors until the next dinstall run at the earliest. Packages are usually not removed from testing by hand. Testing tracks unstable and will automatically remove packages which were removed from unstable when removing them from testing causes no dependency problems. The release team can force a removal from testing if it is really needed, please contact them if this should be the case. Bugs which have been reported against this package are not automatically removed from the Bug Tracking System. Please check all open bugs and close them or re-assign them to another package if the removed package was superseded by another one. The version of this package that was in Debian prior to this removal can still be found using http://snapshot.debian.org/. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 996...@bugs.debian.org. The full log for this bug can be viewed at https://bugs.debian.org/996610 This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org. Debian distribution maintenance software pp. Scott Kitterman (the ftpmaster behind the curtain)
Bug#999906: After upgrade to Debian Bullseye, I am not able to burn DVDs.
Hi, > I am not such a purist, so I really appreciate the comfort of a desktop like > KDE or LXDE in this case. It's not so much about purism in my personal case, but rather about the unwillingness to repeatedly learn how to do the same things in frequently (*) changing ways. (*) Once every ten years is too much for my ageing brain. > So is there anything I can do to help? Not before somebody shows up and asks for tests or experiments. I don't see suspicious upstream commits at https://github.com/KDE/k3b/commits/master and multiple pages until version 18.08.1 which is in Debian 10. In Debian 11 the K3B version is 20.12.2. The Debian 11 changelog https://tracker.debian.org/media/packages/k/k3b/changelog-20.12.2-1 gives no hint that the Debian maintainers changed something related to burn speed or burning in general. The patches in https://sources.debian.org/src/k3b/20.12.2-1/debian/patches/ don't look suspicious either. So i am out of ideas about how to find the trigger for your problems in Debian 11. > PS: I am on vacation till December 14th. Stay safe. Best in a plague-free hut in a remote mountain valley ... Have a nice day :) Thomas
Bug#999906: AW: After upgrade to Debian Bullseye, I am not able to burn DVDs.
Hey Thomas,
yes. At the moment, using xorrecord or xfburn, I am able to do the job.
Thanks a lot for your advice.
I am not such a purist, so I really appreciate the comfort of a desktop like KDE
or LXDE in this case. But I see that there is a huge overhead and with this also
the additional source of errors. But I have great respect for guys like you,
doing it
the straight way. :-)
So is there anything I can do to help?
CU
Werner
PS: I am on vacation till December 14th.
-Original-Nachricht-
Betreff: Re: After upgrade to Debian Bullseye, I am not able to burn DVDs.
Datum: 2021-11-26T12:45:47+0100
Von: "Thomas Schmitt"
An: "999...@bugs.debian.org" <999...@bugs.debian.org>
Hi,
w_t...@t-online.de wrote:
> When I click the tiny icon beside "DVD-R sequential recording",
> the former grayed menus for speed and writing mode are now available.
> Then I can also
> start the writing process, and it does not go to max speed and completes
> successfully.
So - with the necessary black magic - it is possible to use Xfburn
for your purpose with your drive.
Insofar this is a success. {:)
> This is all very confusing.
I agree. Desktops like XFCE, GNOME, or KDE and their applications bring
my blood pressure up to unhealthy levels every time i have use them.
(As a good classic Linuxer i use fvwm2 as window manager with a config
file that essentially stems from a 20 year old SuSE installation.)
> I have no clue what's going on here, and I am so
> sorry for bothering you with that.
No need to apologize. If i would not be interested i could just have
staid away from this bug report.
Given the lack of any active GUI developers for optical disc burning,
i have to check out the user problems with those programs in order to
distinguish their own problems from potential problems in libburn or in
my command line programs.
Any normal desktop user is more qualified than me to operate Xfburn,
Brasero, or K3B. So i cannot help with talking one of them into doing
what the user wants. At best i can lookup error messages in their code
and follow the traces to a burner problem for which i have knowledge.
But especially with K3B's C++ spaghetti code i have big difficulties
to understand. Program execution tends to vanish in a fog of class
inheritance and function overloading. Often it is hard to find the code
part which does the actual work of talking to the drive or to the burn
program.
I will next dig out the instructions how to attribute this bug report
to the Debian package K3B, because you report a reproducible K3B problem
with the upgrade from Debian 10 to Debian 11.
(I don't hold a Debian rank. But any amateur is allowed to operate the
bug tracking system by mail messages. See:
https://www.debian.org/Bugs/server-control
)
Have a nice day :)
Thomas
