Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #220640 > unrolled thread

Unsolvable dependency problems around libc / libcrypt on debian testing/bullseye

Back to article view | Back to linux.debian.user

Contents

  Unsolvable dependency problems around libc / libcrypt on debian testing/bullseye Martin <mb0087@gmail.com> - 2020-03-29 00:00 +0100
    Re: Unsolvable dependency problems around libc / libcrypt on debian  testing/bullseye Andrei POPESCU <andreimpopescu@gmail.com> - 2020-03-29 08:00 +0200
      Re: Unsolvable dependency problems around libc / libcrypt on debian testing/bullseye Martin <mb0087@gmail.com> - 2020-03-29 12:40 +0200
        Re: Unsolvable dependency problems around libc / libcrypt on debian  testing/bullseye Andrei POPESCU <andreimpopescu@gmail.com> - 2020-03-29 13:40 +0200
          Re: Unsolvable dependency problems around libc / libcrypt on debian testing/bullseye Martin <mb0087@gmail.com> - 2020-03-29 16:50 +0200
            Re: Unsolvable dependency problems around libc / libcrypt on debian  testing/bullseye Andrei POPESCU <andreimpopescu@gmail.com> - 2020-03-29 21:00 +0200
              Re: Unsolvable dependency problems around libc / libcrypt on debian testing/bullseye Martin <mb0087@gmail.com> - 2020-03-30 12:50 +0200
                Re: Unsolvable dependency problems around libc / libcrypt on debian  testing/bullseye Andrei POPESCU <andreimpopescu@gmail.com> - 2020-03-30 13:30 +0200
                  Re: [OT] testing on unstable sources list dalios <dalios@eumx.net> - 2020-04-01 14:50 +0200
                    Re: [OT] testing on unstable sources list Andrei POPESCU <andreimpopescu@gmail.com> - 2020-04-01 17:50 +0200
                      Re: [OT] testing on unstable sources list dalios <dalios@eumx.net> - 2020-04-02 09:00 +0200
      Re: Unsolvable dependency problems around libc / libcrypt on debian testing/bullseye Martin <mb0087@gmail.com> - 2020-03-29 12:40 +0200

#220640 — Unsolvable dependency problems around libc / libcrypt on debian testing/bullseye

Dear all,

I have a debian bullseye/testing machine on a 2017 HP i7 machine that
I used daily for many months but was not running since end of November
2019. I upgraded everything with apt update + dist-upgrade +
autoremove + clean this week.
I can't exactly say how but while everything appeared fine initially I
now struggle with having a partially working system. Something with a
very fundamental library seems to have created a unsolvable dependency
situation and I can't get out of it. I think it started with libcrypt1
that was dependency but could not be found.

My question is foremost if I can get out of it myself and how or if it
is due to some package  currently not available (in Incoming as one
error message suggests) and I just have to wait? Maybe my sources list
does not make sense?

apt list --upgradable

Listing... Done
firefox/unstable 74.0-1 amd64 [upgradable from: 69.0.1-1]
libc-bin/testing 2.30-2 amd64 [upgradable from: 2.29-2]
libc6/testing 2.30-2 amd64 [upgradable from: 2.29-2]
libc6/testing 2.30-2 i386 [upgradable from: 2.29-2]
libruby2.5/testing,unstable 2.5.7-1+b1 amd64 [upgradable from: 2.5.7-1]
login/testing,unstable 1:4.8.1-1 amd64 [upgradable from: 1:4.7-2]
passwd/testing,unstable 1:4.8.1-1 amd64 [upgradable from: 1:4.7-2]
whois/testing,unstable 5.5.6 amd64 [upgradable from: 5.5.2]

When I do: sudo apt install whois

The following packages have unmet dependencies:
 whois : Depends: libcrypt1 (>= 1:4.1.0) but it is not installable

sudo apt install locales libc-bin

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:
 libc-bin : Depends: libc6 (> 2.30) but 2.29-2 is to be installed

sudo apt install libc6 libcrypt1
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package libcrypt1 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  libcrypt1:i386

This is my apt sources list:

deb http://deb.debian.org/debian/ testing main non-free contrib
deb-src http://deb.debian.org/debian/ testing main non-free contrib
deb http://deb.debian.org/debian/ unstable main non-free contrib
deb-src http://deb.debian.org/debian/ unstable main non-free contrib

