Bug#1065831: document package specifiers for `upgrade`
Hi all, >> No. Without a package as an argument it won't. Thanks! You're right. Let me write it down here again: - "apt upgrade" (no argument) will never remove a package, only upgrade or install - "apt upgrade pkg_name" will remove, upgrade or install the required package to satisfy its dependencies. - "apt upgrade foo- bar+": advanced option that can be used to specifically removed or install packages. >> Julian provided an explanation in #74, 20240312113620.ga1944...@debian.org I can't access this link.. >> I'm not a Debian developer, never have been. Just someone who submitted a patch or two. And your comments have been really valuable in figuring out what's going on! Again, my confusion was because this was the first time I reported a bug AND several people jumped in the conversation! It is not usually the case ;) Regards
Bug#1065831: document package specifiers for `upgrade`
Hi all, >> (modifiers btw is not a good word. I guess it was never documented so far partly as this is a rather advanced feature and mainly because naming things is hard) yes, we brought it up in our conversation but I agree it was not directly related to the subject as it was an apt advanced option. But it was good because we were able to compare different situations (to spice things up). We even talked about "apt-get" and "aptitude" but I understand they are different commands and the purpose was not to compare behaviours among different tools. >> Well, does it really matter who is and who isn't? No, it doesn't as long as they have the right information ;) Of course, the more people involved in the issue, the better perspective we have on the problem. But it is important to know how apt is *currently* behaving to avoid misunderstanding and wrong assumptions (even from my side as well). We discovered that it is a documentation bug but my initial premise when I opened the bug was that the resolver wasn't working properly. With the right information, we usuallly get faster to the solution. Thank you all, guys! >> Nobody is born an APT developer, they are chosen based on their patch offerings! ;)
Bug#1065831: document package specifiers for `upgrade`
Hi there, > If "apt upgrade" is saying that it removes packages, that is a bug, yes. @david: it is not a bug, apparently. To put everything in a nutshell: - "apt upgrade" can remove packages - "apt upgrade" accepts specific packages to be upgraded Therefore, this behaviour is expected and documentation needs to be modified. In the meantime, while the documentation is modified, can some developer provide some explanation to the current "apt upgrade" behaviour? (*) Thanks (*) I'm a bit confused because I don't know which of the people involved in this bug are actually a developer of the apt package ;)
Bug#1065831: apt upgrade : it removes packages when it shouldn't.
Control: retitle -1 apt upgrade : it removes packages when it shouldn't.
Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)
Control: retitle -1 apt upgrade : it removes packages when it shouldn't. The case you mentioned is a tricky one, yes: *apt upgrade foo+ bar-* (I really don't know how apt handles it internally but having this option is very useful. Of course, I wouldn't remove it). I think it makes a lot of sense for "apt upgrade" to allow packages as arguments. There should be a possibility to upgrade only a set of packages and it comes in handy in some situations (i.e.: t64 upgrade). "apt upgrade" also doesn't mark upgraded packages as manually installed (as expected). But "apt install" does mark them as manually installed (as expected too). Therefore, I see 2 options here: a) Change apt documentation to include the current behaviour. But if so, it should *NOT* remove any packages. b) Remove the possibility to specify packages to upgrade as arguments (which I don't really recommend for the reasons stated above). Anyway, I think some clarification is needed from the developers to shed some light on this. Regards On Tue, Mar 12, 2024 at 3:12 AM Wesley Schwengle wrote: > On Mon, Mar 11, 2024 at 11:32:24PM +0100, Miguel Angel Rojas wrote: > > > I see. It looks like `apt upgrade ' behaves as `apt install > > > '. Which (to me) is unexpected behaviour, as the man page is > > quite > > >clear on its behaviour (man 8 apt-get): > > > > Well, clearly it shouldn’t. To begin with, “apt install” should mark a > > package as manual installed while “apt upgrade” shouldn’t (my > assumption). > > And you’re right that “apt install” can remove a package if needed to > > satisfy dependencies. > > > > On top of that, documentation clearly states that “apt upgrade” should > not > > remove any package, but it does when you specify an individual package to > > upgrade. > > > > If this is not the expected behavior, maybe this is a bug (unless I am > > missing something here). > > I do not know what the bug here is, it could be one of these options: > > 1) apt-get/apt upgrade accepts packages to upgrade where the docs state it >doesn't. The behaviour needs to change to not accept packages. > > 2) apt-get/apt upgrade accepts packages and removes packages to satisfy > deps >where the docs state it doesn't. The behaviour need to change to not > remove >any packages. There is a small edge case where you can say: `apt > upgrade foo >bar-'. Technically, it shouldn't remove packages, yet you want and > instruct >it to remove bar. > > FWIW, aptitude does not remove packages where you call `aptitude > safe-upgrade > foo'. It does remove packages when you call `aptitude full-upgrade foo'. It > also removes bar when you run `aptitude safe-upgrade foo bar-'. > > I'll leave this for the maintainers to answer. > > Cheers, > Wesley > >
Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)
> I see. It looks like `apt upgrade ' behaves as `apt install > '. Which (to me) is unexpected behaviour, as the man page is quite >clear on its behaviour (man 8 apt-get): Well, clearly it shouldn’t. To begin with, “apt install” should mark a package as manual installed while “apt upgrade” shouldn’t (my assumption). And you’re right that “apt install” can remove a package if needed to satisfy dependencies. On top of that, documentation clearly states that “apt upgrade” should not remove any package, but it does when you specify an individual package to upgrade. If this is not the expected behavior, maybe this is a bug (unless I am missing something here).
Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)
Hi Wesley, David, > You keep saying `apt upgrade' yet your command was `apt full-upgrade'. Yes, maybe it didn't express itself properly. After your suggestion about not using "apt full-upgrade" during this t64 migration, I followed your advice and used only "apt upgrade" for individual upgrades. I was referring to this comment you made below: > My advice to you is: don't expect full-upgrade to work until the transitioning > is done. You can do `apt upgrade' without too much hassle. If you feel like it > you can inspect individual upgrades possibilities via `apt list --upgradable' > and upgrade each package individually. Therefore, that's the advice I'm following right now. Now, If I type"apt upgrade" doesn't give me any option to update anything: # apt upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: linux-headers-6.6.15-amd64 linux-headers-6.6.15-common linux-image-6.6.15-amd64 linux-kbuild-6.6.15 Use 'apt autoremove' to remove them. The following packages have been kept back: gstreamer1.0-plugins-bad gstreamer1.0-plugins-good gstreamer1.0-plugins-ugly kaddressbook kmail knotes libgstreamer-plugins-bad1.0-0 libkf5akonadisearch-bin libkf5akonadisearch-plugins libkf5messagecomposer5abi1 libkf5messagecore5abi1 libkf5messagelist5abi1 libkf5messageviewer5abi1 libkf5mimetreeparser5abi1 libkf5pimcommonakonadi5abi1 libkf5templateparser5 libkf5webengineviewer5abi1 libkpimaddressbookimportexport5 libldb2 libopenconnect5 libqt5webengine5 ppp samba-libs 0 upgraded, 0 newly installed, 0 to remove and 23 not upgraded. But, in some situations, as you mentioned, individual package upgrades can work and remove some problems. So what I did was to try some "apt upgrade" on individual packages from that list. This time I try the ppp package: # apt upgrade ppp Reading package lists... Done Building dependency tree... Done Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: linux-headers-6.6.15-amd64 linux-headers-6.6.15-common linux-image-6.6.15-amd64 linux-kbuild-6.6.15 Use 'apt autoremove' to remove them. The following packages will be REMOVED: <--- PACKAGE TO BE REMOVED libpcap0.8 The following NEW packages will be installed: libpcap0.8t64 The following packages have been kept back: gstreamer1.0-plugins-bad gstreamer1.0-plugins-good gstreamer1.0-plugins-ugly kaddressbook kmail knotes libgstreamer-plugins-bad1.0-0 libkf5akonadisearch-bin libkf5akonadisearch-plugins libkf5messagecomposer5abi1 libkf5messagecore5abi1 libkf5messagelist5abi1 libkf5messageviewer5abi1 libkf5mimetreeparser5abi1 libkf5pimcommonakonadi5abi1 libkf5templateparser5 libkf5webengineviewer5abi1 libkpimaddressbookimportexport5 libldb2 libopenconnect5 libqt5webengine5 samba-libs The following packages will be upgraded: ppp 1 upgraded, 1 newly installed, 1 to remove and 22 not upgraded. Need to get 511 kB of archives. After this operation, 15.4 kB disk space will be freed. , As you can see here, I'm typing "apt upgrade ppp" and it removes a package in this case: libpcap0.8 (sometimes more packages are removed). Which is good, because libpcap0.8 is replaced by libpcap0.8t64 (as expected in this t64 migration) but "apt upgrade ppp" is REMOVING a package (which contradicts the specification). @David: I will send you the file as you requested. Regards On Mon, Mar 11, 2024 at 5:44 PM Wesley Schwengle wrote: > > Hi Miguel, > > On Mon, Mar 11, 2024 at 05:09:47PM +0100, Miguel Angel Rojas wrote: > > > I do not know, at times I'm also wondering why it doesn't do it, but I > > didn't > > > take time to look at the code to understand what the resolver is doing. > > Also, > > > it was sort of expected. I think we can probably solve this is a more > > > controlled manner. With the current t64 transitioning in unstable it is > > > difficult to track down. Many updates so the situation now may differ > > from the > > > situation in an hour from now. > > > > Yes, it is confusing for me too. Without considering this t64 migration, > > “apt upgrade” should *NOT* remove any package (just upgrading a package > to > > a newer version or install new dependencies). But it is removing packages > > right now! i.e. again, with this t64 migration, it makes the old > libraries > > to be uninstalled and install the new *t64 version. > > > > Any thoughts why “apt upgrade” is removing packages even when > documentation > > says it shouldn’t? or is it a bug? > > You keep saying `apt upgrade' yet your command was `apt full-upgrade'. As > said > earlier, full-upgrade does indeed remove packages to be able to perform an > upgrade. I haven't seen `apt upgrade' do that. So I cannot comment on apt > doing > something wrong when it isn't :) > > Cheers, > Wesley >
Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)
Hi Wesley, Good conversation here. Let me give you some comments from my side: > No, there is (or was) something going on with the dependencies of gdm-minimal > for sure. I think it is related to libdebuginfod1, which has a t64 variant. > This one has a dependency to libelf1 and libdw1. Now the libdebuginfod1t64 > depends on libelf1t64 and libdw1t64. These two replace libelf1 and libdw1, the > former having a relative high count of reverse dependencies. I didn’t catch this one (and I spent a fair amount of time trying to find out what was going on) ;) Thank you for spotting it! > I do not know, at times I'm also wondering why it doesn't do it, but I didn't > take time to look at the code to understand what the resolver is doing. Also, > it was sort of expected. I think we can probably solve this is a more > controlled manner. With the current t64 transitioning in unstable it is > difficult to track down. Many updates so the situation now may differ from the > situation in an hour from now. Yes, it is confusing for me too. Without considering this t64 migration, “apt upgrade” should *NOT* remove any package (just upgrading a package to a newer version or install new dependencies). But it is removing packages right now! i.e. again, with this t64 migration, it makes the old libraries to be uninstalled and install the new *t64 version. Any thoughts why “apt upgrade” is removing packages even when documentation says it shouldn’t? or is it a bug? > I disagree (or agree) to some extent. The gdb-minimal has been held back on my > system for a long time. I removed it after I saw it was a remnant of a KDE > experiment I did. The fact that I can install it now is a change from a couple > of days ago. The bug may be the same, but with how unstable it is now with > this big transition, it's wise to leave it where we are now and break it down > into a more controlled reproduction path, where we don't have so many moving > pieces. Yes, I fully agreed with that! Let’s wait until packages are fully settled down. I have a feeling that it is the same bug but there is no way to probe it with this transition going on. Regards On Mon, Mar 11, 2024 at 3:04 PM Wesley Schwengle wrote: > > Hello Miguel, > > On Mon, Mar 11, 2024 at 09:50:12AM +0100, Miguel Angel Rojas wrote: > > > >This problem isn't because of apt, the problem is that gdb-minimal/gdb > > > dependencies cannot be satified. A full-upgrade is the equivalent of a > > > dist-upgrade which will remove packages to resolve the dependencies. > The > > > problem you are facing is the t64 transition[1][2] where not all > packages > > are > > > transitioned. > > > > I haven't detected any "gdb | gdb-minimal dependencies that can't be > > satisfied at this point. Everything seems to be OK with those packages. > > No, there is (or was) something going on with the dependencies of > gdm-minimal > for sure. I think it is related to libdebuginfod1, which has a t64 variant. > This one has a dependency to libelf1 and libdw1. Now the libdebuginfod1t64 > depends on libelf1t64 and libdw1t64. These two replace libelf1 and libdw1, > the > former having a relative high count of reverse dependencies. > > > > My advice to you is: don't expect full-upgrade to work until the > > transitioning > > > is done. > > > > You nail it here! I have managed to upgrade package by package but it is > a > > tedious process until the whole transition is completed. > > Some of them yes, but often after doing one, you can use `apt upgrade' to > see if it resolved other problems (which in my case it does from time to > time). > > > But "apt upgrade" > > should not remove any packages according to its documentation (man apt) > > That is correct, but you were executing full-upgrade: > > > > On Sun, Mar 10, 2024 at 02:13:34PM +0100, Miguel Angel wrote: > > > > > > > # apt full-upgrade > > > > Reading package lists... Done > > > > Building dependency tree... Done > > > > Reading state information... Done > > > > Calculating upgrade... Error! > > > > 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: > > > Why is this t64 upgrade working then as it is removing deprecated > packages > > for *t64 packages? > > I do not know, at times I'm also wondering why it doesn't do it, but I > didn't > take time to
Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)
Hi Wesley, >This problem isn't because of apt, the problem is that gdb-minimal/gdb > dependencies cannot be satified. A full-upgrade is the equivalent of a > dist-upgrade which will remove packages to resolve the dependencies. The > problem you are facing is the t64 transition[1][2] where not all packages are > transitioned. I haven't detected any "gdb | gdb-minimal dependencies that can't be satisfied at this point. Everything seems to be OK with those packages. > My advice to you is: don't expect full-upgrade to work until the transitioning > is done. You nail it here! I have managed to upgrade package by package but it is a tedious process until the whole transition is completed. But "apt upgrade" should not remove any packages according to its documentation (man apt) *"upgrade is used to install available upgrades of all packages currently installed on the system from the sources configured via sources.list(5). New packages will be installed if required to satisfy dependencies, but existing packages will never be removed. If an upgrade for apackage requires the remove of an installed package the upgrade for thispackage isn't performed."* Why is this t64 upgrade working then as it is removing deprecated packages for *t64 packages? > This seems to be an more of an actual issue where dependencies are declared but >apt doing something weird. But that is an issue on bookworm where we aren't >getting poluted results because of a transitioning. I'm glad you were able to replicate in bookworm (stable) it but I don't think (at least in this case) it is related to the t64 transition. Same errors on both distributions and I checked that gdb dependencies were satisfied in unstable (I don't have a system running stable). > I don't know either and that question should be redirected to the > plasma-workspace maintainer. good advice! I will. Appreciate your support. Thanks! On Sun, Mar 10, 2024 at 8:20 PM Wesley Schwengle wrote: > On Sun, Mar 10, 2024 at 02:13:34PM +0100, Miguel Angel wrote: > > > # apt full-upgrade > > Reading package lists... Done > > Building dependency tree... Done > > Reading state information... Done > > Calculating upgrade... Error! > > 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: > > plasma-workspace : Depends: gdb-minimal but it is not going to be > installed or > > gdb > > E: Error, pkgProblemResolver::Resolve generated breaks, this may be > caused by held packages. > > > > This problem isn't because of apt, the problem is that gdb-minimal/gdb > dependencies cannot be satified. A full-upgrade is the equivalent of a > dist-upgrade which will remove packages to resolve the dependencies. The > problem you are facing is the t64 transition[1][2] where not all packages > are > transitioned. > > My advice to you is: don't expect full-upgrade to work until the > transitioning > is done. You can do `apt upgrade' without too much hassle. If you feel > like it > you can inspect individual upgrades possibilities via `apt list > --upgradable' > and upgrade each package individually. That has worked well for me in the > past > week with aptitude, but it requires going through many offered solutions. > > > I've seen other users are experimenting the same issue: > > https://groups.google.com/g/linux.debian.user/c/7gpQImSH-Cs > > This seems to be an more of an actual issue where dependencies are > declared but > apt doing something weird. But that is an issue on bookworm where we aren't > getting poluted results because of a transitioning. It differs from yours > because your apt output says "gdb-minimal but it is not going to be > installed > or gdb" so apt sees the alternative, but cannot install it either. IMHO, > that should > be filed as a seperate bug against apt on bookworm. And if possible > checked on > testing as well. FWIW, I can reproduce it on bookwork with apt, apt-get and > aptitude, where the latter offers a solution to install gdb and not > deinstall > plasma-workspace. > > > I don't know why plasma-workspace depends on gdb > > I don't know either and that question should be redirected to the > plasma-workspace maintainer. > > Cheers, > Wesley > > [1] https://lists.debian.org/debian-devel-announce/2024/02/msg0.html > [2] > https://www.reddit.com/r/debian/comments/1b2ncdn/64bit_time_t_transition_in_progress_in_unstable/ > >
Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2
Hi Diederik, > While 'annoying', this is expected behavior. It tries to load the newest (-83) Yes, this is the expected behavior from our Linux kernel. However, I agree with you and these messages are very annoying and should be removed. > It could be it wouldn't be shown if it had already found one of the earlier logged firmware files. Interesting theory! When the new version of the firmware packages is uploaded, we can check again if the "'iwl-debug-yoyo.bin" message disappears Why are you confused with the numbers? >Bit confused about that version number, but looks like success. And yes, wifi is working fine although I haven't properly done any performance test yet. Regards On Sun, Feb 11, 2024 at 4:15 PM Diederik de Haas wrote: > Hi Miguel, > > On Sunday, 11 February 2024 16:03:20 CET Miguel A. Rojas wrote: > > I forgot to include you the dmesg as promised: > > > > [2.235947] iwlwifi :00:14.3: enabling device ( -> 0002) > > [2.237778] iwlwifi :00:14.3: Detected crf-id 0x1300504, cnv-id > > 0x80401 wfpm id 0x8030 > > [2.237805] iwlwifi :00:14.3: PCI dev 7a70/0074, rev=0x430, > > rfid=0x10a100 > > [2.237845] iwlwifi :00:14.3: firmware: failed to load > > iwlwifi-so-a0-hr-b0-83.ucode (-2) > > [2.237867] iwlwifi :00:14.3: firmware: failed to load > > iwlwifi-so-a0-hr-b0-83.ucode (-2) > > ... more firmware load failures > > [2.238098] iwlwifi :00:14.3: Direct firmware load for > > iwlwifi-so-a0-hr-b0-73.ucode failed with error -2 > > [2.241012] iwlwifi :00:14.3: firmware: direct-loading firmware > > iwlwifi-so-a0-hr-b0-72.ucode > > While 'annoying', this is expected behavior. It tries to load the newest > (-83) > and when it can't find that, it tries an older one and ends up with '-72'. > > > [2.247819] iwlwifi :00:14.3: api flags index 2 larger than > > supported by driver > > [2.247832] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: > > 0.0.2.36 > > [2.248049] iwlwifi :00:14.3: firmware: failed to load > > iwl-debug-yoyo.bin (-2) > <- > > [2.248067] iwlwifi :00:14.3: firmware: failed to load > > iwl-debug-yoyo.bin (-2) > <- > > This 'iwl-debug-yoyo.bin' is a familiar one, but this file is NOT > available in > the upstream linux-firmware repo. > It could be it wouldn't be shown if it had already found one of the > earlier > logged firmware files. > I might look into this particular issue at some later date. > > > [2.248078] iwlwifi :00:14.3: loaded firmware version > > 72.daa05125.0 so-a0-hr-b0-72.ucode op_mode iwlmvm > > Bit confused about that version number, but looks like success ... > > > [2.653952] iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6 AX201 > > 160MHz, REV=0x430 > > [2.769070] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f > > [2.769102] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f > > [2.769110] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90 > > [2.769118] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10 > > [2.769154] iwlwifi :00:14.3: Detected RF HR B3, rfid=0x10a100 > > [2.834751] iwlwifi :00:14.3: base HW address: bc:09:1b:d3:e2:ee > > [2.849492] iwlwifi :00:14.3 wlp0s20f3: renamed from wlan0 > > [6.570171] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f > > [6.570263] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f > > [6.570275] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90 > > [6.570307] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10 > > [6.644756] iwlwifi :00:14.3: Registered PHC clock: iwlwifi-PTP, > > with index: 0 > > [6.809353] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f > > [6.809386] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f > > [6.809397] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90 > > [6.809408] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10 > > ... and from this it seems the device appears to be working properly? > > If that's indeed the case then this bug would essentially be a request for > a > new upstream version. > > Cheers, > Diederik
Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2
Hi Diederik, My bad. Let me explain again. Taking into account the firmware errors: - Realtek messages are fixed now. There are no actions to be done here. - iwlwifi: If you are still working on a new version containing the -83 file, that should fix some warning messages but not all of them. There is another message (*firmware: failed to load iwl-debug-yoyo.bin (-2)*) that I think is related to bug #966218. This bug has been there for a while, so I don't know what's happening here. Nobody explains what's going on or why this file is not included in the firmware package. Thanks! On Fri, Feb 9, 2024 at 7:48 PM Diederik de Haas wrote: > Control: tag -1 moreinfo > > Hi, > > On Friday, 9 February 2024 19:35:01 CET Miguel A. Rojas wrote: > > A few days ago, I went to > > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git > > and update the missing loaded modules. > > > > Indeed, I noticed that I have another messages related to the iwlwifi > > module: "kernel: iwlwifi :00:14.3: firmware: failed to load > > iwlwifi-so-a0-hr-b0-83.ucode (-2)". > > The reason I asked for more dmesg lines is that it likely then tried > (f.e.) > -81, then -79 and then probably succeeded at some point. > The Debian kernel (unfortunately imo) 'promoted' warning/info messages to > errors, which make it appear more severe then they actually are. > > > I think the the root cause is that the current Debian packages firmware > > packages are 6 months old and they need to be updated accordingly. New > > Debian Linux kernel expects a specific version of the firmware or the > > name of the firmware has changed. > > I do think that the old package versions are a problem, so I have been > working > on Merge Requests for updating them. > Version 20230804 would make the -83 file available. > But the device using and older version should still work. If it doesn't > work > with an older version, but it does work with a newer, that's important > info. > > But I'm still a bit confused as this bug is about *realtek* firmware, not > iwlwifi? Can you answer the question I asked previously?
Bug#1052012: plasma-workspace: sddm presents a white screen with no background nor buttons
Hi there, Downgrading the following packages: - sddm-themes-breeze - sddm-theme-debian-breeze to version 4:5.27.7-2 makes sddm fully usable again with no issues. It seems some changes have been made on version 4:5.27.8-1 that have broken sddm. I hope this helps. Regards
Bug#1040174: nvidia-driver: Can't upgrade to nvidia-driver-525.116.04-1 on debian unstable: build fails
Hi there, I can confirm the bug is there. Libraries are not found and NVIDIA driver fails to build. Regards
Bug#934648: Acknowledgement (nvidia-kernel-dkms: Nvidia 418.74 does not build with kernel 5.2.0 (put_user_pages))
Hi all, It seems the problem is fixed with the new release (418.88) Thanks On Tue, Aug 13, 2019 at 12:42 AM Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 934648: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934648. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > As you requested using X-Debbugs-CC, your message was also forwarded to > mianro...@gmail.com > (after having been given a Bug report number, if it did not have one). > > Your message has been sent to the package maintainer(s): > Debian NVIDIA Maintainers > > If you wish to submit further information on this problem, please > send it to 934...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 934648: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934648 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems >
Bug#799948: Plasma desktop is unable to start (black screen - panic)
> > > I must first say that I am absolutely not familiar with KDE, the QT > environment and how it works. But the thread that raises the abort > doesn't look like it's in the GL libraries code: > > Maybe there's some context I'm missing. Forgive me for asking, but are > you sure this is due to the Nvidia driver packages or glx-alternatives? > > Hi Luca, But indeed, it is! I conducted the same experiments as Vladimir did with the same result. Something is wrong with the glx beyond 0.6.x (bad packaging, new API, new behavior? I don't know). I would recommend to reproduce as it is very easy to do it and you will see what we are talking about. Talking about Bug #799948, is there a reason why sddm user should be included in video? (because it seems to be the workaround) If so, someone should notify sddm guys that is somehow required due to new upstream requirement in nvidia glx packages. We don't have a clear explanation about it. Regards
Bug#799948: Plasma desktop is unable to start (black screen - panic)
Hi Luca, Here you have the report you asked about the plasmashell. I do not know if it could be related to a configuration issue, but again very easy to reproduce. Here you have 2 reports (same error in 2 consecutive log on sessions). These crashes are related to the plasmashell (I manually fixed the workaround by adding the sddm user to the video group) but if you remove it, sddm is the one who crashes. Hope it helps. Application: Plasma (plasmashell), signal: Aborted Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f972f7dc940 (LWP 1799))] Thread 7 (Thread 0x7f9718aeb700 (LWP 1801)): #0 0x7f9729f6252d in poll () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7f972dfb2252 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #2 0x7f972dfb3ddf in xcb_wait_for_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #3 0x7f971ac4c2f9 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so #4 0x7f972a64b25e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f972976b0a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #6 0x7f9729f6b06d in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 6 (Thread 0x7f971220c700 (LWP 1806)): #0 0x7f972a881391 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #1 0x7f9726d2176d in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f9726d2210b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f9726d222ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7f972a881e4b in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f972a8282ca in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7f972a646374 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7f972ce7b055 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #8 0x7f972a64b25e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x7f972976b0a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #10 0x7f9729f6b06d in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 5 (Thread 0x7f9709f46700 (LWP 1810)): #0 0x7f97297717fc in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7f972976d4d4 in _L_lock_986 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x7f972976d336 in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0 #3 0x7f972614de90 in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1 #4 0x7f972615141e in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1 #5 0x7f972615181b in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1 #6 0x7f97226fafc0 in ?? () from /usr/lib/x86_64-linux-gnu/tls/libnvidia-tls.so.340.93 #7 0x7f9726d654d0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #8 0x7f9726d21cc4 in g_main_context_check () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #9 0x7f9726d22180 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #10 0x7f9726d222ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #11 0x7f972a881e4b in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #12 0x7f972a8282ca in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #13 0x7f972a646374 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #14 0x7f972ce7b055 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #15 0x7f972a64b25e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #16 0x7f972976b0a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #17 0x7f9729f6b06d in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 4 (Thread 0x7f97035c8700 (LWP 1814)): #0 0x7f9726d221c2 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #1 0x7f9726d222ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f972a881e4b in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #3 0x7f972a8282ca in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7f972a646374 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f972ce7b055 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #6 0x7f972a64b25e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7f972976b0a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #8 0x7f9729f6b06d in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 3 (Thread 0x7f9701d32700 (LWP 1815)): #0 0x7f972976f08f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7f972f222144 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Script.so.5 #2 0x7f972f222189 in ?? () from
Bug#800938: Bug#799948: Plasma desktop is unable to start (black screen - panic)
Hi Luca, Thanks for the quick answer! Here you have both report you asked for. Hopefully it will help us to know where the issue is. Regards On Sun, Oct 18, 2015 at 9:43 PM, Luca Boccassi <luca.bocca...@gmail.com> wrote: > On Sun, 2015-10-18 at 20:16 +0200, Miguel Angel Rojas wrote: > > Hi all, > > > > > > Vladimir is right, same issue here. Indeed, It is weird to me not so > > many people is currently reporting on it, but it is affecting a lot of > > programs. Something happens when upgrading to version 0.6.x (I agree > > at this point) > > > > > > plasma-desktop is also unable to start and panic (black screen).If you > > update-alternative glx fall back to mesa, the desktop runs just fine > > (of course, without the nvidia drivers) > > > > > > I though it was solved by bug 799948 (ssdm panic too), but again, it > > is not. At least you can "adduser sddm video" and make ssdm-greater > > works as a workaround, but plasma-desktop panics still panics after > > you try to log on. > > > > > > > > It is very easy to check it. Just install a fresh installation of KDE > > and nvidia drivers and you will see a beautiful black screen. Let me > > know if you need additional information but it is quite easy to > > reproduce > > Hi, > > Could you please attach the output of: > > reportbug --template glx-alternative-nvidia > reportbug --template nvidia-driver > > Kind regards, > Luca Boccassi > > -- Package-specific info: Diversions: diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/libGLESv1_CM.so to /usr/lib/mesa-diverted/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/l
Bug#799948: Plasma desktop is unable to start (black screen - panic)
Hi all, Vladimir is right, same issue here. Indeed, It is weird to me not so many people is currently reporting on it, but it is affecting a lot of programs. Something happens when upgrading to version 0.6.x (I agree at this point) plasma-desktop is also unable to start and panic (black screen).If you update-alternative glx fall back to mesa, the desktop runs just fine (of course, without the nvidia drivers) I though it was solved by bug 799948 (ssdm panic too), but again, it is not. At least you can "adduser sddm video" and make ssdm-greater works as a workaround, but plasma-desktop panics still panics after you try to log on. It is very easy to check it. Just install a fresh installation of KDE and nvidia drivers and you will see a beautiful black screen. Let me know if you need additional information but it is quite easy to reproduce Regards
Bug#693512: [Pkg-utopia-maintainers] Bug#693512: network-manager: Network manager does not remove default routes
Hi Michael, Thanks for the troubleshooting. I think we have several options here (as far as I see). We can also combined some of them: - Modify ifupdown to be aware of networkmanager installation (as you suggested) - Modify networkmanager to remove/modify/backup /e/n/i interfaces managed by it (at installation time only or automatically done after the interfaces is managed by networkmanager - this last one is even complex?) - Message in networkmanager at installation time if ifupdown is installed (also include this information in /usr/share/doc) - Modify networkmanager documentation ( http://wiki.debian.org/NetworkManager#Enabling_Interface_Management) to point out Michael suggestion to manually remove references in /e/n/i for interfaces managed by networkmanager (if not done automatically by previous options) What do you think? Regards On Sun, Nov 18, 2012 at 1:39 PM, Michael Biebl bi...@debian.org wrote: On 18.11.2012 13:29, Miguel A. Rojas wrote: # The primary network interface allow-hotplug eth0 iface eth0 inet static address 192.168.2.2 netmask 255.255.255.0 network 192.168.2.0 broadcast 192.168.2.255 gateway 192.168.2.1 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 85.62.229.131 85.62.229.132 --- As you may see, after networkmanager installation, /etc/network/interfaces was not modified (I do not know if this is the default behaviour). I managed to enable interface managed according to http://wiki.debian.org/NetworkManager#Enabling_Interface_Management. After doing that, networkmanager was able to manage the interface and I suppose it got the information from /etc/network/interfaces. Let me know if you need anything else from my side. I really do not know where this route is coming from. Perhaps I did something wrong in the procedure, but I just followed the standard manuals. So, the problem is basically this: You have eth0 configured in /etc/network/interfaces. This device is now configured *both* by ifupdown and NetworkManager if you set managed=true. So I actually do not recommend that as maintainer of network-manager (contrary to what the wiki says). So, if you want to manage eth0 with NetworkManager it is better to remove the (eth0) configuration from /etc/network/interfaces completely, so ifupdown does no longer touch it. Now, while NetworkManager does not enable a ethernet interface if there is no network link, ifupdown does not care. It simply runs ifup eth0 during boot. This is why your eth0 network device is brought up and you have this route entry. So, in summary, I don't think there is actually a bug in network-manager. It's just the way what happens if you configure your system to use managed=true. Andrew, do you have a better idea how to handle this situation? Could ifup/ifdown be changed to check if managed=true is set and not configure the device in this case? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Bug#651229: console-setup: ckbcomp not found when booting
Hi Anton, I see you point. I am not an expert on this but here are my thoughts: - If ckbcomp could not be called at boot time... why this is inside in /bin/setupcon (which is called at boot time)? Same idea for the other binaries you mentioned - How is the preliminary keymap precompiled in /etc/console-setup ? Which command should you execute? - Perhaps the warning should mention my 2nd point above and this will avoid this warning. What do you think? Regards
Bug#572655: libopenipmi0 depends on non-existing package libglib1.2ldbl
Package: libopenipmi0
Version: 2.0.16-1.1
Severity: grave
# aptitude install libopenipmi0
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information... Done
Initializing package states... Done
Reading task descriptions... Done
The following NEW packages will be installed:
libopenipmi0{b}
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 579kB of archives. After unpacking 1,466kB will be used.
The following packages have unmet dependencies:
libopenipmi0: Depends: libglib1.2ldbl (= 1.2.10-18) which is a virtual
package.
The following actions will resolve these dependencies:
Keep the following packages at their current version:
1) libopenipmi0 [Not Installed]
Tier: Cancel all user actions (2)
Accept this solution? [Y/n/q/?]
It seems that libglib1.2ldbl does not exist anymore in debian repositories
and source package could not be found.
Could you please fix it?
Thanks.
Bug#513142: ucf/dbconfig warning when package is installed
Hi Michael, Here is the version I use (I think is the lastest one): # dpkg -l | grep dbconfig ii dbconfig-common 1.8.40 common framework for packaging database applications Thanks for your quick reply. Today, I've upgrade the rest of the packages you uploaded yesterday (zabbix-agent zabbix-server-mysql) with same result: Configuring zabbix-agent (1:1.6.2-2) ... Starting Zabbix agent: zabbix_agentd Configurando zabbix-server-mysql (1:1.6.2-2) ... dbconfig-common: writing config to /etc/dbconfig-common/zabbix-server-mysql.conf *** WARNING: ucf was run from a maintainer script that uses debconf, but the script did not pass --debconf-ok to ucf. The maintainer script should be fixed to not stop debconf before calling ucf, and pass it this parameter. For now, ucf will revert to using old-style, non-debconf prompting. Ugh! Please inform the package maintainer about this problem. dbconfig-common: flushing administrative password Starting Zabbix server: zabbix_server Let me know if you need more information. Miguel. On Tue, Jan 27, 2009 at 9:40 AM, Michael Ablassmeier a...@grinser.de wrote: tags 513142 + unreproducible thanks hi Miguel, On Mon, Jan 26, 2009 at 09:34:26PM +0100, Miguel A. Rojas wrote: Configuring zabbix-frontend-php (1:1.6.2-2) ... dbconfig-common: writing config to /etc/dbconfig-common/zabbix-frontend-php.conf *** WARNING: ucf was run from a maintainer script that uses debconf, but the script did not pass --debconf-ok to ucf. The maintainer script should be fixed to not stop debconf before calling ucf, and pass it this parameter. For now, ucf will revert to using old-style, non-debconf prompting. Ugh! Please inform the package maintainer about this problem. I do not know if this happens in a fresh installation of 1.6.2-2 (without upgrade from previous versions) because I just upgraded from the previous version: 1.6.2-1 -- 1.6.2-2 and this error appears. i cant reproduce this error. Neither on a fresh installation, nor on upgrade from 1.6.2-1. The zabbix-frontend-php packages postinst isnt calling ucf anyways. Its only called in postrm on purge (which works nicely too). So i guess it may also be dbconfig-common which produces this warning. What dbconfig-common version are you using? bye, - michael
Bug#513012: Confirmed using old vars in zabbix.conf.php from zabbix developers
Hi, It is confirmed that variable parameters we are using are not the one zabbix are using right now. The reason why DB_* vars are still working is for compatibility reason for older versions. Here you have the link: http://www.zabbix.com/forum/showthread.php?t=11593 Michael, do you want me to report another bug about it or we can reopen this bug and fix it? I really appreciate your work. Very fast to be solved!! Regards.
