Re: old entries in sources.list?

at's *precisely* why we suggested to people to use the codename as part of the sources.list files. Bearing in mind we expect to release Testing as Trixie/Debian 13 in a couple of months ... If you pin to a codename of "forky" (once trixie releases), you'll get unstable and testin

Re: old entries in sources.list?

le main > > deb-src http://deb.debian.org/ stable main > > Congratulations, you just told people to disable all security updates. > > This entire thread could have been answered by "do what the release > notes tell you to do." There is literally a section in there telling yo

Re: [SOLVED] Re: old entries in sources.list?

On Fri, Jun 20, 2025 at 6:29 PM Andy Smith wrote: > > [...] > > There have even been some arguments that the relatively recent trend of > providing .d directories and support for config fragment inclusion has > been added predominantly by software coming from distribution ecosystems > that lack d

Re: [SOLVED] Re: old entries in sources.list

On Fri 20 Jun 2025 at 12:12:09 (-0400), Jeffrey Walton wrote: > On Fri, Jun 20, 2025 at 11:53 AM Greg Wooledge wrote: > > On Fri, Jun 20, 2025 at 11:40:59 -0400, Jeffrey Walton wrote: > > > On Fri, Jun 20, 2025 at 11:30 AM wrote: > > > > On Fri, Jun 20, 2025 at 11:06:51AM -0400, Jeffrey Walton wro

Re: [SOLVED] Re: old entries in sources.list?

On Fri, Jun 20, 2025 at 12:59 PM songbird wrote: > > Jeffrey Walton wrote: > ... > > Unfortunately, I cannot find a Debian specific article on > > configuration directories. However, Red Hat has "Linux configuration: > > Understanding *.d directories in /etc," > >

Re: old entries in sources.list?

Don't use the word "stable" in sources.list, because it points to a moving target. When a new stable occurs, "stable" will point to the next release, and that is a VERY BAD IDEA. You don't want a surprise partial upgrade to occur. Release upgrades requ

Re: old entries in sources.list?

ou just told people to disable all security updates. This entire thread could have been answered by "do what the release notes tell you to do." There is literally a section in there telling you what sources.list should look like, and everyone is supposed to read the release notes before upg

Re: old entries in sources.list?

ssues with this. * Don't use the word "stable" in sources.list, because it points to a moving target. When a new stable occurs, "stable" will point to the next release, and that is a VERY BAD IDEA. You don't want a surprise partial upgrade to occur. Re

Re: old entries in sources.list?

On 2025-06-20 22:15, 🦓 wrote: Gisteren schreef li...@nodatagrabbing.com: I can't tell you if it is the "best" way to do things, but I have always just deleted the entries associated with the previous release when I upgraded distros. I never have noticed any disadvantages when doing that. if th

Re: old entries in sources.list?

Gisteren schreef li...@nodatagrabbing.com: > I can't tell you if it is the "best" way to do things, but I have always > just deleted the entries associated with the previous release when I > upgraded distros. I never have noticed any disadvantages when doing that. if that is so safe, then i would

Re: [SOLVED] Re: old entries in sources.list?

Hi, On Fri, Jun 20, 2025 at 01:23:13PM -0400, Greg Wooledge wrote: > In the specific case of /etc/ssh/sshd_config.d/, the man page is > pretty explicit: > > Note that the Debian openssh-server package sets several options as stan‐ > dard in /etc/ssh/sshd_config which are not the default

Re: [SOLVED] Re: old entries in sources.list?

On Fri, 20 Jun 2025, The Wanderer wrote: Personally, what I do in response to such a prompt is to have it show me a diff of the two files, and then if the changes involve losing any settings want to retain, I have it give me a shell prompt (or use another shell I have independently) to make a co

Re: [SOLVED] Re: old entries in sources.list?

On Fri, Jun 20, 2025 at 11:30 AM wrote: > > On Fri, Jun 20, 2025 at 11:06:51AM -0400, Jeffrey Walton wrote: > > On Fri, Jun 20, 2025 at 10:37 AM Greg Wooledge wrote: > > > > > > On Fri, Jun 20, 2025 at 10:15:47 -0400, Jeffrey Walton wrote: > > > > SSH config files are located in /etc, too. But ad