By trying to remove and reinstall I ended up losing some important
packages, so I made it worse already. The general advice to
clean/dist-upgrade/install -f does not get me any further.

Any advice appreciated!
Best regards,
Marty.

[toc] | [next] | [standalone]

#220649 — Re: Unsolvable dependency problems around libc / libcrypt on debian testing/bullseye

[Multipart message — attachments visible in raw view] — view raw

On Sb, 28 mar 20, 23:59:17, Martin wrote:
> 
> I have a debian bullseye/testing machine on a 2017 HP i7 machine that
> I used daily for many months but was not running since end of November
> 2019. I upgraded everything with apt update + dist-upgrade +
> autoremove + clean this week.

[...]
 
> This is my apt sources list:
> 
> deb http://deb.debian.org/debian/ testing main non-free contrib
> deb-src http://deb.debian.org/debian/ testing main non-free contrib
> deb http://deb.debian.org/debian/ unstable main non-free contrib
> deb-src http://deb.debian.org/debian/ unstable main non-free contrib

With this sources list you appear to be running unstable, not testing. 

Please show also the output of 'apt policy'.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#220658

Hello Andrei,

thank you for your time!

> With this sources list you appear to be running unstable, not testing.
> Please show also the output of 'apt policy'.
>

sorry, yes I am usually happy to be on "unstable".

Here is apt policy:

Package files:
 100 /var/lib/dpkg/status
     release a=now
 500 https://repo.skype.com/deb stable/main amd64 Packages
     release o=. stable,a=stable,n=stable,l=. stable,c=main,b=amd64
     origin repo.skype.com
 600 http://deb.debian.org/debian unstable/contrib i386 Packages
     release o=Debian,a=unstable,n=sid,l=Debian,c=contrib,b=i386
     origin deb.debian.org
 600 http://deb.debian.org/debian unstable/contrib amd64 Packages
     release o=Debian,a=unstable,n=sid,l=Debian,c=contrib,b=amd64
     origin deb.debian.org
 600 http://deb.debian.org/debian unstable/non-free i386 Packages
     release o=Debian,a=unstable,n=sid,l=Debian,c=non-free,b=i386
     origin deb.debian.org
 600 http://deb.debian.org/debian unstable/non-free amd64 Packages
     release o=Debian,a=unstable,n=sid,l=Debian,c=non-free,b=amd64
     origin deb.debian.org
 600 http://deb.debian.org/debian unstable/main i386 Packages
     release o=Debian,a=unstable,n=sid,l=Debian,c=main,b=i386
     origin deb.debian.org
 600 http://deb.debian.org/debian unstable/main amd64 Packages
     release o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64
     origin deb.debian.org
 650 http://deb.debian.org/debian testing/contrib i386 Packages
     release o=Debian,a=testing,n=bullseye,l=Debian,c=contrib,b=i386
     origin deb.debian.org
 650 http://deb.debian.org/debian testing/contrib amd64 Packages
     release o=Debian,a=testing,n=bullseye,l=Debian,c=contrib,b=amd64
     origin deb.debian.org
 650 http://deb.debian.org/debian testing/non-free i386 Packages
     release o=Debian,a=testing,n=bullseye,l=Debian,c=non-free,b=i386
     origin deb.debian.org
 650 http://deb.debian.org/debian testing/non-free amd64 Packages
     release o=Debian,a=testing,n=bullseye,l=Debian,c=non-free,b=amd64
     origin deb.debian.org
 650 http://deb.debian.org/debian testing/main i386 Packages
     release o=Debian,a=testing,n=bullseye,l=Debian,c=main,b=i386
     origin deb.debian.org
 650 http://deb.debian.org/debian testing/main amd64 Packages
     release o=Debian,a=testing,n=bullseye,l=Debian,c=main,b=amd64
     origin deb.debian.org
 500 https://download.docker.com/linux/debian buster/stable amd64 Packages
     release o=Docker,a=buster,l=Docker CE,c=stable,b=amd64
     origin download.docker.com
