Re: How about sources.sources? (Was: Question Regarding sources.list)
On Du, 24 mai 20, 14:55:33, Cindy Sue Causey wrote: > > /etc/apt/sources.list.d/sources.sources > > DISCLAIMER: This format was originally found when something like "man > apt-get", "man apt", or "man sources.list" referenced a standalone > "man sources.sources" type deal. I can't find it just this second. I > didn't dream this up and sure don't cognitively function well enough > to have grasped what APPEARS to be describing it under "DEB822-STYLE > FORMAT" within "man sources.list". man sources.list > The rest of the email now... > > For this to work, you have to rename everything else (the files NOT > directories) or even delete anything else "*.list" because it doesn't > function otherwise (at least not for ME). There is no such restriction. > Those don't specifically state "bullseye-updates" anywhere. I DO > remember addressing it somehow because I have "*-updates" in archived > sources.list files from various previous *suites*. Having just updated > 115MB of Bullseye, SOME updates are still working just fine. > > Comparing past DOTlist to present DOTsources, it looks like MY > bullseye-updates is now covered by that bullseye-security reference. > That sounds familiar'ish. bullseye is still (in) testing, -security and -updates are empty. > FOR ME, this layout/feature/technique didn't work pre-Bullseye. > Without exiting, rebooting, digging through other... suites.. yada, I > don't know if this is a new perk for Bullseye or needs tweaked > differently for past suites. According to the manpage it was introduced in apt 1.1 (stretch has 1.4.10). > PPPS Any outside 3rd party type packages that have been given > permission to set up their own DOTlist files... will potentially > complain that they can't find something or other yada. They're talking > about how you may or may not now (?) have to delete DOTlist files for > this TRICK (i.e. RADICAL.. COOL..) feature to work correctly. [citation needed] Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: How about sources.sources? (Was: Question Regarding sources.list)
On 5/24/20, Cindy Sue Causey wrote: > > PPPS Any outside 3rd party type packages that have been given > permission to set up their own DOTlist files... will potentially > complain that they can't find something or other yada. They're talking > about how you may or may not now (?) have to delete DOTlist files for > this TRICK (i.e. RADICAL.. COOL..) feature to work correctly. > > Their data can be worked right into that same lineup within that same > single sources.sources file. Example: > > Types: deb > URIs: https://deb.opera.com/opera-stable/ > Suites: stable > Components: non-free > > CAVEAT: You MIGHT or MIGHT NOT still have to work through granting > them permission via something like that curl/apt-key step. MAYBE. Time > and case-by-case usage will tell.. Amending this part to mention that the referenced curl/apt-key step is that one that helps verify the package's integrity before installing. > PS to that as I look at that block: IF you use Bullseye non-free, that > right there could possibly be combined into the same single block with > your Bullseye data. I only use Bullseye main so that won't work for my > own usage case. Started playing with this again while waiting for a camera battery to charge up. You can change the names AND have multiple different files all ending with DOTsources. It's working the same way that it does with DOTlist files. My sources.sources is now momentarily renamed to debian.sources. Also created a nonfree.sources and plugged that browser block above into it. Ran "apt-get update" with no sources.sources file... no errors... no balking. Yay! #ThankYou to whichever Developers created that option. I really LOVE that stacked way of cognitively picking out the details from each block. Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
How about sources.sources? (Was: Question Regarding sources.list)
On 4/12/20, Chris Debian wrote: > > I recently installed Debian Bullseye > > I am a complete beginner. *heh!* You sound like me. That's about what I do.. Go for unstable as a newbie. Live #LIFE large! :) > My sources.list files is below: > > # See https://wiki.debian.org/SourcesList for more information. > deb http://deb.debian.org/debian/ bullseye main > deb-src http://deb.debian.org/debian/ bullseye main > > deb http://deb.debian.org/debian/ bullseye-updates main > deb-src http://deb.debian.org/debian/ bullseye-updates main > > deb http://security.debian.org/debian-security/ bullseye-security main > deb-src http://security.debian.org/debian-security/ bullseye-security main I left that in for comparison. This is mine... except that mine is instead created as: /etc/apt/sources.list.d/sources.sources DISCLAIMER: This format was originally found when something like "man apt-get", "man apt", or "man sources.list" referenced a standalone "man sources.sources" type deal. I can't find it just this second. I didn't dream this up and sure don't cognitively function well enough to have grasped what APPEARS to be describing it under "DEB822-STYLE FORMAT" within "man sources.list". The rest of the email now... For this to work, you have to rename everything else (the files NOT directories) or even delete anything else "*.list" because it doesn't function otherwise (at least not for ME). For example, I leave my old sources.list in place but change it to sourcesDOTlist. That's just as a readily available fallback in case sources.sources ever starts failing. As of seconds ago, MY *newest* sources.sources file's contents are: Types: deb deb-src URIs: http://deb.debian.org/debian http://mirrors.namecheap.com/debian Suites: bullseye Components: main Types: deb URIs: http://distro.ibiblio.org/debian Suites: bullseye Components: main Types: deb deb-src URIs: http://security.debian.org/debian-security Suites: bullseye-security Components: main contrib non-free The change I just made was to test drive having more than one repository in a single line BECAUSE there's an "s" at the end of "URIs" there. After update, things are perfect with the expected result being the addition of appropriate new files showing up under /var/lib/apt/lists. iBiblio has its own entry because it was failing over deb-src for some reason. Those don't specifically state "bullseye-updates" anywhere. I DO remember addressing it somehow because I have "*-updates" in archived sources.list files from various previous *suites*. Having just updated 115MB of Bullseye, SOME updates are still working just fine. Comparing past DOTlist to present DOTsources, it looks like MY bullseye-updates is now covered by that bullseye-security reference. That sounds familiar'ish. FOR ME, this layout/feature/technique didn't work pre-Bullseye. Without exiting, rebooting, digging through other... suites.. yada, I don't know if this is a new perk for Bullseye or needs tweaked differently for past suites. The fail I experienced might boil down to that necessary bullseye-security v. bullseye-updates change. Maybe that does NOT apply to previous suites.. or something? My CHOICE to have "Components: main contrib non-free" for bullseye-security "suite" is to cover my computer's... hm... just in case I accidentally/incidentally install something not from main at some point.. Whoever put this whole sources.sources take on this together, I LOVE IT! Its layout is easier on my brain for comprehending it as a whole those rare times I might need to change something. Very snazzy! PS Easier ONCE you figure out its methodology, that is. :) PPS "#" comments didn't work for me previously. Just did a test drive, and they're working fine now. FABULOUS because comments are handy for e.g. having quick references to favorite repositories that aren't being used at the moment. PPPS Any outside 3rd party type packages that have been given permission to set up their own DOTlist files... will potentially complain that they can't find something or other yada. They're talking about how you may or may not now (?) have to delete DOTlist files for this TRICK (i.e. RADICAL.. COOL..) feature to work correctly. Their data can be worked right into that same lineup within that same single sources.sources file. Example: Types: deb URIs: https://deb.opera.com/opera-stable/ Suites: stable Components: non-free CAVEAT: You MIGHT or MIGHT NOT still have to work through granting them permission via something like that curl/apt-key step. MAYBE. Time and case-by-case usage will tell.. PS to that as I look at that block: IF you use Bullseye non-free, that right there could possibly be combined into the same single block with your Bullseye data. I only use Bullseye main so that won't work for my own usage case. Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
Re: USB controller resets when burning CD
deloptes wrote: Unfortunately, trying different USB ports does not make any difference, as all my external USB ports belong to the same controller. Would like to try your other suggestion, unloading xhci_hcd and let the system fall back to ehci_hcd. How do I do that? I tried blacklisting xhci_hcd, following the instructions in the Debian Kernel Manual Chapter 6. When I rebooted, xhci_hcd loaded anyhow. sudo rmmod xhci_hcd ? Unfortunately, it is not that simple. The initial challenge is rmmod refuses to remove xhci_hcd, saying it is already in use. I figured out that challenge. First you have to remove xhci_pci, then it will let you remove xhci_hcd. The bigger challenge is, removing the xhci modules leaves all the external USB ports disabled. I was hoping the system would fall back to using ehci_hcd for those ports, but no such luck. Maybe I need to reinitialize something?
