Re: official list of alternatives?
On 2021-02-14 01:57 +0300, IL Ka wrote: > Hello. > > There is a list of alternatives in ``sensible-browser`` including > ``www-browser``, ``x-www-browser`` etc. > > This makes me think that all alternatives must be documented somewhere in > debian policy. What makes you think so? Many alternatives have only two or three implementations, sometimes from the same source package. > Something like "each developer of X-based browser must register it as > x-www-browser alternative". > > However, I haven't found anything except "pager" and "editor" (section 11) > Do I miss something? At least x-terminal-emulator and x-window-manager are also mentioned. But there are many others, on my system alone over 100: , | $ ls /var/lib/dpkg/alternatives | wc -l | 122 ` Obviously it would not be practical to document them all in the policy. Cheers, Sven
Re: btrfs?
I used it on a system I intended to be sort of a NAS with a pair of 1 TB spinning drives. Then one drive started to make funny noises so I moved on from that idea. What I like about BTRFS is being able to use it in a RAID type fashion and the subvolume capability so it isn't a show stopper if, say, tmp was allocated 5 GB on an EXT4 system and suddenly a large compile needs more tmp space or some such. Now the only thing running it here is a Freedombox that is running on a micro-SD card and the image came formatted with BTRFS. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
official list of alternatives?
Hello. There is a list of alternatives in ``sensible-browser`` including ``www-browser``, ``x-www-browser`` etc. This makes me think that all alternatives must be documented somewhere in debian policy. Something like "each developer of X-based browser must register it as x-www-browser alternative". However, I haven't found anything except "pager" and "editor" (section 11) Do I miss something? Thank you. Ilya.
Re: btrfs?
On 2021-02-13 13:13, Steve Mynott wrote: Is anyone running btrfs (either on bullseye or buster)? I've been running on U20.04 and the stability seems fine and I wondered if my experience was typical? I ran several Stretch machines with btrfs. One was my daily driver. I never did any maintenance. After a year or so, the daily driver started slowing down, and Thunderbird starting losing e-mail messages when I tried to save them to my local disk (!). I ran 'btrfs balance ...' repeatedly via a script and was able to get some improvements, but the desktop was too far gone. I wiped and reinstalled with ext4 on all of the machines. It looks like there is a daemon for Buster and newer that can do periodic maintenance for btrfs. You might want to check that out: https://wiki.debian.org/Btrfs#Maintenance David
Missing memory and the mystery of MTRRs
[This would probably be an FAQ if I knew the proper incantation...] I realized recently that a box I've been running for a while isn't seeing all of its installed memory. The BIOS screens indicate that 8GB is installed, but Debian (recently upgraded to Buster) only sees a bit over 3GB. cjg@dragon:~$ head -1 /proc/meminfo MemTotal:3331096 kB During boot I noticed the following message: [0.012080] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 4800MB of RAM. So I guess it's time to start learning about the wonderful world of MTRRs. cjg@dragon:~$ cat /proc/mtrr reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back reg01: base=0x08000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x0c000 ( 3072MB), size= 256MB, count=1: write-back reg03: base=0x0cff0 ( 3327MB), size=1MB, count=1: uncachable cjg@dragon:~$ head -9 /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping: 2 microcode : 0x56 cpu MHz : 1598.388 cache size : 2048 KB Here's the first part of /var/log/messages: [0.00] Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-amd64 root=UUID=4d3143dd-d732-4755-b832-05753ab9c53a ro quiet [0.00] x86/fpu: x87 FPU will use FXSAVE [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0008efff] usable [0.00] BIOS-e820: [mem 0x0008f000-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xcfd60fff] usable [0.00] BIOS-e820: [mem 0xcfd61000-0xcfd6dfff] reserved [0.00] BIOS-e820: [mem 0xcfd6e000-0xcfe1efff] usable [0.00] BIOS-e820: [mem 0xcfe1f000-0xcfee8fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcfee9000-0xcfeecfff] usable [0.00] BIOS-e820: [mem 0xcfeed000-0xcfef1fff] ACPI data [0.00] BIOS-e820: [mem 0xcfef2000-0xcfef2fff] usable [0.00] BIOS-e820: [mem 0xcfef3000-0xcfefefff] ACPI data [0.00] BIOS-e820: [mem 0xcfeff000-0xcfef] usable [0.00] BIOS-e820: [mem 0xcff0-0xcfff] reserved [0.00] BIOS-e820: [mem 0xfff0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00022bff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.4 present. [0.00] DMI: /DG965WH, BIOS MQ96510J.86A.1687.2007.0510.0258 05/10/2007 [0.00] tsc: Fast TSC calibration using PIT [0.00] tsc: Detected 1864.782 MHz processor [0.02] e820: update [mem 0x-0x0fff] usable ==> reserved [0.05] e820: remove [mem 0x000a-0x000f] usable [0.011126] last_pfn = 0x22c000 max_arch_pfn = 0x4 [0.011134] MTRR default type: uncachable [0.011135] MTRR fixed ranges enabled: [0.011137] 0-9 write-back [0.011139] A-F uncachable [0.011140] MTRR variable ranges enabled: [0.011142] 0 base 0 mask F8000 write-back [0.011144] 1 base 08000 mask FC000 write-back [0.011145] 2 base 0C000 mask FF000 write-back [0.011147] 3 base 0CFF0 mask 0 uncachable [0.011148] 4 disabled [0.011149] 5 disabled [0.011149] 6 disabled [0.011150] 7 disabled [0.011968] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.012074] e820: update [mem 0xcff0-0x22bff] usable ==> reserved [0.012080] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 4800MB of RAM. Is there some sort of HOWTO that covers this stuff? Where do I go from here? -- cgi...@surfnaked.ca (Charlie Gibbs)
Re: btrfs?
On Sat, Feb 13, 2021 at 1:20 PM Steve Mynott wrote: > Is anyone running btrfs (either on bullseye or buster)? > I am using it on a laptop running buster with encryption and lvm. It seems to be working fine. I haven't really checked anything, though.
btrfs?
Is anyone running btrfs (either on bullseye or buster)? I've been running on U20.04 and the stability seems fine and I wondered if my experience was typical?
Re: chromecast: no audio when casting screen, works with tab
I have just find a posible solution https://www.linuxuprising.com/2020/04/how-to-cast-your-gnome-shell-desktop-to.html?m=1 I will test it in unstable Regards El jue., 17 dic. 2020 10:19, Andrea Borgia escribió: > > Il giorno gio 17 dic 2020 alle ore 07:12 Javier Barroso < > javibarr...@gmail.com> ha scritto: > >> >> It is a known issue , see >> >> https://support.google.com/chromecast/thread/27045993?hl=en >> > > Great find, thanks for the quick response too :) > > >
Re: rsync to NAS for backup
On 2021-02-13 01:27, mick crane wrote: I made a mistake and instead of getting a PC for backup I got a NAS. I'm struggling to get to grips with it. If rsync from PC to NAS NAS changes the owner/group of files to me/users which is probably no good for backing up. There's that problem then another that it won't let me login as root. I asked on Synology forum but not getting a lot of joy. https://community.synology.com/enu/forum/1/post/141137 Anybody used these things can advise ? What is the model of the Synology NAS? What options -- CPU, memory, disks, bays, interfaces, PSU, whatever? Support page URL? Reading the forum post, it sounds like you damaged the sudoers file. The fix would appear to be doing a Mode 2 reset per Synology's instructions: https://www.synology.com/en-global/knowledgebase/DSM/tutorial/General_Setup/How_to_reset_my_Synology_NAS Once the NAS has been reset, figure out how to meet your needs within the framework provided by Synology. Follow the User Guide. Follow the Admin Guide. Do not mess around "under the hood" with a terminal and sudo. Make Synology earn your money. But if you want complete control, buy or build an x86_64/amd64 server, install Debian, and have at it. David
Re: Rebuilding Debian Live gnome image fails
On 13-Feb-21 06:06, John Crawley wrote:
On 12/02/2021 17:16, Matthijs wrote:
On 12-02-2021 03:12, John Crawley wrote:
On 09/02/2021 21:40, Matthijs wrote:
Following the Debian Live manual on using a predefined
configuration(https://live-team.pages.debian.net/live-manual/html/live-manual/managing-a-configuration.en.html#333):
$ mkdir live-images && cd live-images
$ lb config --config
https://salsa.debian.org/live-team/live-images.git::debian
$ cd images/standard
$ sudo lb build
...this works and I get an ISO image in that directory.
But, instead doing this:
$ mkdir live-images && cd live-images
$ lb config --config
https://salsa.debian.org/live-team/live-images.git::debian
$ cd images/gnome-desktop
$ sudo lb build
(note the change in the 'cd' command)
...this does NOT work. The build command starts doing a lot of
work, fetching & installing stuff, but then simply stops at this
point (copy/paste of ~17 lines of build.log):
It's not mentioned in those docs, but I'm pretty sure you'll need to
run 'lb config' one more time after moving to the config directory
(and possibly editing the files inside), before 'lb build'.
Interesting. I've tried it, but it doesn't make much of a difference
- stops at roughly the same point (well, I get two lines extra, but
not much information from that).
I did manage to trace the root cause back to lines 75/76 in
/usr/lib/live/build/chroot_package-lists:
Expand_packagelist "$(basename ${LIST})" "config/package-lists" \
| grep -v '^#' >> chroot/root/packages.chroot
It seems that at some point, with the config I'm using,
"Expand_packagelist" does not return anything and the script then
simply stops. When I replace it with:
My_list=$(Expand_packagelist "$(basename ${LIST})"
"config/package-lists")
echo ${My_list} | grep -v '^#' >> chroot/root/packages.chroot
...the build continues and delivers a bootable image. So, my issue
seems to be solved with that, or at least I have a workaround.
Perhaps I'll dive a bit further, because right now I don't fully
understand why the build would stop originally: I would expect, if
"expand_packagelist" doesn't return anything, that the following
"grep" would hang indefinitely.
This might be the issue that was fixed with a commit on Jan. 12th:
https://salsa.debian.org/live-team/live-build/-/commit/f13273368a16df271e4317d413d9da564f541dea
You could try that fix of appending '|| true' to the line.
That's exactly the same issue! And indeed that fix works as well. Hmmm,
I looked through the bug report on packages.debian.org, but didn't think
to look at that page you mentioned. But, good to have it solved. Thanks!
Nevertheless, an additional "lb config" doesn't seem to be necessary,
as the modified chrot_package-list script works correctly with the
original procedure.
You're right in this case, because auto/config holds exactly the same
configuration for all the desktop versions. I still think, however,
that if you edited auto/config inside the gnome (or whatever)
directory, that you'd have to run 'lb config' inside the directory to
pick the changes up.
Might be. I'll keep it in mind. For now, I'm just playing with the
possibilities, trying to get a squashfs-content as much as possible
equal to the official Debian release, then make sure I can reproduce it
in a scripted way. Then the fun start, to make the small changes that I
need in my personalized version.
--
Matthijs
Re: How automatic are backport package updates?
On Sb, 13 feb 21, 11:57:42, Michael Grant wrote: > > I was not thinking this would cause more (or significantly more > anyway) work than we already do. Dot releases are tested. It might > even be *less* work as upgrades would be incremental and smaller > rather than large. https://wiki.debian.org/ReleaseProposals Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: How automatic are backport package updates?
On Sb, 13 feb 21, 11:31:16, songbird wrote: > > to me the freeze should just be a snapshot that is > worked from off to the side and then unstable can > continue to be worked on and security fixes and such > can keep working through to testing. This can already be done, e.g. by uploading to 'testing-proposed-updates' instead. The problem with this is that packages fixing bugs in testing will see less testing than packages in unstable, which is why the Release Team requests all updates to go via unstable instead and uses testing-proposed-updates only as a last resort. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: How automatic are backport package updates?
On Sat, Feb 13, 2021 at 06:58:36PM +0200, Andrei POPESCU wrote: > On Sb, 13 feb 21, 10:47:41, Michael Grant wrote: > > > > I completely understand the desire for stability and reliability. But > > it seems like having to wait up to 2 years for some major new feature > > to get into Debian can be daunting, especially when it gets into > > Testing. I was wondering, is there, or has anyone given any thought > > to something in between Testing+Backports and Stable+Security that is > > something like Stable at each dot release, thus reducing this window > > down to 3 months as opposed to 2 years? > > Yes, it's called Ubuntu ;) I see I made an error in my paragraph above. I meant to say something in between Testing+Security and Stable+Backports+Security (though as has been said, you can't apply Security patches to Testing.) Huh, I did not know that this is what Ubuntu was based on. I always thought the 6-month releases were based on the dot releases of Debian. Maybe I should consider moving to Ubuntu Server? Hmm, that sounds like a nightmare waiting to happen. Michael Grant signature.asc Description: PGP signature
Re: How automatic are backport package updates?
On Sb, 13 feb 21, 11:57:42, Michael Grant wrote: > On Sat, Feb 13, 2021 at 11:31:16AM -0500, songbird wrote: > > yes, but since Debian is run by volunteers and many of > > them are very busy it has been talked about but not beyond > > that. the idea of rolling releases, always releasable, and > > some other phrases has been discussed, but until enough > > people get together to actually do it and prove that it > > works and will be supported it won't happen. unstable is > > perhaps the closest currently coming to that idea, but > > the freeze process pushes development off into experimental > > or upstream until the freeze is done and then the whole > > cycle comes up again. > > I understood that Unstable == Sid from Andrew's detailed message in > this thread and it's also on confirmed on this page: > https://wiki.debian.org/DebianUnstable. > > I was not thinking this would cause more (or significantly more > anyway) work than we already do. Dot releases are tested. It might > even be *less* work as upgrades would be incremental and smaller > rather than large. > > Thinking back, this is one of the beauties of Testing is that things > happen incrementally over time. Sure, I may have to fix something > here and there but that often turns out to be easier and less > stressful than doing a major upgrade and having to set aside an entire > weekend. It depends a lot on your particular setup. Many users appreciate the non-changing of stable and often go on using a particular release even beyond it's EOL (against all advice). Ubuntu started out with timed releases every 6 months (based on Debian sid), but later introduced the LTS. Clearly there is demand for both approaches. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: How automatic are backport package updates?
On Sb, 13 feb 21, 10:47:41, Michael Grant wrote: > > I completely understand the desire for stability and reliability. But > it seems like having to wait up to 2 years for some major new feature > to get into Debian can be daunting, especially when it gets into > Testing. I was wondering, is there, or has anyone given any thought > to something in between Testing+Backports and Stable+Security that is > something like Stable at each dot release, thus reducing this window > down to 3 months as opposed to 2 years? Yes, it's called Ubuntu ;) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: How automatic are backport package updates?
On Sat, Feb 13, 2021 at 11:31:16AM -0500, songbird wrote: > yes, but since Debian is run by volunteers and many of > them are very busy it has been talked about but not beyond > that. the idea of rolling releases, always releasable, and > some other phrases has been discussed, but until enough > people get together to actually do it and prove that it > works and will be supported it won't happen. unstable is > perhaps the closest currently coming to that idea, but > the freeze process pushes development off into experimental > or upstream until the freeze is done and then the whole > cycle comes up again. I understood that Unstable == Sid from Andrew's detailed message in this thread and it's also on confirmed on this page: https://wiki.debian.org/DebianUnstable. I was not thinking this would cause more (or significantly more anyway) work than we already do. Dot releases are tested. It might even be *less* work as upgrades would be incremental and smaller rather than large. Thinking back, this is one of the beauties of Testing is that things happen incrementally over time. Sure, I may have to fix something here and there but that often turns out to be easier and less stressful than doing a major upgrade and having to set aside an entire weekend. Michael Grant signature.asc Description: PGP signature
Re: How automatic are backport package updates?
Michael Grant wrote: ... > I completely understand the desire for stability and reliability. But > it seems like having to wait up to 2 years for some major new feature > to get into Debian can be daunting, especially when it gets into > Testing. I was wondering, is there, or has anyone given any thought > to something in between Testing+Backports and Stable+Security that is > something like Stable at each dot release, thus reducing this window > down to 3 months as opposed to 2 years? yes, but since Debian is run by volunteers and many of them are very busy it has been talked about but not beyond that. the idea of rolling releases, always releasable, and some other phrases has been discussed, but until enough people get together to actually do it and prove that it works and will be supported it won't happen. unstable is perhaps the closest currently coming to that idea, but the freeze process pushes development off into experimental or upstream until the freeze is done and then the whole cycle comes up again. to me the freeze should just be a snapshot that is worked from off to the side and then unstable can continue to be worked on and security fixes and such can keep working through to testing. i suggest the acronym tasty for that snapshot (as in tasty-freeze :) - you can use the other concepts of soft-serve or hard-freeze and such to go along and if you want more scoops or sprinkles added, etc.). :) songbird
Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye
Op 13-02-2021 om 14:56 schreef songbird: Frank wrote: Op 12-02-2021 om 22:18 schreef Gary Dale: ... I can do the same with Dolphin but I find it clumsy. FileZIlla is made to let you transfer files between local and remote directories. That's exactly what I do with caja, either from one tab to the other or between separate windows. I'm not sure what's supposed to be clumsy about it. probably the part about the remote machine not being accessible to casual logging in or browsing. at least for my own purposes there's no other method to get to that machine unless i want to use a horrible web interface. Ok. My setup, using bookmarks and login data in the keyring, allows me to browse any of my remotes after two mouse clicks: one to open the bookmark list and one to select the site. when i transfer files back and forth for the website i'm not always using direct copies and only in one direction being important. if i make a change on the website end and don't want my next batch of transferred files to clobber it FileZilla has the options for not having that happen. in a batch of 1500 files with many subdirectories that isn't possible with a simple copy from one tab to another. Right. That makes sense. I hardly ever want what's on a site and the local copy to differ, so for me copying between tabs/windows is fine. Regards, Frank
Re: How automatic are backport package updates?
On Sat, Feb 13, 2021 at 02:32:56PM +, Andrew M.A. Cater wrote: > The below is my opinion: it is informed by watching other folk have problems > over the years. > > TLDR; - If you are running a production system - run Debian's latest stable > release. Stable > gets security support and backported fixes for security issues. > > Release overview: > > > Debian releases trickle down over a period of years: Unstable (code name Sid) > -> Testing -> Stable. > [There is also an Experimental repository - but I'll leave that out for the > sake of brevity]. > > Fictious example: Take the case of a brand new package Foo which, we'll say, > is a personal productivity > app. and updates regularly but on a fairly long timescale. > > Debian unstable == codename "Sid" > - > > If package foo is introduced today, it will go into Sid in source code form > and be built there. Sid is never > expected to be released in this form and receives no formal security or other > support. If you run Sid, you're > expected to be experienced enough to fix any problems yourself. Major > upgrades of something like a desktop > environmnent can sit in Sid for many months until all the components are > ready and all dependencies are > sorted out. Package churn can be severe and unpredictable. > > After a short while with no major problems, and a minimal amount of testing, > package foo can pass to Testing. > > Debian testing == codename "Bullseye" == Debian 11 when released. > > > "Testing" is preparation for the next large scale release of Debian.Testing > effectively collects packages for > a couple of years until a freeze period and eventual release. [Debian 11 > (code name Bullseye) - is at that > stage at the moment: the freeze period has started relatively recently - it > may be released in June 2021 or > so following further freeze stages, all other things being equal.] > > At this point, package foo will not go into current stable: it will only be > prepared for the NEXT release of > Debian months or years away. > > There is a backports repository. This is a way to run a small number of > packages from Debian testing on a > stable system. This might, for example, be an updated kernel because 5.10.x > runs on your brand new hardware > whereas 4.19.x won't run the hardware correctly. These packages are built > against the versions of the packages > in Debian stable (otherwise they won't run there) but provide new/different > versions to those supported in stable. > No security support as such - if you're running backports, you are very much > on your own / out as an edge case > > If enough users of Debian stable really wanted package foo, it could, > conceivably be put here into the backports > repository, but if it wasn't originally released as part of stable, you can't > readily slipstream something straight > into Stable.. > > Package version numbers: > --- > > Very well established packages might have the same or subtly different > versions from Sid all the way down to stable. > It could be that there's version 4.x newly released in Sid, 3.x in Testing > and 2.x in Stable for example with the > different versions reflecting different codebases. > > Stable release == Debian 10 (Buster) as at 20200213 > == > > As of today: Debian's latest stable release is Debian 10 - codename Buster - > and the point release is Debian 10.8 (released on > February 8th, 2021). In due course, there will likely be a 10.9 - updates > which roll up security updates / changes etc. occur > approximately every three months. > > If you run a stable system, and keep it regularly updated, then the point > releases will be very small changes as they occur. > > "Frankendebian" > --- > > You shouldn't cherry pick between releases because that leads to instability. > Likewise "I'll just pull XYZ from Ubuntu and > expect it to work on Debian X" will occasionallly work but more often than > not produce impossible problems fo dependency > and version instability which require significant unpicking. > > All best, as ever, > > Andy C. Thanks Andy, Tixy, Andrei, Dan and others who have chimed in on this. You all have convinced me to move to stable+backports. One comment though, in the 10+ years of running Debian Testing, I have to say that Testing is actually very reliable, way more reliable than it's name implies! I initially moved to Testing because there were some packages that I needed which were not in Backports and were regularlly maintained in Testing. I'm afraid I don't recall which packages anymore, I think it might have been Sendmail. Back then I thought (perhaps mistakenly) that Testing was getting security fixes. Let me add to your recommendations above: For the packages in Testing which don't make it into Backports, one can first try
Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye
Frank wrote: > Op 12-02-2021 om 22:18 schreef Gary Dale: ... >> I can do the same with Dolphin but I find it clumsy. FileZIlla is made >> to let you transfer files between local and remote directories. >> > That's exactly what I do with caja, either from one tab to the other or > between separate windows. I'm not sure what's supposed to be clumsy > about it. probably the part about the remote machine not being accessible to casual logging in or browsing. at least for my own purposes there's no other method to get to that machine unless i want to use a horrible web interface. when i transfer files back and forth for the website i'm not always using direct copies and only in one direction being important. if i make a change on the website end and don't want my next batch of transferred files to clobber it FileZilla has the options for not having that happen. in a batch of 1500 files with many subdirectories that isn't possible with a simple copy from one tab to another. songbird
Re: How automatic are backport package updates?
On Fri, Feb 12, 2021 at 12:05:44PM -0500, Michael Grant wrote: > Replying to this message that's just over a month old now. Now that > 10.8 just came out, is this a good time to jump off the testing repo > and onto stable for my production box? Is this one of those rare > moments when testing and stable line up? Or should I continue to wait > for Bullseye? > The below is my opinion: it is informed by watching other folk have problems over the years. TLDR; - If you are running a production system - run Debian's latest stable release. Stable gets security support and backported fixes for security issues. Release overview: Debian releases trickle down over a period of years: Unstable (code name Sid) -> Testing -> Stable. [There is also an Experimental repository - but I'll leave that out for the sake of brevity]. Fictious example: Take the case of a brand new package Foo which, we'll say, is a personal productivity app. and updates regularly but on a fairly long timescale. Debian unstable == codename "Sid" - If package foo is introduced today, it will go into Sid in source code form and be built there. Sid is never expected to be released in this form and receives no formal security or other support. If you run Sid, you're expected to be experienced enough to fix any problems yourself. Major upgrades of something like a desktop environmnent can sit in Sid for many months until all the components are ready and all dependencies are sorted out. Package churn can be severe and unpredictable. After a short while with no major problems, and a minimal amount of testing, package foo can pass to Testing. Debian testing == codename "Bullseye" == Debian 11 when released. "Testing" is preparation for the next large scale release of Debian.Testing effectively collects packages for a couple of years until a freeze period and eventual release. [Debian 11 (code name Bullseye) - is at that stage at the moment: the freeze period has started relatively recently - it may be released in June 2021 or so following further freeze stages, all other things being equal.] At this point, package foo will not go into current stable: it will only be prepared for the NEXT release of Debian months or years away. There is a backports repository. This is a way to run a small number of packages from Debian testing on a stable system. This might, for example, be an updated kernel because 5.10.x runs on your brand new hardware whereas 4.19.x won't run the hardware correctly. These packages are built against the versions of the packages in Debian stable (otherwise they won't run there) but provide new/different versions to those supported in stable. No security support as such - if you're running backports, you are very much on your own / out as an edge case If enough users of Debian stable really wanted package foo, it could, conceivably be put here into the backports repository, but if it wasn't originally released as part of stable, you can't readily slipstream something straight into Stable.. Package version numbers: --- Very well established packages might have the same or subtly different versions from Sid all the way down to stable. It could be that there's version 4.x newly released in Sid, 3.x in Testing and 2.x in Stable for example with the different versions reflecting different codebases. Stable release == Debian 10 (Buster) as at 20200213 == As of today: Debian's latest stable release is Debian 10 - codename Buster - and the point release is Debian 10.8 (released on February 8th, 2021). In due course, there will likely be a 10.9 - updates which roll up security updates / changes etc. occur approximately every three months. If you run a stable system, and keep it regularly updated, then the point releases will be very small changes as they occur. "Frankendebian" --- You shouldn't cherry pick between releases because that leads to instability. Likewise "I'll just pull XYZ from Ubuntu and expect it to work on Debian X" will occasionallly work but more often than not produce impossible problems fo dependency and version instability which require significant unpicking. All best, as ever, Andy C. > On Tue, Jan 12, 2021 at 10:35:05AM -0500, Dan Ritter wrote: > > Michael Grant wrote: > > >> Let's say I want to run 'testing' to be more on the edge to get the > >> latest and greatest of packages and to incrementally always be on top > >> of updates rather than having to do large release updates. But from > >> time to time there is a security update to a package which is newer, > >> or if something specific is broken, I may want to go back to a > >> specific version of something. What should I put in my sources.list? > > > > Are you running a production system? > > Yes. > > > That is, are you running a Debian system
Re: Tora 3 for Bullsey?
Harald Dunkel wrote: > Hi folks, > > how comes there is not Tora for Bullseye? it doesn't look like it is being very actively worked on and the package didn't get enough support from a Debian Developer or Maintainer to continue so it was removed. it is in stable, if someone wanted to get it back into unstable in the future they'd have to work on it and upload it. right now with a freeze you'd have to probably put it in experimental (along with any dependencies needed that aren't already available elsewhere). songbird
Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye
Andrei POPESCU wrote: ... > Debian doesn't support downgrading of packages. > > When dpkg installs another version of a package (typically newer) it=20 > basically overwrites the existing version and runs the corresponding=20 > package scripts from the to be installed version. > > A newer package may introduce changes that the older package (scripts)=20 > can't deal with. In practice it does work in many cases, except for=20 > those where it doesn't. Fixing them would require a time machine ;) > > A roll-back, especially if automatic, could introduce more issues than=20 > it fixes. > > Someone(tm) has to determine on a case by case basis whether rolling=20 > back makes sense and the system administrator is in the best position to=20 > do so. > > In theory the package Maintainer could provide a general "hint" that=20 > system administrators could chose to ignore (at their own risk). > > Currently the infrastructure for this doesn't exist[1] and, besides, I'd=20 > rather have Maintainers focus on fixing the newer package instead. > > > Volunteer time is precious! > > > [1] it would need support in the Debian archive software and APT at a=20 > minimum. > > Besides, there is already an arguably safer (though hackish) way to=20 > achieve that by uploading a package with version+really.the.old.version=20 > instead. > > In this case the Maintainer can also take care to adjust the package=20 > scripts accordingly. at one time i was thinking that i could put my entire system on git, and then i found out that git didn't like it if you had subdirectories with git in them so that was as far as i got with that idea. a rolling snap shot of the entire system should let you revert changes, but somehow you would need to figure out the differences you'd want to keep from those you didn't. since that can be a non-trivial task for many people that is probably why not many people do it. i installed timekeeper (i think it was) to try that out and after a few days decided that it took up too much space for what i really wanted and needed so i went back to my previous method (a once in a while full back up and other select backups) and the various safer booting options (including from a USB stick) with a stable version of Debian on them. songbird
Re: Tora 3 for Bullsey?
Harald Dunkel wrote: > how comes there is not Tora for Bullseye? It was removed from Sid and Testing in 2019 because it was not compatible with Qt5 and only available for Qt4 and was not reuploaded ever since: https://tracker.debian.org/pkg/tora https://tracker.debian.org/news/1057870/removed-213-4-from-unstable/ Grüße, Sven. -- Sigmentation fault. Core dumped.
Tora 3 for Bullsey?
Hi folks, how comes there is not Tora for Bullseye? Regards Harri
Re: rsync to NAS for backup
On Sat, 13 Feb 2021 09:27:54 + mick crane wrote: > I made a mistake and instead of getting a PC for backup I got a NAS. > I'm struggling to get to grips with it. > If rsync from PC to NAS NAS changes the owner/group of files to > me/users which is probably no good for backing up. Can you set up a network file system such as NFS on the NAS, then tar your data to the NAS? Can you install a backup server such as amanda on the NAS? -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: rsync to NAS for backup
Is there an alternative if you want an incremental backup? Obviously you could use tar-ed archives with unprivileged permissions. If you did, you would get a huge network overhead. thks Toni Mas GPG 3F42A21D84D7E950 Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ En dissabte 13 de febrer de 2021 a les 13:50, didier gaumet va escriure: > Hello, > > Disclaimer: I do not use and am not familiar with Sinology hardware and > software and generally speaking, I am not knowledgeable in networking > > I would say that: > > - the owner:group names of a file on the PC you backup and the > owner:group names of the backup files on the synology files might be > different, even if you try to maintain ownership and rights. What really > counts here are owner:group identifiers (UID:GID). Bob_user:Bob_group on > your PC might equate to Alice_user:John_group on your NAS. Upon > restoration that would be reversed to Bob_user:Bob_group. > That would be typical without something like a LDAP server. > > - SSH root login seems to be discouraged for security reasons. Sinology > probably adhere to this principle and the appropriate way to do what you > want would probably be to access a shell on the Synology software to > issue a sudo or su -c command. > > - editing /etc/sudoers is generally done via the visudo command > - if that is of interest to you, there is a way to install Debian in > chroot on your NAS > signature.asc Description: OpenPGP digital signature
Re: rsync to NAS for backup
Hello, Disclaimer: I do not use and am not familiar with Sinology hardware and software and generally speaking, I am not knowledgeable in networking I would say that: - the owner:group names of a file on the PC you backup and the owner:group names of the backup files on the synology files might be different, even if you try to maintain ownership and rights. What really counts here are owner:group identifiers (UID:GID). Bob_user:Bob_group on your PC might equate to Alice_user:John_group on your NAS. Upon restoration that would be reversed to Bob_user:Bob_group. That would be typical without something like a LDAP server. - SSH root login seems to be discouraged for security reasons. Sinology probably adhere to this principle and the appropriate way to do what you want would probably be to access a shell on the Synology software to issue a sudo or su -c command. - editing /etc/sudoers is generally done via the visudo command - if that is of interest to you, there is a way to install Debian in chroot on your NAS
Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye
Op 12-02-2021 om 22:18 schreef Gary Dale: On 2021-02-12 14:12, Frank wrote: Op 12-02-2021 om 18:19 schreef Gary Dale: I appreciate the people doing this, but this is a serious issue. I have to resort to firing up a VM or resorting to the command line on my local server to update my web sites because I can't do it from Testing. What file manager do you use? I stopped using FileZilla for ftps years ago and only use MATE's caja these days. Hasn't stopped working and I keep my (bullseye) system up-to-date, so whatever TLS library caja is using, this bug doesn't affect it. Regards, Frank I can do the same with Dolphin but I find it clumsy. FileZIlla is made to let you transfer files between local and remote directories. That's exactly what I do with caja, either from one tab to the other or between separate windows. I'm not sure what's supposed to be clumsy about it.
rsync to NAS for backup
I made a mistake and instead of getting a PC for backup I got a NAS. I'm struggling to get to grips with it. If rsync from PC to NAS NAS changes the owner/group of files to me/users which is probably no good for backing up. There's that problem then another that it won't let me login as root. I asked on Synology forum but not getting a lot of joy. https://community.synology.com/enu/forum/1/post/141137 Anybody used these things can advise ? mick -- Key ID4BFEBB31
Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye
On Vi, 12 feb 21, 17:00:41, Gary Dale wrote: > > Which is why I think it would be useful to have way to rollback a package > when you can't fix it quickly. That way you aren't asking all the users to > do it themselves and track the bug status individually. When the maintainers > think they have a fix, it can go through the normal process... Debian doesn't support downgrading of packages. When dpkg installs another version of a package (typically newer) it basically overwrites the existing version and runs the corresponding package scripts from the to be installed version. A newer package may introduce changes that the older package (scripts) can't deal with. In practice it does work in many cases, except for those where it doesn't. Fixing them would require a time machine ;) A roll-back, especially if automatic, could introduce more issues than it fixes. Someone(tm) has to determine on a case by case basis whether rolling back makes sense and the system administrator is in the best position to do so. In theory the package Maintainer could provide a general "hint" that system administrators could chose to ignore (at their own risk). Currently the infrastructure for this doesn't exist[1] and, besides, I'd rather have Maintainers focus on fixing the newer package instead. Volunteer time is precious! [1] it would need support in the Debian archive software and APT at a minimum. Besides, there is already an arguably safer (though hackish) way to achieve that by uploading a package with version+really.the.old.version instead. In this case the Maintainer can also take care to adjust the package scripts accordingly. Random example found on my system: $ rmadison fonts-font-awesome fonts-font-awesome | 4.2.0~dfsg-1 | oldoldstable | source, all fonts-font-awesome | 4.7.0~dfsg-1 | oldstable| source, all fonts-font-awesome | 5.0.10+really4.7.0~dfsg-1 | stable | source, all fonts-font-awesome | 5.0.10+really4.7.0~dfsg-4~bpo10+1 | buster-backports | source, all fonts-font-awesome | 5.0.10+really4.7.0~dfsg-4 | testing | source, all fonts-font-awesome | 5.0.10+really4.7.0~dfsg-4 | unstable | source, all Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