Re: [SOLVED] Re: old entries in sources.list

On Fri, Jun 20, 2025 at 08:58:58AM -0500, David Wright wrote: > On Fri 20 Jun 2025 at 08:28:11 (+0200), to...@tuxteam.de wrote: > > On Thu, Jun 19, 2025 at 05:40:24PM -0400, Jeffrey Walton wrote: > > > > [...] > > > > > It might be worth mentioning t

Re: [SOLVED] Re: old entries in sources.list?

On Fri, Jun 20, 2025 at 18:20:37 +0100, Tim Woodall wrote: > On Fri, 20 Jun 2025, The Wanderer wrote: > > > Personally, what I do in response to such a prompt is to have it show me > > a diff of the two files, and then if the changes involve losing any > > settings want to retain, I have it give m

Re: [SOLVED] Re: old entries in sources.list?

On Fri, Jun 20, 2025 at 12:12:09 -0400, Jeffrey Walton wrote: > Unfortunately, I cannot find a Debian specific article on > configuration directories. However, Red Hat has "Linux configuration: > Understanding *.d directories in /etc," >

Re: [SOLVED] Re: old entries in sources.list?

Jeffrey Walton wrote: ... > Unfortunately, I cannot find a Debian specific article on > configuration directories. However, Red Hat has "Linux configuration: > Understanding *.d directories in /etc," >. Now > that we have configuration d

Re: [SOLVED] Re: old entries in sources.list?

On Fri, Jun 20, 2025 at 11:42:53AM -0400, The Wanderer wrote: > On 2025-06-20 at 11:30, to...@tuxteam.de wrote: > > > On Fri, Jun 20, 2025 at 11:06:51AM -0400, Jeffrey Walton wrote: > > >> You will absolutely lose your sshd_config when the package is > >> upgraded and you choose the maintainers v

Re: [SOLVED] Re: old entries in sources.list?

On Fri, Jun 20, 2025 at 11:53 AM Greg Wooledge wrote: > > On Fri, Jun 20, 2025 at 11:40:59 -0400, Jeffrey Walton wrote: > > On Fri, Jun 20, 2025 at 11:30 AM wrote: > > > > > > On Fri, Jun 20, 2025 at 11:06:51AM -0400, Jeffrey Walton wrote: > > > > On Fri, Jun 20, 2025 at 10:37 AM Greg Wooledge

Re: [SOLVED] Re: old entries in sources.list?

On Fri, Jun 20, 2025 at 11:40:59 -0400, Jeffrey Walton wrote: > On Fri, Jun 20, 2025 at 11:30 AM wrote: > > > > On Fri, Jun 20, 2025 at 11:06:51AM -0400, Jeffrey Walton wrote: > > > On Fri, Jun 20, 2025 at 10:37 AM Greg Wooledge wrote: > > > > > > > > On Fri, Jun 20, 2025 at 10:15:47 -0400, Jeffr

Re: [SOLVED] Re: old entries in sources.list?

On 2025-06-20 at 11:30, to...@tuxteam.de wrote: > On Fri, Jun 20, 2025 at 11:06:51AM -0400, Jeffrey Walton wrote: >> You will absolutely lose your sshd_config when the package is >> upgraded and you choose the maintainers version of the file. > > No. > > You will be asked, as for every conffile

Re: [SOLVED] Re: old entries in sources.list?

On Fri, Jun 20, 2025 at 11:06:51AM -0400, Jeffrey Walton wrote: > On Fri, Jun 20, 2025 at 10:37 AM Greg Wooledge wrote: > > > > On Fri, Jun 20, 2025 at 10:15:47 -0400, Jeffrey Walton wrote: > > > SSH config files are located in /etc, too. But admins are expected to > > > make changes to /etc/ssh/s

Re: [SOLVED] Re: old entries in sources.list?

On Fri, Jun 20, 2025 at 10:37 AM Greg Wooledge wrote: > > On Fri, Jun 20, 2025 at 10:15:47 -0400, Jeffrey Walton wrote: > > SSH config files are located in /etc, too. But admins are expected to > > make changes to /etc/ssh/sshd_config.d/, and not /etc/ssh/sshd_config. > > That's definitely false.