Pinned packages:
     libpython3.8-minimal -> 3.8.2-1 with priority -30000
     libcrypt1 -> 1:4.4.15-1 with priority -30000
     libcrypt1:i386 -> 1:4.4.15-1 with priority -30000
     powertop -> 2.10-1+b1 with priority 30000
     openssh-server -> 1:8.1p1-1 with priority 30000
     grub-efi-amd64 -> 2.04-3 with priority 30000
     isc-dhcp-client -> 4.4.1-2 with priority 30000


I tried to unpin these packages:

sudo apt-mark unhold libcrypt1


E: Can't select installed nor candidate version from package
'libcrypt1' as it has neither of them
E: No packages found

sudo -i
root@lemon:~# echo libcrypt1 install | dpkg --set-selections
dpkg: warning: package not in status nor available database at line 1: libcrypt1
dpkg: warning: found unknown packages; this might mean the available database
is outdated, and needs to be updated through a frontend method;
please see the FAQ <https://wiki.debian.org/Teams/Dpkg/FAQ>

Running apt update makes no difference to that.

Best regards,
Marty

On Sun, 29 Mar 2020 at 07:56, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
>
> On Sb, 28 mar 20, 23:59:17, Martin wrote:
> >
> > I have a debian bullseye/testing machine on a 2017 HP i7 machine that
> > I used daily for many months but was not running since end of November
> > 2019. I upgraded everything with apt update + dist-upgrade +
> > autoremove + clean this week.
>
> [...]
>
> > This is my apt sources list:
> >
> > deb http://deb.debian.org/debian/ testing main non-free contrib
> > deb-src http://deb.debian.org/debian/ testing main non-free contrib
> > deb http://deb.debian.org/debian/ unstable main non-free contrib
> > deb-src http://deb.debian.org/debian/ unstable main non-free contrib
>
> With this sources list you appear to be running unstable, not testing.
>
> Please show also the output of 'apt policy'.
>
> Kind regards,
> Andrei
> --
> http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#220661 — Re: Unsolvable dependency problems around libc / libcrypt on debian testing/bullseye

[Multipart message — attachments visible in raw view] — view raw

On Du, 29 mar 20, 12:37:39, Martin wrote:
> 
> Here is apt policy:
> 
> Package files:
>  100 /var/lib/dpkg/status
>      release a=now
>  500 https://repo.skype.com/deb stable/main amd64 Packages
>      release o=. stable,a=stable,n=stable,l=. stable,c=main,b=amd64
>      origin repo.skype.com
>  600 http://deb.debian.org/debian unstable/contrib i386 Packages
>      release o=Debian,a=unstable,n=sid,l=Debian,c=contrib,b=i386
>      origin deb.debian.org
>  600 http://deb.debian.org/debian unstable/contrib amd64 Packages
>      release o=Debian,a=unstable,n=sid,l=Debian,c=contrib,b=amd64
>      origin deb.debian.org
>  600 http://deb.debian.org/debian unstable/non-free i386 Packages
>      release o=Debian,a=unstable,n=sid,l=Debian,c=non-free,b=i386
>      origin deb.debian.org
>  600 http://deb.debian.org/debian unstable/non-free amd64 Packages
>      release o=Debian,a=unstable,n=sid,l=Debian,c=non-free,b=amd64
>      origin deb.debian.org
>  600 http://deb.debian.org/debian unstable/main i386 Packages
>      release o=Debian,a=unstable,n=sid,l=Debian,c=main,b=i386
>      origin deb.debian.org
>  600 http://deb.debian.org/debian unstable/main amd64 Packages
>      release o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64
>      origin deb.debian.org
>  650 http://deb.debian.org/debian testing/contrib i386 Packages
>      release o=Debian,a=testing,n=bullseye,l=Debian,c=contrib,b=i386
>      origin deb.debian.org
>  650 http://deb.debian.org/debian testing/contrib amd64 Packages
>      release o=Debian,a=testing,n=bullseye,l=Debian,c=contrib,b=amd64
>      origin deb.debian.org
>  650 http://deb.debian.org/debian testing/non-free i386 Packages
>      release o=Debian,a=testing,n=bullseye,l=Debian,c=non-free,b=i386
>      origin deb.debian.org
>  650 http://deb.debian.org/debian testing/non-free amd64 Packages
>      release o=Debian,a=testing,n=bullseye,l=Debian,c=non-free,b=amd64
>      origin deb.debian.org
>  650 http://deb.debian.org/debian testing/main i386 Packages
>      release o=Debian,a=testing,n=bullseye,l=Debian,c=main,b=i386
>      origin deb.debian.org
>  650 http://deb.debian.org/debian testing/main amd64 Packages
>      release o=Debian,a=testing,n=bullseye,l=Debian,c=main,b=amd64
>      origin deb.debian.org
>  500 https://download.docker.com/linux/debian buster/stable amd64 Packages
>      release o=Docker,a=buster,l=Docker CE,c=stable,b=amd64
>      origin download.docker.com

