Re: Firmwares (was Re: Bits from the DPL)
On Mon, 1 Apr 2024 at 19:28, Vincent Bernat wrote: > > On 2024-04-01 18:05, Jonathan Carter wrote: > > The included firmware contributed to Debian 12 being a huge success, > > but it wasn't the only factor. > > Unfortunately, the shipped firmwares are now almost a year old, > including for unstable. I am following the progress since quite a few > years and I have seen many possible contributors trying to help and > fail. The current situation is that Debian does not work well with > recent AMD-based laptops due to firmware being too old. Therefore, we > are back at users trying to update the firmware by copying them from > random places (as for myself, I am using the deb generated by upstream's > Makefile). > > My personal impression is that we are repeating a common scheme in > Debian: maintainers don't have time to move forward due to the task > being non-trivial for reasons of our own, people are proposing to help > (6 people in [1]), but this is ignored by the maintainers as they don't > have time. As one of the persons who tried and failed to do the update, I wouldn't blame maintainers ignoring my PR. I would have appreciated getting more prompt feedback, but I understand that we all are doing this during our spare time. There was another issue which I could not find my way through. I found it pretty troublesome to update debian/config subdirs. There is no clear reference whether the Version should follow the WHENCE or the firmware version from the git commit message (they differ for Intel BT files). So, my 2c, packaging infrastructure should use WHENCE file where possible instead of duplicating a significant part of it. -- With best wishes Dmitry
Bug#1050354: ITP: qbootctl -- utility to control Quacomm A/B boot slots
Package: wnpp Severity: wishlist Owner: Dmitry Baryshkov X-Debbugs-Cc: debian-devel@lists.debian.org, debian-on-mobile-maintain...@alioth-lists.debian.net * Package name: qbootctl Version : 0.1.2 Upstream Contact: Caleb Connolly * URL : https://gitlab.com/sdm845-mainline/qbootctl * License : GPL v3 Programming Lang: C++ Description : utility to control Quacomm A/B boot slots Qbootctl is a CLI tool for manipulating A/B slots on Android devices. It is a port of the original Android bootctrl HAL developed by Qualcomm, modified to build on Linux and provide a friendly CLI interface. This utility is useful to switch between A/B boot slots on the Qualcomm platforms and also to mark the current boot attempt as successful (or not).
Re: Questionable Package Present in Debian: fortune-mod
On Sat, 19 Aug 2023 at 00:52, Dominik George wrote: > > > So, let's at least be consistent. > > Totally agree with that. > > Debian is not a collection of harmful content, it is an operating system. > > But, unfortunately, there are too many people in the project who think, in > the name of "free speech", protecting racists, nazists, and anarchists is > more important than protecting PoC, jews, or other minorities. Coming from the country that started to ban some kinds of information "to protect children", later transferring that to a whole wide censorship, I'd support protecting 'free speech', which includes all kinds of minorities: PoC, LGBTQ+ and anarchists, masochists, etc. According to Debian's CoC we use non-offensive ways to communicate within the project, so that everybody is welcome to speak and contribute. But we should not censor software. If there is a misogynistic comment in GNU HURD sources, should we censor it out? -- With best wishes Dmitry
Re: Firmware GR result - what happens next?
Hello, вс, 2 окт. 2022 г. в 22:36, Steve Langasek : > > On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote: > > >What's the plan for upgraded systems with an existing > > >/etc/apt/sources.list. > > >Will the new n-f-f section added on upgrades automatically(if non-free was > > >enabled before)? > > > So this is the one bit that I don't think we currently have a good > > answer for. We've never had a specific script to run on upgrades (like > > Ubuntu do), so this kind of potentially breaking change doesn't really > > have an obvious place to be fixed. > > > Obviously we'll need to mention this in the release notes for > > bookworm. Should we maybe talk about adding an upgrade helper tool? > > I heartily endorse ubuntu-release-upgrader, it has been useful in addressing > uncounted upgrade issues over the years and I think something like this > would be a nice addition to Debian as well. Two caveats: I'd kindly ask against additional upgrade scripts. It is too easy to miss them, especially if one has been using Debian for ages with bare apt-get update && apt-get dist-upgrade. Moreover such a script will not help people that are already using testing. For the past few decades, updating the setup was always a job of the package scripts. Thus we potentially can have an addon in the apt's postinstall script that will check if the user is running bookworm, the non-free repo is enabled and non-free-firmware is not. In such case postinst can present user with a choice of ignoring n-f-f, attempting automatic '/bookworm/s/non-free/non-free non-free-firmware/' or letting user to fix setup. This way the user will be present with such choice whichever path he uses to update to bookworm. -- With best wishes Dmitry
Re: RFC: pam: dropping support for NIS/NIS+?
чт, 21 апр. 2022 г. в 11:04, Gabor Gombas : > > Hi, > > On Wed, Apr 20, 2022 at 04:26:02PM -0400, Boyuan Yang wrote: > > > Before any discussion takes place, I would like to point out a previous > > attempt of Fedora trying to get rid of NIS/NIS+ back in 2021. Please check > > out > > the LWN article at https://lwn.net/Articles/874174/ , which would definitely > > be helpful for the condition in Debian. > > That discussion seems to be about removing NIS/NIS+ support from the > entire distribution. This thread is about removing NIS support from PAM. > That's an important distinction, because in practice, NIS/NIS+ support > mostly means the NSS modules, and the tools/servers in the case of NIS. > > Dropping NIS support from PAM would mean losing only the ability to > change the passwords of users coming from NIS. It would not affect user > lookups, and password change would still be possible using yppasswd. > There does not even seem to be any NIS+ support in PAM - nothing seems > to include . > > Personlly, I think bundling NIS password changing capability in pam_unix > was a design mistake. It should always have been a distinct module. Can we provide a separately packaged pam_unix_nis which can be used instead of pam_unix in cases where this functionality is still required? -- With best wishes Dmitry