Re: [SOLVED] Re: old entries in sources.list?

On Fri, Jun 20, 2025 at 10:15:47 -0400, Jeffrey Walton wrote: > SSH config files are located in /etc, too. But admins are expected to > make changes to /etc/ssh/sshd_config.d/, and not /etc/ssh/sshd_config. That's definitely false.

Re: [SOLVED] Re: old entries in sources.list?

On Fri, Jun 20, 2025 at 2:28 AM wrote: > > On Thu, Jun 19, 2025 at 05:40:24PM -0400, Jeffrey Walton wrote: > > [...] > > > It might be worth mentioning that if the package owns sources.list, > > then you should not edit it. You should allow the package mainta

Re: [SOLVED] Re: old entries in sources.list

On Fri 20 Jun 2025 at 08:28:11 (+0200), to...@tuxteam.de wrote: > On Thu, Jun 19, 2025 at 05:40:24PM -0400, Jeffrey Walton wrote: > > [...] > > > It might be worth mentioning that if the package owns sources.list, > > then you should not edit it. You should allow the p

Re: [SOLVED] Re: old entries in sources.list?

On Thu, Jun 19, 2025 at 05:40:24PM -0400, Jeffrey Walton wrote: [...] > It might be worth mentioning that if the package owns sources.list, > then you should not edit it. You should allow the package maintainer > to edit or replace sources.list. Place your changes in > /etc/apt/so

Re: [SOLVED] Re: old entries in sources.list

On Thu 19 Jun 2025 at 17:40:24 (-0400), Jeffrey Walton wrote: > It might be worth mentioning that if the package owns sources.list, > then you should not edit it. You should allow the package maintainer > to edit or replace sources.list. Place your changes in > /etc/apt/sources.list.

Re: [SOLVED] Re: old entries in sources.list?

It answers all my > questions and worries I had. > > So, "best" way is to remove the old entries and use only trixie-related ones. > > This litle question/issue is fully solved and can safely be closed. > > I am looking forward to trixie and are very excited

Re: [SOLVED] Re: old entries in sources.list?

Andrew M.A. Cater writes: > Use apt / apt-get options for safe upgrade - to upgrade the minimum > set of packages. Log the output of the safe-upgrade command (normally just "apt upgrade") and read the log before giving the next command. > Do an apt-get dist-upgrade / apt full-upgrade And again,

Re: [SOLVED] Re: old entries in sources.list?

the system up to date on the old release - bookworm. READ THE RELEASE NOTES Change the sources.list to the new sources.list for trixie Use apt / apt-get options for safe upgrade - to upgrade the minimum set of packages. Do an apt-get dist-upgrade / apt full-upgrade Reboot to bring up the new

[SOLVED] Re: old entries in sources.list?

> If the packaging system wants to remove a package that came from > oldstable for dependency reasons, having oldstable sources listed > won't change that. > > Some old packages (usually versioned libraries) are kept around forever > and don't cause any problems. They just sit on your hard drive

Re: old entries in sources.list?