So you have a multiarch (amd64 and i386) system, with amd64 repositories 
for Skype and Docker.

Why do you need i386? I'm guessing you might have some locally installed 
packages as well. Please show also the output of

    aptitude search '~o'
    aptitude search '~b'

> Pinned packages:
>      libpython3.8-minimal -> 3.8.2-1 with priority -30000
>      libcrypt1 -> 1:4.4.15-1 with priority -30000
>      libcrypt1:i386 -> 1:4.4.15-1 with priority -30000
>      powertop -> 2.10-1+b1 with priority 30000
>      openssh-server -> 1:8.1p1-1 with priority 30000
>      grub-efi-amd64 -> 2.04-3 with priority 30000
>      isc-dhcp-client -> 4.4.1-2 with priority 30000

Why did you add these pins?

> I tried to unpin these packages:
> 
> sudo apt-mark unhold libcrypt1

Pins are not holds...

Your system is a... complex mixture that is very easy to break.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#220670

On Sun, 29 Mar 2020 at 13:33, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
>
> So you have a multiarch (amd64 and i386) system, with amd64 repositories
> for Skype and Docker.
>
> Why do you need i386? I'm guessing you might have some locally installed
> packages as well. Please show also the output of
>
>     aptitude search '~o'
>     aptitude search '~b'

I would not bot able to answer it, maybe the scanner driver. I do use
skype and docker. Anyway, here the output:

 sudo aptitude search '~o'
Warning: Invalid locale (please review locale settings, this might
lead to problems later):
  locale::facet::_S_create_c_locale name not valid
i   libapt-inst2.0                                              - deb
package format runtime library
i   libapt-pkg5.0                                               -
package management runtime library
i   libdns-export1104                                           -
Exported DNS Shared Library
i   libip4tc0                                                   -
netfilter libip4tc library
i   libip6tc0                                                   -
netfilter libip6tc library
i   libisc-export1100                                           -
Exported ISC Shared Library
i   libjson-c3                                                  - JSON
manipulation library - shared library
i   libprocps7                                                  -
library for accessing process information from /proc
i   libreadline7                                                - GNU
readline and history libraries, run-time libraries
i A linux-image-5.2.0-3-amd64                                   -
Linux 5.2 for 64-bit PCs (signed)
i   net.downloadhelper.coapp                                    -
Video DownloadHelper companion app
i   perl-modules-5.28                                           - Core
Perl modules
i   scangearmp-common                                           -
ScanGear MP for Linux.
i   scangearmp-mg2500series                                     -
ScanGear MP for Linux.

sudo aptitude search '~b'
Warning: Invalid locale (please review locale settings, this might
lead to problems later):
  locale::facet::_S_create_c_locale name not valid

downloadhelper is part of a firefox extension.
"locale" is one of the packages that is currently broken (update:
could reinstall and it is working now)

>
> > Pinned packages:
> >      libpython3.8-minimal -> 3.8.2-1 with priority -30000
> >      libcrypt1 -> 1:4.4.15-1 with priority -30000
> >      libcrypt1:i386 -> 1:4.4.15-1 with priority -30000
> >      powertop -> 2.10-1+b1 with priority 30000
> >      openssh-server -> 1:8.1p1-1 with priority 30000
> >      grub-efi-amd64 -> 2.04-3 with priority 30000
> >      isc-dhcp-client -> 4.4.1-2 with priority 30000
>
> Why did you add these pins?

When I did the upgrade (the big one after 4 months) apt-listbugs
warned about a number of bugs and I felt safer to pin those packages.

>
> > I tried to unpin these packages:
> >
> > sudo apt-mark unhold libcrypt1
>
> Pins are not holds...

Thank you, this was not obvious to me. I now deleted the pins from
/etc/apt/preferences.d/apt-listbugs and rerun update+upgrade and that
seems to have fixed my problems.
\o/

>
> Your system is a... complex mixture that is very easy to break.

You refer to my apt policy I assume and/or my apt sources list? I
would be happy to simplify it. In my sources.list I now only have
unstable:

deb http://deb.debian.org/debian/ unstable main non-free contrib
deb-src http://deb.debian.org/debian/ unstable main non-free contrib

For my apt preferences I had:

Package: *
Pin: release a=testing
Pin-Priority: 650

Package: *
Pin: release a=unstable
Pin-Priority: 600

To be honest back in the day when I did that, I struggled to really
understand it. My intention was to have the system take packages from
unstable and if a package is not available there then from testing.
Does it even do that?
Thank you a lot for your help!

Marty

[toc] | [prev] | [next] | [standalone]

#220681 — Re: Unsolvable dependency problems around libc / libcrypt on debian testing/bullseye

[Multipart message — attachments visible in raw view] — view raw

On Du, 29 mar 20, 16:40:03, Martin wrote:
> On Sun, 29 Mar 2020 at 13:33, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> >
> > > Pinned packages:
> > >      libpython3.8-minimal -> 3.8.2-1 with priority -30000
> > >      libcrypt1 -> 1:4.4.15-1 with priority -30000
> > >      libcrypt1:i386 -> 1:4.4.15-1 with priority -30000
> > >      powertop -> 2.10-1+b1 with priority 30000
> > >      openssh-server -> 1:8.1p1-1 with priority 30000
> > >      grub-efi-amd64 -> 2.04-3 with priority 30000
> > >      isc-dhcp-client -> 4.4.1-2 with priority 30000
> >
> > Why did you add these pins?
> 
> When I did the upgrade (the big one after 4 months) apt-listbugs
> warned about a number of bugs and I felt safer to pin those packages.
> 
> >
> > > I tried to unpin these packages:
> > >
> > > sudo apt-mark unhold libcrypt1
> >
> > Pins are not holds...
> 
> Thank you, this was not obvious to me. I now deleted the pins from
> /etc/apt/preferences.d/apt-listbugs and rerun update+upgrade and that
> seems to have fixed my problems.
> \o/

Ok.

> > Your system is a... complex mixture that is very easy to break.
> 
> You refer to my apt policy I assume and/or my apt sources list? I
> would be happy to simplify it. In my sources.list I now only have
> unstable:
> 
> deb http://deb.debian.org/debian/ unstable main non-free contrib
> deb-src http://deb.debian.org/debian/ unstable main non-free contrib

According to your 'apt policy' you also had repositories configured for 
Skype and Docker. Did you remove those as well?

> For my apt preferences I had:
> 
> Package: *
> Pin: release a=testing
> Pin-Priority: 650
> 
> Package: *
> Pin: release a=unstable
> Pin-Priority: 600
> 
> To be honest back in the day when I did that, I struggled to really
> understand it. My intention was to have the system take packages from
> unstable and if a package is not available there then from testing.
> Does it even do that?

It does the exact opposite, because in your configuration testing has 
higher priority.

For what you wrote above you don't need any pinning, just have both 
unstable and testing your sources.list.


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#220694

On Sun, 29 Mar 2020 at 20:59, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> According to your 'apt policy' you also had repositories configured for
> Skype and Docker. Did you remove those as well?

They remain, just were in their own files.

>
> > For my apt preferences I had:
> >
> > Package: *
> > Pin: release a=testing
> > Pin-Priority: 650
> >
> > Package: *
> > Pin: release a=unstable
> > Pin-Priority: 600
> >
> > To be honest back in the day when I did that, I struggled to really
> > understand it. My intention was to have the system take packages from
> > unstable and if a package is not available there then from testing.
> > Does it even do that?
>
> It does the exact opposite, because in your configuration testing has
> higher priority.
>
> For what you wrote above you don't need any pinning, just have both
> unstable and testing your sources.list.

Great, thank you very much for clearing this up for me! Problems solved!

Best regards,
Marty

[toc] | [prev] | [next] | [standalone]