On Thu, Jun 19, 2025 at 16:57:11 +0200, Hans wrote: > Which of one I should not do? The advice is only to include sources for the current stable release, and not for any older releases. > I fear, that when deleting any entries of the previous release, it might want > to deinstall packages ("app

Re: old entries in sources.list?

> > Better means, "delete/comment all bookworm entries" or "leave entries > > for bookworm and trixie for a while in parallel"? > > Don't do that, as you might install older packages that aren't in the > current release which give you certain dependency errors. Which of one I should not do? I f

Re: old entries in sources.list?

On 2025-06-19 14:40, Hans wrote: Hi all, I have a simple question, which aways appear with a new debian-version. When a new version is official released (let`s say: from bookworm to trixie), what is best way to edit the sources.list? Better means, "delete/comment all bookworm entrie

old entries in sources.list?

Hi all, I have a simple question, which aways appear with a new debian-version. When a new version is official released (let`s say: from bookworm to trixie), what is best way to edit the sources.list? Better means, "delete/comment all bookworm entries" or "leave entries fo

Re: Feature request: Make deb822 default and deprecate old-style sources.list

that their sources.list is in a spiffy new format so I would expect many people to be uninterested in doing busy work. At least now there's a nag message to "encourage" them to do busy work. :-/

Re: Feature request: Make deb822 default and deprecate old-style sources.list

On 01/05/2025 21:17, Jonathan Dowland wrote: On Thu May 1, 2025 at 7:30 PM BST, Siddh Raman Pant wrote: A big red warning (and not error / failure) will bring a much needed kinetic force for the change IMO, on the same lines as the warning when using the old apt-keys stuff. Hence, I request for

Re: Feature request: Make deb822 default and deprecate old-style sources.list

On Thu May 1, 2025 at 9:17 PM BST, Jonathan Dowland wrote: However, can I point out that the pre-822 format has been around for *27 years*: it's going to take a long time for people who are familiar with it to internalise the new format. Introducing nagging warnings too soon will frustrate peop

Re: Feature request: Make deb822 default and deprecate old-style sources.list

On 2025-05-02, Siddh Raman Pant wrote: > Now that we have deb822 format for specifying APT repo which includes > everything within one file, the user should be discouraged from using > old styles where the GPG key is stored in a "keyring" (whether it be a > trusted keyring or just a folder in anot

Re: Feature request: Make deb822 default and deprecate old-style sources.list

On Thu May 1, 2025 at 7:30 PM BST, Siddh Raman Pant wrote: A big red warning (and not error / failure) will bring a much needed kinetic force for the change IMO, on the same lines as the warning when using the old apt-keys stuff. Hence, I request for making deb822 the default format and deprecat

Re: Feature request: Make deb822 default and deprecate old-style sources.list

Bugs/ Those of us using apt already get a message informing us the there are legacy sources, which in my case is Opera. Even though Opera does have a new-style source declaration, Opera insists on recreating the legacy sources.list with its own entry on each upgrade, which I later delete. I'm

Feature request: Make deb822 default and deprecate old-style sources.list

Hi, Now that we have deb822 format for specifying APT repo which includes everything within one file, the user should be discouraged from using old styles where the GPG key is stored in a "keyring" (whether it be a trusted keyring or just a folder in another place with that name). Far too many pl

Re: testing apt upgrade 2.9.23 to 2.9.26 changes to sources.list

On Thu, 6 Feb 2025 14:51:17 + Joe wrote: > > > On 2/6/25 8:20 AM, Charles Curley wrote: > > > > > > And for those who are wondering, this is going on in trixie. [...] > The quick fix in sources.list for debian is to add signed-by into > existing lin

Re: testing apt upgrade 2.9.23 to 2.9.26 changes to sources.list

On Thu, Feb 06, 2025 at 08:53:49AM -0700, Charles Curley wrote: On Thu, 6 Feb 2025 10:42:27 -0500 Michael Stone wrote: >...except that, per the rest of the discussion in that bug, it almost >certainly won't be able to predict which signer to apply for each >sources.list entr

Re: testing apt upgrade 2.9.23 to 2.9.26 changes to sources.list

Also, there is https://wiki.debian.org/SourcesList . Regards, Jörg.

Re: testing apt upgrade 2.9.23 to 2.9.26 changes to sources.list

Hi, On Thu, Feb 06, 2025 at 08:27:54AM -0500, Dan Ritter wrote: > Charles Curley wrote: > > Another option would be to retain all comments, and let the user > > manually convert commented out entries. Simple, easy to do, and only a > > little obnoxious for the user. > > > > And for those who are

Re: testing apt upgrade 2.9.23 to 2.9.26 changes to sources.list

On Thu, 6 Feb 2025 08:53:49 -0700 Charles Curley wrote: > However, it is not in the man page for apt or apt-get. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1094784 -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/

Re: testing apt upgrade 2.9.23 to 2.9.26 changes to sources.list

On Thu, 6 Feb 2025 15:30:02 + Joe wrote: > Why in the world bother making your own scripts when you can just do > > # apt modernize-sources > The following files need modernizing: > - /etc/apt/sources.list.d/google-chrome-beta.list > - /etc/apt/sources.list.d/google-earth-pro.list > -

Re: testing apt upgrade 2.9.23 to 2.9.26 changes to sources.list

ng through this process the comments in >> sources.list were discarded. > > I think this behaviour is unlikely to change unless you report a bug > about it. there are so many bugs filed against apt that something like this has about zero chance of being noticed or changed. also i just trie

Re: testing apt upgrade 2.9.23 to 2.9.26 changes to sources.list

On Thu, 6 Feb 2025 10:42:27 -0500 Michael Stone wrote: > >...except that, per the rest of the discussion in that bug, it almost > >certainly won't be able to predict which signer to apply for each > >sources.list entry. That you'll probably have to add on your own.

Re: testing apt upgrade 2.9.23 to 2.9.26 changes to sources.list

hich looks like it might be intended to make this type of conversion. ...except that, per the rest of the discussion in that bug, it almost certainly won't be able to predict which signer to apply for each sources.list entry. That you'll probably have to add on your own. It even tells y

Re: testing apt upgrade 2.9.23 to 2.9.26 changes to sources.list

On Thu, 6 Feb 2025 08:09:37 -0700 Charles Curley wrote: > On Thu, 6 Feb 2025 14:51:17 + > Joe wrote: > > > The long-term fix is a file standard.sources root:root 644 in > > /etc/sources.list.d containing: > > Is there anything that tells one how to make this conversion? Better > yet, a s

Re: testing apt upgrade 2.9.23 to 2.9.26 changes to sources.list

o be an 'apt modernize-sources' sub-command, which looks like it might be intended to make this type of conversion. ...except that, per the rest of the discussion in that bug, it almost certainly won't be able to predict which signer to apply for each sources.list entry. That yo

Re: testing apt upgrade 2.9.23 to 2.9.26 changes to sources.list

On Thu, Feb 06, 2025 at 08:09:37AM -0700, Charles Curley wrote: Is there anything that tells one how to make this conversion? Better yet, a script or two to do it for us? There will be a lot of people scrambling to convert at the last minute. Yes, current version prompts on what to do.

Re: testing apt upgrade 2.9.23 to 2.9.26 changes to sources.list

On Thu, 6 Feb 2025 14:51:17 + Joe wrote: > The long-term fix is a file standard.sources root:root 644 in > /etc/sources.list.d containing: Is there anything that tells one how to make this conversion? Better yet, a script or two to do it for us? There will be a lot of people scrambling to co

Re: testing apt upgrade 2.9.23 to 2.9.26 changes to sources.list

rom what I understand you are basically asking > >> for otherwise valid but commented-out sources.list lines to be > >> converted into inactive deb822 files, which seems like a big > >> request. > > > > Another option would be to retain all comments, and le

Re: testing apt upgrade 2.9.23 to 2.9.26 changes to sources.list

hat I understand you are basically asking for otherwise > > > valid but commented-out sources.list lines to be converted into > > > inactive deb822 files, which seems like a big request. > > > > Another option would be to retain all comments, and let the user > >

Re: testing apt upgrade 2.9.23 to 2.9.26 changes to sources.list

On 2/6/25 8:20 AM, Charles Curley wrote: On Thu, 6 Feb 2025 07:53:07 + Andy Smith wrote: Having said that, I am not sure how the complaint could be addressed since from what I understand you are basically asking for otherwise valid but commented-out sources.list lines to be converted

Re: testing apt upgrade 2.9.23 to 2.9.26 changes to sources.list

Charles Curley wrote: > On Thu, 6 Feb 2025 07:53:07 + > Andy Smith wrote: > > > Having said that, I am not sure how the complaint could be addressed > > since from what I understand you are basically asking for otherwise > > valid but commented-out sources.list

Re: testing apt upgrade 2.9.23 to 2.9.26 changes to sources.list

On Thu, 6 Feb 2025 07:53:07 + Andy Smith wrote: > Having said that, I am not sure how the complaint could be addressed > since from what I understand you are basically asking for otherwise > valid but commented-out sources.list lines to be converted into > inactive deb822 files,

Re: testing apt upgrade 2.9.23 to 2.9.26 changes to sources.list

Hi, On Thu, Feb 06, 2025 at 01:51:49AM -0500, songbird wrote: > when doing the upgrade you do have the option of doing > a test run to see what changes are made or not making the > changes at that time. > > when going through this process the comments in > sources.list

testing apt upgrade 2.9.23 to 2.9.26 changes to sources.list

when doing the upgrade you do have the option of doing a test run to see what changes are made or not making the changes at that time. when going through this process the comments in sources.list were discarded. i don't know about other people or what they put in sources.list,

Re: sources.list for Mozilla VPN

Am 09.12.24 um 20:30 schrieb Paul Scott: > I have never been completely clear about the format for sources.list. > > Can someone tell what to add to sources.list to get mozillavpn (sid) Mozilla VPN is based on Mullvad VPN. Mullvad is cheaper and provides Debian packages.

Re: sources.list for Mozilla VPN

Hi, On Tue, Dec 10, 2024 at 11:26:52PM +0100, Jean-François Bachelet wrote: > Le 10/12/2024 à 19:41, Andy Smith a écrit : > > According to: > > > > > > https://support.mozilla.org/en-US/kb/how-install-mozilla-vpn-linux-computer > > > > they only support Ubuntu. > no. > > read at the botto

Re: sources.list for Mozilla VPN

Hello :) Le 10/12/2024 à 19:41, Andy Smith a écrit : Hi, On Mon, Dec 09, 2024 at 12:30:01PM -0700, Paul Scott wrote: Can someone tell what to add to sources.list to get mozillavpn (sid) I think you would be better off asking Mozilla how to install software they make, as this is not

Re: sources.list for Mozilla VPN

On Tue, Dec 10, 2024 at 21:56:32 +0100, Geert Stappers wrote: > I did see "debports" (not "backports") on > https://packages.debian.org/sid/mozillavpn I also see a link to . If I click that, I am taken to a page that says, among other things, Save 50% on Mozilla VP

Re: sources.list for Mozilla VPN

On Tue, Dec 10, 2024 at 01:08:09PM -0700, Paul Scott wrote: > On 12/10/24 11:41 AM, Andy Smith wrote: > > Hi, > > > > On Mon, Dec 09, 2024 at 12:30:01PM -0700, Paul Scott wrote: > > > Can someone tell what to add to sources.list to get mozillavpn (sid) > > I

Re: sources.list for Mozilla VPN

On Tue, Dec 10, 2024 at 01:08:09PM -0700, Paul Scott wrote: > https://packages.debian.org/sid/mozillavpn shows the packages listed > as backports Sid doesn't have backports. What I see at that page is that there are *unofficial* builds of mozillavpn, but only on riscv64 and ia64. What architectur

Re: sources.list for Mozilla VPN

On Tue 10 Dec 2024 at 13:08:09 (-0700), Paul Scott wrote: > https://packages.debian.org/sid/mozillavpn shows the packages listed > as backports I saw those, but they appear to be for rather unusual architectures, and I thought you'd have mentioned that. Cheers, David.

Re: sources.list for Mozilla VPN

Andy, Thank you for your reply. https://packages.debian.org/sid/mozillavpn shows the packages listed as backports Paul On 12/10/24 11:41 AM, Andy Smith wrote: Hi, On Mon, Dec 09, 2024 at 12:30:01PM -0700, Paul Scott wrote: Can someone tell what to add to sources.list to get mozillavpn

Re: sources.list for Mozilla VPN

Hi, On Mon, Dec 09, 2024 at 12:30:01PM -0700, Paul Scott wrote: > Can someone tell what to add to sources.list to get mozillavpn (sid) I think you would be better off asking Mozilla how to install software they make, as this is not packaged by or provided by Debian. According to: ht

sources.list for Mozilla VPN

I have never been completely clear about the format for sources.list. Can someone tell what to add to sources.list to get mozillavpn (sid) TIA, Paul

Re: /etc/apt/sources.list example [WAS Re: medically smart watches]

On 2/25/24 07:14, Andrew M.A. Cater wrote: I have to agree, and pursuing that seems to disclose I do not have the non-frre in my configs. So I'm now asking for help to add it to my /etc/apt/sources *.list stuff. For apt sources.list - have a look at: https://wiki.debian.org/Source

/etc/apt/sources.list example [WAS Re: medically smart watches]

t; > As I see it, is https://wiki.debian.org/BluetoothUser now the best place > > to go. > > > I have to agree, and pursuing that seems to disclose I do not have the > non-frre in my configs. So I'm now asking for help to add it to my > /etc/apt/sources *.list stuf

Re: Apt sources.list

On Thu, Apr 20, 2023 at 12:18:35PM +0200, Vincent Lefevre wrote: > Anyway, in the time of freeze like now (probably with more > users trying testing), isn't it important that testing gets > security updates? It's not really about what's "important", but what's feasible given the available resource

Re: Apt sources.list

se, even for users using unstable: have "stable-security" in apt sources (e.g. /etc/apt/sources.list). Since stable is new, most packages are based on the same version as stable. That way, users can benefit from security updates for stable. > https://wiki.debian.org/DebianTestin

Re: Apt sources.list

no point in > >>> having 'testing-security' lines in sources.list (I guess it'll give an > >>> error anyway). > >> > >> No error. It exists but as a perpetually empty repository. > > > > This is incorrect. > > > > cventin:~&

Re: Apt sources.list

Op 18-04-2023 om 16:33 schreef Vincent Lefevre: On 2023-04-15 21:59:19 +0200, Frank wrote: Op 15-04-2023 om 18:12 schreef Tixy: Testing doesn't get explicit security support so there's no point in having 'testing-security' lines in sources.list (I guess it'll give an

Re: Apt sources.list

en the next release comes, bookworm will still be > > > bookworm, but "testing" will be bookworm "plus". I'd like to follow > > > testing, regardless of the status of Debian official releases. > > > > > > So... in my sources.list, if I ch

Re: Apt sources.list

On Mon, Apr 17, 2023 at 12:45 AM wrote: > > On Sun, Apr 16, 2023 at 09:20:22PM -0400, Jeffrey Walton wrote: > > [...] > > > Corporations don't need browser cooperation for Data Loss Prevention > > > (DLP) (but they already have it). Corporations just run an > > > interception proxy, like NetSkope.

Re: Apt sources.list

On Sun, Apr 16, 2023 at 09:20:22PM -0400, Jeffrey Walton wrote: [...] > > Corporations don't need browser cooperation for Data Loss Prevention > > (DLP) (but they already have it). Corporations just run an > > interception proxy, like NetSkope. The NetScope Root CA is loaded into > > every browse

Re: Apt sources.list

On Sun, Apr 16, 2023 at 4:52 PM Jeffrey Walton wrote: > > On Sun, Apr 16, 2023 at 3:06 PM Tim Woodall wrote: > > > > On Sat, 15 Apr 2023, Greg Wooledge wrote: > > > > > Now, personally I don't feel this is a threat model that I need to > > > worry about. I just use plain old http sources at home

Re: Apt sources.list

On Sun, Apr 16, 2023 at 3:06 PM Tim Woodall wrote: > > On Sat, 15 Apr 2023, Greg Wooledge wrote: > > > Now, personally I don't feel this is a threat model that I need to > > worry about. I just use plain old http sources at home, and if "They" > > learn that I've downloaded rxvt-unicode and mutt,

Re: Apt sources.list

On Sat, 15 Apr 2023, Greg Wooledge wrote: Now, personally I don't feel this is a threat model that I need to worry about. I just use plain old http sources at home, and if "They" learn that I've downloaded rxvt-unicode and mutt, well, good for Them. The thread model I'm most concerned abou

Re: Apt sources.list

Frank writes: > Are you kidding? No way! Unstable is never pushed into testing just > like that. There are packages that will never move to testing at all! That's correct. Immediately after the release Testing and Stable are identical. Unstable is unchanged. When the freeze is lifted packages th

Re: Apt sources.list

On Sun 16 Apr 2023 at 07:14:31 (+0200), Frank wrote: > Op 15-04-2023 om 22:15 schreef Andrew M.A. Cater: > > On Sat, Apr 15, 2023 at 08:14:11PM +0100, Brian wrote: > > > On Sat 15 Apr 2023 at 16:45:40 +, Andrew M.A. Cater wrote: > > > > > > > I would suggest that you remain on bookworm until b

Re: Apt sources.list

Op 16-04-2023 om 13:12 schreef Andrew M.A. Cater: Release day when someone pushes the magic switch and the symlinks move :) [snip] "Testing" == "Previous contents of Unstable" (== Trixie / Debian 13) Are you kidding? No way! Unstable is never pushed into testing just like that. There are p

Re: Apt sources.list

On Sat, 15 Apr 2023 20:30:11 -0400 Jeffrey Walton wrote: > On Sat, Apr 15, 2023 at 11:09 AM wrote: > > On Sat, 15 Apr 2023 14:01:27 +0100 > > Alain D D Williams wrote: > > > On Sat, Apr 15, 2023 at 08:52:06AM -0400, Greg Wooledge wrote: > > > While we are talking about this, is there any reason

Re: Apt sources.list

On 15/04/2023 19:54, davidson wrote: On Sat, 15 Apr 2023 to...@tuxteam.de wrote: On Sat, Apr 15, 2023 at 12:18:57PM -0400, Dan Ritter wrote: It's nice not to be telling everyone who can sniff a plaintext connection which packages you are installing, Without doubt, this is an advantage of a TL

Re: Apt sources.list

On Sun, Apr 16, 2023 at 12:10:33AM -0400, Stefan Monnier wrote: > > On release day, bookworm -> "stable", > > So far so good. > > > "unstable" -> testing == trixie > > Really? I thought there was always a delay for packages to move from > unstable to testing. > Let's try this again because re

Re: Apt sources.list

On Sat, Apr 15, 2023 at 10:54:10PM +, davidson wrote: [...] > What's wrong, Tomas? Don't you want to watch pornographic videos and > conduct your banking with the same application? I'm glad I don't have to use the browser for any of those. Cheers -- t signature.asc Description: PGP signa

Re: Apt sources.list

Op 15-04-2023 om 22:15 schreef Andrew M.A. Cater: On Sat, Apr 15, 2023 at 08:14:11PM +0100, Brian wrote: On Sat 15 Apr 2023 at 16:45:40 +, Andrew M.A. Cater wrote: I would suggest that you remain on bookworm until bookworm is released as stable. At that point (and only then) change bookwor

Re: Apt sources.list

On Sun 16 Apr 2023 at 00:10:33 (-0400), Stefan Monnier wrote: > > On release day, bookworm -> "stable", > > So far so good. > > > "unstable" -> testing == trixie > > Really? I thought there was always a delay for packages to move from > unstable to testing. Well, I suppose it gives the naïve u

Re: Apt sources.list

> On release day, bookworm -> "stable", So far so good. > "unstable" -> testing == trixie Really? I thought there was always a delay for packages to move from unstable to testing. Stefan

Re: Apt sources.list

On Sat, Apr 15, 2023 at 11:09 AM wrote: > On Sat, 15 Apr 2023 14:01:27 +0100 > Alain D D Williams wrote: > > On Sat, Apr 15, 2023 at 08:52:06AM -0400, Greg Wooledge wrote: > > While we are talking about this, is there any reason why all the > > http: should not be https: ? > > > > I have done thi

Re: Apt sources.list

>> Now, personally I don't feel this is a threat model that I need to >> worry about. I just use plain old http sources at home, and if >> "They" learn that I've downloaded rxvt-unicode and mutt, well, good >> for Them. > My understanding is that mandating HTTPS for all connections is supposed >

Re: Apt sources.list

On Sat, 15 Apr 2023 Greg Wooledge wrote: On Sat, Apr 15, 2023 at 10:54:10PM +, davidson wrote: In case you wish to obscure what software you *install*, but need not conceal the software you *download*: Step one: Make a list of the packages you want, and then augment it with as many plausi

Re: Apt sources.list

On 2023-04-15 at 19:11, Greg Wooledge wrote: > On Sat, Apr 15, 2023 at 10:54:10PM +, davidson wrote: > >> In case you wish to obscure what software you *install*, but need >> not conceal the software you *download*: >> >> Step one: Make a list of the packages you want, and then augment >> it

Re: Apt sources.list

On Sat, Apr 15, 2023 at 10:54:10PM +, davidson wrote: > In case you wish to obscure what software you *install*, but need not > conceal the software you *download*: > > Step one: Make a list of the packages you want, and then augment it > with as many plausible alternatives and red herrings

  1   2   3   4   5   6   7   8   9   10   >