#220696 — Re: Unsolvable dependency problems around libc / libcrypt on debian testing/bullseye

[Multipart message — attachments visible in raw view] — view raw

On Lu, 30 mar 20, 12:47:45, Martin wrote:
> On Sun, 29 Mar 2020 at 20:59, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> >
> > > For my apt preferences I had:
> > >
> > > Package: *
> > > Pin: release a=testing
> > > Pin-Priority: 650
> > >
> > > Package: *
> > > Pin: release a=unstable
> > > Pin-Priority: 600
> > >
> > > To be honest back in the day when I did that, I struggled to really
> > > understand it. My intention was to have the system take packages from
> > > unstable and if a package is not available there then from testing.
> > > Does it even do that?
> >
> > It does the exact opposite, because in your configuration testing has
> > higher priority.
> >
> > For what you wrote above you don't need any pinning, just have both
> > unstable and testing your sources.list.
> 
> Great, thank you very much for clearing this up for me! Problems solved!

To explain, apt by default will always prefer the newest version it can 
find in your repositories. Pins are only necessary if for some reason 
you want to override that.

If you intend to stay on unstable it is safe to remove the pins 
completely and still retain testing in sources.list (having testing in 
sources.list when running unstable is a good idea anyway).

As for bugs in individual packages, you need a negative pin (any value 
below 0) for the specific version with the bug. That way a newer version 
(hopefully without the bug) will be installed automatically.

If you are using aptitude there is also 'forbid-version' which does the 
same.

A pin with a value > 1000 (any value) will force apt to keep the package 
at that version, regardless of what updates are available. As you found 
out, this will block regular updates that explicitly require a newer 
version of the pinned package.

One has to decide on a case-by-case basis what is more important (pin or 
updates).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#220768 — Re: [OT] testing on unstable sources list

On 3/30/20 2:26 PM, Andrei POPESCU wrote:

(snip)

>> [...] and still retain testing in sources.list (having testing in 
> sources.list when running unstable is a good idea anyway).

(snip)

> Kind regards,
> Andrei
> 

Can you be so kind and explain to me how is that a good idea? I am
_definitely not_ as knowledgeable as you are, but that sounds strange
enough to make me wonder what have I missed...

I have only tried unstable twice and only on secondary machines, just
for experimenting. This question is only for learning purpose.


Thanks in advance,
Dalios

[toc] | [prev] | [next] | [standalone]

#220778 — Re: [OT] testing on unstable sources list

[Multipart message — attachments visible in raw view] — view raw

On Mi, 01 apr 20, 15:49:25, dalios wrote:
> On 3/30/20 2:26 PM, Andrei POPESCU wrote:
> 
> >> [...] and still retain testing in sources.list (having testing in 
> > sources.list when running unstable is a good idea anyway).
> 
> Can you be so kind and explain to me how is that a good idea? I am
> _definitely not_ as knowledgeable as you are, but that sounds strange
> enough to make me wonder what have I missed...
> 
> I have only tried unstable twice and only on secondary machines, just
> for experimenting. This question is only for learning purpose.

The recommendation is based on the statement of a Debian Release Manager 
some years ago[1].

Basically it may happen that a particular package is removed from 
unstable, which will also affect other packages that depend on it.

With testing in sources.list the package can be installed from there 
instead.

Because apt[2] by default prefers newer versions of a package, if a 
package is available in unstable and testing with different versions the 
unstable version will be preferred.

So the only downsides I can think of would be slightly longer download 
times on 'apt update' and possibly a late alert that a specific package 
is being removed from Debian (typically packages are removed from 
testing first, but it may happen the other way around as well).

[1] https://lists.debian.org/debian-devel/2009/03/msg00582.html
[2] and other package managers like aptitude, etc.

Hope this explains,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#220795 — Re: [OT] testing on unstable sources list

On 4/1/20 6:46 PM, Andrei POPESCU wrote:
> On Mi, 01 apr 20, 15:49:25, dalios wrote:
>> On 3/30/20 2:26 PM, Andrei POPESCU wrote:
>>
>>>> [...] and still retain testing in sources.list (having testing in 
>>> sources.list when running unstable is a good idea anyway).
>>
>> Can you be so kind and explain to me how is that a good idea? I am
>> _definitely not_ as knowledgeable as you are, but that sounds strange
>> enough to make me wonder what have I missed...
>>
>> I have only tried unstable twice and only on secondary machines, just
>> for experimenting. This question is only for learning purpose.
> 
> The recommendation is based on the statement of a Debian Release Manager 
> some years ago[1].
> 
> Basically it may happen that a particular package is removed from 
> unstable, which will also affect other packages that depend on it.
> 
> With testing in sources.list the package can be installed from there 
> instead.
> 
> Because apt[2] by default prefers newer versions of a package, if a 
> package is available in unstable and testing with different versions the 
> unstable version will be preferred.
> 
> So the only downsides I can think of would be slightly longer download 
> times on 'apt update' and possibly a late alert that a specific package 
> is being removed from Debian (typically packages are removed from 
> testing first, but it may happen the other way around as well).
> 
> [1] https://lists.debian.org/debian-devel/2009/03/msg00582.html
> [2] and other package managers like aptitude, etc.
> 
> Hope this explains,
> Andrei
> 

Thanks for the explanation.

Dalios

[toc] | [prev] | [next] | [standalone]

#220659

I commented out the testing repository in my apt sources list and ran
apt update/upgrade/clean/autoremove. It helped e.g. with updating
firefox from 69 to 74 but other packages are still stuck.

apt list --upgradable

libc-bin/unstable 2.30-4 amd64 [upgradable from: 2.29-2]
libc6/unstable 2.30-4 amd64 [upgradable from: 2.29-2]
libc6/unstable 2.30-4 i386 [upgradable from: 2.29-2]
libpam-systemd/unstable 245.2-1 amd64 [upgradable from: 244.3-1]
libruby2.5/unstable 2.5.7-1+b1 amd64 [upgradable from: 2.5.7-1]
libselinux1/unstable 3.0-1+b2 amd64 [upgradable from: 3.0-1+b1]
libsystemd0/unstable 245.2-1 amd64 [upgradable from: 244.3-1]
libudev1/unstable 245.2-1 amd64 [upgradable from: 244.3-1]
login/unstable 1:4.8.1-1 amd64 [upgradable from: 1:4.7-2]
passwd/unstable 1:4.8.1-1 amd64 [upgradable from: 1:4.7-2]
ruby-debian/unstable 0.3.10+b3 amd64 [upgradable from: 0.3.10+b2]
ruby-sqlite3/unstable 1.4.2-2+b2 amd64 [upgradable from: 1.4.2-2+b1]
ruby-unf-ext/unstable 0.0.7.6-1+b2 amd64 [upgradable from: 0.0.7.6-1+b1]
ruby-unicode/unstable 0.4.4-2+b11 amd64 [upgradable from: 0.4.4-2+b10]
ruby-xmlparser/unstable 0.7.3-3+b4 amd64 [upgradable from: 0.7.3-3+b3]
ruby/unstable 1:2.7 amd64 [upgradable from: 1:2.5.7.1]
shim-unsigned/unstable 15+1533136590.3beb971-8 amd64 [upgradable from:
15+1533136590.3beb971-7]
systemd/unstable 245.2-1 amd64 [upgradable from: 244.3-1]
udev/unstable 245.2-1 amd64 [upgradable from: 244.3-1]
whois/unstable 5.5.6 amd64 [upgradable from: 5.5.2]

On Sun, 29 Mar 2020 at 07:56, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
>
> On Sb, 28 mar 20, 23:59:17, Martin wrote:
> >
> > I have a debian bullseye/testing machine on a 2017 HP i7 machine that
> > I used daily for many months but was not running since end of November
> > 2019. I upgraded everything with apt update + dist-upgrade +
> > autoremove + clean this week.
>
> [...]
>
> > This is my apt sources list:
> >
> > deb http://deb.debian.org/debian/ testing main non-free contrib
> > deb-src http://deb.debian.org/debian/ testing main non-free contrib
> > deb http://deb.debian.org/debian/ unstable main non-free contrib
> > deb-src http://deb.debian.org/debian/ unstable main non-free contrib
>
> With this sources list you appear to be running unstable, not testing.
>
> Please show also the output of 'apt policy'.
>
> Kind regards,
> Andrei
> --
> http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web