Re: Testing bullseye

[Nicholas Geovanis]

On Sun, Jul 25, 2021, 3:03 PM Nicholas Geovanis 
wrote:

>
>
> On Sun, Jul 25, 2021, 2:35 AM Gunnar Gervin  wrote:
>
>> ..Learning Linux Debian is a nice hobby(feels more like a lifestyle)
>>
>
> Linux always felt larger than merely another OS, whether Debian or other.
>

But I should add that the Debian ecosystem always felt bigger than the
other distributions' ecosystems. Thinking of SuSE and RH/CentOS/fedora. It
just seems to vacuum it all up and release it. And I now even encounter
businesses that are uncomfortable in the RH ecosystem because they see
single-vendor dependency there despite open source. I think AWS and Google
cloud deserve some credit for that, having presented Debian and
Debian-based releases (AMI in AWS) as almost canonical. And they have their
own wariness of RH as competitors.

IMO that's because of the free-software movement's stated social goals and
> because of the broad cooperation needed to make the software. Yet the
> free-software movement is unknown to the humans who rely on Linux servers
> as only infrastructure, and mostly ignored as a social movement even by
> those who use Linux consciously or with economic intent.
>
> geg
>>
>

Re: Testing bullseye

[Nicholas Geovanis]

On Sun, Jul 25, 2021, 2:35 AM Gunnar Gervin  wrote:

> ..Learning Linux Debian is a nice hobby(feels more like a lifestyle)
>

Linux always felt larger than merely another OS, whether Debian or other.
IMO that's because of the free-software movement's stated social goals and
because of the broad cooperation needed to make the software. Yet the
free-software movement is unknown to the humans who rely on Linux servers
as only infrastructure, and mostly ignored as a social movement even by
those who use Linux consciously or with economic intent.

geg
>

Testing bullseye

[Gunnar Gervin]

Thx for the request to help in this project even not knowing code. I'll
firstly try it on my 14 yr old Debian Buster ex-macbook. Nice way to
include more people &, probably, improve+stabilize the distro much faster.
Learning Linux Debian is a nice hobby(feels more like a lifestyle)
geg

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Gary Dale]

On 2021-02-17 04:53, Andrei POPESCU wrote:

On Ma, 16 feb 21, 16:45:13, Gary Dale wrote:

I hear you, but the issue is that if I revert to a previous version, then I
have to hold it to stop the buggy version from clobbering it every day. And
I have to monitor the Testing version for changes to see when a fix is
potentially available so I can remove the hold.

Not just me but every user who is experiencing the bug also has to do this.

This is what 'aptitude forbid-version' is for.

Kind regards,
Andrei

Thanks. I wasn't aware of that option.

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Gary Dale]

On 2021-02-16 17:02, Philip Wyett wrote:

On Tue, 2021-02-16 at 16:45 -0500, Gary Dale wrote:

On 2021-02-13 03:02, Andrei POPESCU wrote:

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

I hear you, but the issue is that if I revert to a previous version,
then I have to hold it to stop the buggy version from clobbering it
every day. And I have to monitor the Testing version for changes to
see
when a fix is potentially available so I can remove the hold.

Not just me but every user who is experiencing the bug also has to do
this.

There is a kludge for this if the buggy version didn't contain
critical
security fixes - re-release the previous version with a slightly
higher
version number than the buggy one (e.g. 3.7.0-5a). When the bug is
(finally) fixed, give the fixed version a slightly higher number
still
(e.g. 3.7.0.5b).

Again this would only be done where it appears that fixing the bug
may
take time (it's been over a month now). If I were to do the
alternative
- pull packages from Sid - I have no real indication if they fix it
or
introduce even worse problems.

I can only assume that the reason a fix hasn't made it down through
Sid
yet is that it's not simple. My suggestion isn't to make more work
for
maintainers but rather to take the time pressure off them without
leaving us testers to jump through hoops.



Hi,

What appears to be the fixed version is in sid (3.7.0-7). It has to
pass in sid for 10 days before migration to testing, see below link.

https://tracker.debian.org/pkg/gnutls28

https://metadata.ftp-master.debian.org/changelogs//main/g/gnutls28/gnutls28_3.7.0-7_changelog

My testing with filezilla, shows all to be working once more, though
testing has been limited.

Regards

Phil

Confirmed. Seems to work. You need to install libnettle and libgnutls 
from Sid as well.

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Andrei POPESCU]

On Ma, 16 feb 21, 16:45:13, Gary Dale wrote:
> 
> I hear you, but the issue is that if I revert to a previous version, then I
> have to hold it to stop the buggy version from clobbering it every day. And
> I have to monitor the Testing version for changes to see when a fix is
> potentially available so I can remove the hold.
> 
> Not just me but every user who is experiencing the bug also has to do this.

This is what 'aptitude forbid-version' is for.

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


signature.asc
Description: PGP signature

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Gary Dale]

On 2021-02-13 03:02, Andrei POPESCU wrote:

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


I hear you, but the issue is that if I revert to a previous version, 
then I have to hold it to stop the buggy version from clobbering it 
every day. And I have to monitor the Testing version for changes to see 
when a fix is potentially available so I can remove the hold.


Not just me but every user who is experiencing the bug also has to do this.

There is a kludge for this if the buggy version didn't contain critical 
security fixes - re-release the previous version with a slightly higher 
version number than the buggy one (e.g. 3.7.0-5a). When the bug is 
(finally) fixed, give the fixed version a slightly higher number still 
(e.g. 3.7.0.5b).


Again this would only be done where it appears that fixing the bug may 
take time (it's been over a month now). If I were to do the alternative 
- pull packages from Sid - I have no real indication if they fix it or 
introduce even worse problems.


I can only assume that the reason a fix hasn't made it down through Sid 
yet is that it's not simple. My suggestion isn't to make more work for 
maintainers but rather to take the time pressure off them without 
leaving us testers to jump through hoops.

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Philip Wyett]

On Tue, 2021-02-16 at 16:45 -0500, Gary Dale wrote:
> On 2021-02-13 03:02, Andrei POPESCU wrote:
> > 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
> 
> I hear you, but the issue is that if I revert to a previous version, 
> then I have to hold it to stop the buggy version from clobbering it 
> every day. And I have to monitor the Testing version for changes to
> see 
> when a fix is potentially available so I can remove the hold.
> 
> Not just me but every user who is experiencing the bug also has to do
> this.
> 
> There is a kludge for this if the buggy version didn't contain
> critical 
> security fixes - re-release the previous version with a slightly
> higher 
> version number than the buggy one (e.g. 3.7.0-5a). When the bug is 
> (finally) fixed, give the fixed version a slightly higher number
> still 
> (e.g. 3.7.0.5b).
> 
> Again this would only be done where it appears that fixing the bug
> may 
> take time (it's been over a month now). If I were to do the
> alternative 
> - pull packages from Sid - I have no real indication if they fix it
> or 
> introduce even worse problems.
> 
> I can only assume that the reason a fix hasn't made it down through
> Sid 
> yet is that it's not simple. My suggestion isn't to make more work
> for 
> maintainers but rather to take the time pressure off them without 
> leaving us testers to jump through hoops.
> 
> 

Hi,

What appears to be the fixed version is in sid (3.7.0-7). It has to
pass in sid for 10 days before migration to testing, see below link.

https://tracker.debian.org/pkg/gnutls28

https://metadata.ftp-master.debian.org/changelogs//main/g/gnutls28/gnutls28_3.7.0-7_changelog

My testing with filezilla, shows all to be working once more, though
testing has been limited.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


signature.asc
Description: This is a digitally signed message part

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Frank]

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: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[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.

  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: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[songbird]

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: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Frank]

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.

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Andrei POPESCU]

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

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Gary Dale]

On 2021-02-12 16:10, songbird wrote:

Gary Dale wrote:
...

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. I see
it also impacts other programs that I (fortunately) don't use as much.

   i know it is frustrating to hit something like this when you
are trying to just get a website updated.  all i can say is that
if you are running testing you are taking this sort of happening
as a risk and if you do not want that risk then you should step
back to stable instead.  especially if you are doing this for
something that might be time critical or a production issue.

   i keep a stable partition for this reason and while i rarely
have needed it in the past this year i've had to use it twice.
once for the FileZilla issue as you are facing and another for
a program which hasn't been converted to python3 yet (and for
all i know it may not ever be).


I keep a VM for the same reason - I set it up several years ago after a 
Ghostscript issue caused a lot of pain for me in both Stable and 
Testing. I set the VM up for what was then OldStable as a workaround. I 
also have a laptop running Stable. In 20 years of running Debian, I've 
only encountered 2 issues that weren't fixed fairly quickly.


However, it's all a little clumsy. My main workstation is set up the way 
I like and I'm familiar with using it. The other options I rarely have 
to use.  I often find it easier to ssh to my (stable) server and use the 
command line for file transfers.






When faced with a major bug, shouldn't there be a procedure to pull back
the testing version - like restoring the previous version with a
bumped-up version number while working on the known buggy version in
experimental (no need to punish people using SID)?

   it didn't affect enough people for it to be noticed before
the affected packages went from sid to testing.  that's the
problem when you get particular older packages that only a
few people use once in a while.  it would have been nice to
have caught it in sid before testing, but, well...

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...


I don't mind testing things and reporting issues, but I also don't like 
having my workflow disrupted for an extended period.


I admit I don't know what issues were behind the rollout of the current 
"testing" version of GnuTLS but it breaks a lot of programs, including 
(apparently) wget.

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Gary Dale]

On 2021-02-12 14:15, Paul Scott wrote:


On 2/12/21 12:12 PM, 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.



gFtp seems to fail also.  Do you know what works for Gnome on sid?

Thank you,

Paul

I didn't even know it was still being developed. I used it briefly after 
kBear was dropped, but found that it didn't seem to keep up with the 
state of the protocols. It stopped working for me when the various hosts 
I use improved their security. FileZilla handles more of the wrinkles...

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[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.

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Gary Dale]

On 2021-02-12 09:12, songbird wrote:

Gary Dale wrote:
...

Time passes and the bug is still in Debian/Testing.


   please look at the end of:


   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980119


   it looks like things are happening, but how quickly those
changes are applied and uploads happen and are approved may
take some time yet.

   like you i was kinda wondering if any fix at all was
happening or if anyone was even looking into it.

   i sure don't have the skills or expertise in either
filezilla or gnutls to track something like this down.  :(
all i can be is appreciative for those who do and say
thank you!  :)


   songbird


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. I see 
it also impacts other programs that I (fortunately) don't use as much.


When faced with a major bug, shouldn't there be a procedure to pull back 
the testing version - like restoring the previous version with a 
bumped-up version number while working on the known buggy version in 
experimental (no need to punish people using SID)?

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[songbird]

Gary Dale wrote:
...
> 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. I see 
> it also impacts other programs that I (fortunately) don't use as much.

  i know it is frustrating to hit something like this when you
are trying to just get a website updated.  all i can say is that
if you are running testing you are taking this sort of happening
as a risk and if you do not want that risk then you should step
back to stable instead.  especially if you are doing this for 
something that might be time critical or a production issue.

  i keep a stable partition for this reason and while i rarely 
have needed it in the past this year i've had to use it twice.
once for the FileZilla issue as you are facing and another for
a program which hasn't been converted to python3 yet (and for
all i know it may not ever be).


> When faced with a major bug, shouldn't there be a procedure to pull back 
> the testing version - like restoring the previous version with a 
> bumped-up version number while working on the known buggy version in 
> experimental (no need to punish people using SID)?

  it didn't affect enough people for it to be noticed before
the affected packages went from sid to testing.  that's the
problem when you get particular older packages that only a 
few people use once in a while.  it would have been nice to
have caught it in sid before testing, but, well...


  songbird

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Frank de Bruijn]

Op 12-02-2021 om 20:15 schreef Paul Scott:

On 2/12/21 12:12 PM, 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.



gFtp seems to fail also.  Do you know what works for Gnome on sid?


No idea, sorry.

I use Xfce, but I don't like Thunar, so I installed caja. caja is based 
on GNOME's nautilus, so would expect that to work as well. Haven't tried 
it though.


Regards,
Frank

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[songbird]

Greg Wooledge wrote:
...
> First of all, let's be clear: the bug (#980119) affects "FTP over TLS"
> a.k.a. "FTPS" which is a hacked-up abomination of a protocol on top of
> the worst protocol ever conceived.
>
> Anyone actually using this needs to take some time and seriously
> re-evaluate their infrastructure.

  it is something that works, bits are bits, if they are 
getting from my machine to the other at the other end of 
the connection intact and in the right place with the right
permissions then i'm fine with continuing to use it.

  note that ISPs often don't provide the best and most up-
to-date resources or they may not advertise the recommended
alternatives.  and it takes time to make changes.  i sure 
know that i normally hate "web interfaces" that are sometimes 
available.


> The fact that very few people use this nonstandard protocol means it
> doesn't see as much testing as other protocols.

  true.


...
> You are running testing.  This means you are testing Debian's next
> release, before it's released, in order to spot bugs.  Thank you for
> that.  This is a service you are performing for the Debian community,
> and it's valued.
>
> As a volunteer tester, you accept the fact that the software you are
> testing may have bugs.  That's why you're testing it.
>
> This particular bug looks like it has been succesfully reported,
> reproduced, pinpointed, and a fix is underway.  I don't know what
> more you could possibly ask for.
>
> Meanwhile, if this bug affects you, you are free to install an older
> version of the package that doesn't have the bug, or to build a
> package with the upstream patch applied for your temporary local use,
> or to use a non-testing system for your production work.

  all agreed with, but it is better to not mess some things up
if you can avoid it.  :)


  songbird

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Paul Scott]

On 2/12/21 12:12 PM, 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.



gFtp seems to fail also.  Do you know what works for Gnome on sid?

Thank you,

Paul

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Frank]

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

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Greg Wooledge]

On Fri, Feb 12, 2021 at 12:19:46PM -0500, Gary Dale wrote:
> On 2021-02-12 09:12, songbird wrote:
> >it looks like things are happening, but how quickly those
> > changes are applied and uploads happen and are approved may
> > take some time yet.

> 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. I see it also
> impacts other programs that I (fortunately) don't use as much.

First of all, let's be clear: the bug (#980119) affects "FTP over TLS"
a.k.a. "FTPS" which is a hacked-up abomination of a protocol on top of
the worst protocol ever conceived.

Anyone actually using this needs to take some time and seriously
re-evaluate their infrastructure.

The fact that very few people use this nonstandard protocol means it
doesn't see as much testing as other protocols.

> When faced with a major bug, shouldn't there be a procedure to pull back the
> testing version - like restoring the previous version with a bumped-up
> version number while working on the known buggy version in experimental (no
> need to punish people using SID)?

You are running testing.  This means you are testing Debian's next
release, before it's released, in order to spot bugs.  Thank you for
that.  This is a service you are performing for the Debian community,
and it's valued.

As a volunteer tester, you accept the fact that the software you are
testing may have bugs.  That's why you're testing it.

This particular bug looks like it has been succesfully reported,
reproduced, pinpointed, and a fix is underway.  I don't know what
more you could possibly ask for.

Meanwhile, if this bug affects you, you are free to install an older
version of the package that doesn't have the bug, or to build a
package with the upstream patch applied for your temporary local use,
or to use a non-testing system for your production work.

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[songbird]

Gary Dale wrote:
...
> Time passes and the bug is still in Debian/Testing.


  please look at the end of:


  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980119


  it looks like things are happening, but how quickly those
changes are applied and uploads happen and are approved may
take some time yet.

  like you i was kinda wondering if any fix at all was 
happening or if anyone was even looking into it.

  i sure don't have the skills or expertise in either
filezilla or gnutls to track something like this down.  :(
all i can be is appreciative for those who do and say
thank you!  :)


  songbird

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Gary Dale]

On 2021-01-28 11:03, David Wright wrote:

On Thu 28 Jan 2021 at 10:17:50 (-0500), Gary Dale wrote:

On 2021-01-20 10:44, songbird wrote:

Gary Dale wrote:
...
the problem is still there with the recent version of Filezilla
that showed up in testing (3.52.0.5-1).

i see there is a bug filed via GNUTLS:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980119

not sure what progress is actually being made.


I note that the problem affects all ftp client's I've tried under
testing but not the ones in the stable release. It's been weeks since
I first reported this issue yet it still remains.

As far as I can tell, the timeline is:

2021-01-12 your original report
2021-01-14 opened BTS #980119
back and forth replication
2021-01-20 verbose debug information posted
2021-01-23 forwarded to https://gitlab.com/gnutls/gnutls/-/issues/1152

Would that be reasonable for a Severity: Normal bug in testing?

Cheers,
David.


Time passes and the bug is still in Debian/Testing.

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Gary Dale]

On 2021-01-28 11:03, David Wright wrote:

On Thu 28 Jan 2021 at 10:17:50 (-0500), Gary Dale wrote:

On 2021-01-20 10:44, songbird wrote:

Gary Dale wrote:
...
the problem is still there with the recent version of Filezilla
that showed up in testing (3.52.0.5-1).

i see there is a bug filed via GNUTLS:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980119

not sure what progress is actually being made.


I note that the problem affects all ftp client's I've tried under
testing but not the ones in the stable release. It's been weeks since
I first reported this issue yet it still remains.

As far as I can tell, the timeline is:

2021-01-12 your original report
2021-01-14 opened BTS #980119
back and forth replication
2021-01-20 verbose debug information posted
2021-01-23 forwarded to https://gitlab.com/gnutls/gnutls/-/issues/1152

Would that be reasonable for a Severity: Normal bug in testing?

Cheers,
David.


Given that it renders ftp unusable, I'd rate it as important, not normal.

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Gary Dale]

On 2021-01-20 10:44, songbird wrote:

Gary Dale wrote:
...

   the problem is still there with the recent version of Filezilla
that showed up in testing (3.52.0.5-1).


   i see there is a bug filed via GNUTLS:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980119


   not sure what progress is actually being made.


   songbird

I note that the problem affects all ftp client's I've tried under 
testing but not the ones in the stable release. It's been weeks since I 
first reported this issue yet it still remains.

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[David Wright]

On Thu 28 Jan 2021 at 10:17:50 (-0500), Gary Dale wrote:
> On 2021-01-20 10:44, songbird wrote:
> > Gary Dale wrote:
> > ...
> >the problem is still there with the recent version of Filezilla
> > that showed up in testing (3.52.0.5-1).
> > 
> >i see there is a bug filed via GNUTLS:
> > 
> >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980119
> > 
> >not sure what progress is actually being made.
> > 
> I note that the problem affects all ftp client's I've tried under
> testing but not the ones in the stable release. It's been weeks since
> I first reported this issue yet it still remains.

As far as I can tell, the timeline is:

2021-01-12 your original report
2021-01-14 opened BTS #980119
   back and forth replication
2021-01-20 verbose debug information posted
2021-01-23 forwarded to https://gitlab.com/gnutls/gnutls/-/issues/1152

Would that be reasonable for a Severity: Normal bug in testing?

Cheers,
David.

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[songbird]

Philip Wyett wrote:
...
> As stated in other mails. This is why their is stable/production and we
> should rely on those and not testing. ;-)

  yes, of course.  :)  why i keep a booting stable partition
handy.


  songbird

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Philip Wyett]

On Wed, 2021-01-20 at 10:44 -0500, songbird wrote:
> Gary Dale wrote:
> ...
> 
>   the problem is still there with the recent version of Filezilla
> that showed up in testing (3.52.0.5-1).
> 
> 
>   i see there is a bug filed via GNUTLS:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980119
> 
> 
>   not sure what progress is actually being made.
> 
> 
>   songbird
> 

Hi,

This is not a filezilla issue after a little investigation. I will be
looking at other related packages, including gnutls in the coming
days/weeks. I will also be adding these packages to my tracked packages
and make them part of my testing when doing package updates to
filezilla and general testing.

FYI: 3.52.2 just went to unstable/sid.

As stated in other mails. This is why their is stable/production and we
should rely on those and not testing. ;-)

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


signature.asc
Description: This is a digitally signed message part

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[songbird]

Gary Dale wrote:
...

  the problem is still there with the recent version of Filezilla
that showed up in testing (3.52.0.5-1).


  i see there is a bug filed via GNUTLS:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980119


  not sure what progress is actually being made.


  songbird

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Gary Dale]

On 2021-01-13 15:59, Eike Lantzsch wrote:

On Wednesday, 13 January 2021 17:33:12 -03 Gary Dale wrote:

On 2021-01-13 14:54, Eike Lantzsch wrote:

On Wednesday, 13 January 2021 16:42:17 -03 Gary Dale wrote:

On 2021-01-12 22:53, Philip Wyett wrote:

On Tue, 2021-01-12 at 21:27 -0500, Gary Dale wrote:

I'm running Debian/Bullseye on an AMD64 machine.

I'm trying to update a site using FileZilla with the same
settings
I've
been using but cannot get a connection. I've tried this on
several
sites
with the same results. Here's the FileZilla dialogue of a session
connect attempt:

Status:Resolving address of 
Status:Connecting to :21...
Status:Connection established, waiting for welcome message...
Status:Initializing TLS...
Status:Verifying certificate...
Status:TLS connection established.
Status:Server does not support non-ASCII characters.
Status:Logged in
Status:Retrieving directory listing of "/"...
Command:CWD /
Response:250 OK. Current directory is /
Command:PWD
Response:257 "/" is your current location
Command:TYPE I
Response:200 TYPE is now 8-bit binary
Command:PASV
Response:227 Entering Passive Mode (,141,8).
Command:MLSD
Response:150 Accepted data connection
Error:GnuTLS error -15: An unexpected TLS packet was
received.
Error:The data connection could not be established:
ECONNABORTED
-
Connection aborted
Response:226 72 matches total
Error:Failed to retrieve directory listing

at which point the connection seems to be severed by FileZilla.

When I try a command line ftp session, I also find that I cannot
do
an
"ls" after logging in.

However I can connect from my server which is running
Debian/Buster.
Something seems to be going wrong with GnuTLS once the connection
is
established on Bullseye. This is a new behaviour as it wasn't
doing
this
last week.

Hi Gary,

I can confirm this issue.

Please file a bug report against filezilla and it will be looked
into
by myself once 3.52.0.5 has transitioned into unstable (imminent).

Regards

Phil

I don't think it is just a FileZilla problem as it also seems to
crop
up with the command-line ftp program.

You might also try lftp. But since it seems to be a TLS problem the
result might be the same.
Does TLS work when you download mail with your mail-client?

Kind regards
Eike
--
Eike Lantzsch ZP6CGE

I already did the ftp command, as noted in the initial e-mail.

No, I don't think you did what I recommended. I wrote lftp.
ELL-EFF-TEE-PEE
That is a totally different program and far more potent than ftp.

Sorry, old eyes and a 4k monitor. I installed lftp and got the same 
problem I had with ftp. I can log in then when I try to "ls", I get an 
"unexpected TLS packet was received" error.

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Gary Dale]

On 2021-01-13 14:54, Eike Lantzsch wrote:

On Wednesday, 13 January 2021 16:42:17 -03 Gary Dale wrote:

On 2021-01-12 22:53, Philip Wyett wrote:

On Tue, 2021-01-12 at 21:27 -0500, Gary Dale wrote:

I'm running Debian/Bullseye on an AMD64 machine.

I'm trying to update a site using FileZilla with the same settings
I've
been using but cannot get a connection. I've tried this on several
sites
with the same results. Here's the FileZilla dialogue of a session
connect attempt:

Status:Resolving address of 
Status:Connecting to :21...
Status:Connection established, waiting for welcome message...
Status:Initializing TLS...
Status:Verifying certificate...
Status:TLS connection established.
Status:Server does not support non-ASCII characters.
Status:Logged in
Status:Retrieving directory listing of "/"...
Command:CWD /
Response:250 OK. Current directory is /
Command:PWD
Response:257 "/" is your current location
Command:TYPE I
Response:200 TYPE is now 8-bit binary
Command:PASV
Response:227 Entering Passive Mode (,141,8).
Command:MLSD
Response:150 Accepted data connection
Error:GnuTLS error -15: An unexpected TLS packet was received.
Error:The data connection could not be established:
ECONNABORTED
-
Connection aborted
Response:226 72 matches total
Error:Failed to retrieve directory listing

at which point the connection seems to be severed by FileZilla.

When I try a command line ftp session, I also find that I cannot do
an
"ls" after logging in.

However I can connect from my server which is running
Debian/Buster.
Something seems to be going wrong with GnuTLS once the connection
is
established on Bullseye. This is a new behaviour as it wasn't doing
this
last week.

Hi Gary,

I can confirm this issue.

Please file a bug report against filezilla and it will be looked
into
by myself once 3.52.0.5 has transitioned into unstable (imminent).

Regards

Phil

I don't think it is just a FileZilla problem as it also seems to crop
up with the command-line ftp program.

You might also try lftp. But since it seems to be a TLS problem the
result might be the same.
Does TLS work when you download mail with your mail-client?

Kind regards
Eike
--
Eike Lantzsch ZP6CGE


I already did the ftp command, as noted in the initial e-mail. Ftp 
connects but can't get a remote directory listing, without which it 
can't seem to transfer files. Things work with Buster but not with Bullseye.


I'm not having any problems with Thunderbird (my e-mail client) with 
accounts connecting through SSL/TLS and StartTLS.

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Gary Dale]

On 2021-01-12 22:53, Philip Wyett wrote:

On Tue, 2021-01-12 at 21:27 -0500, Gary Dale wrote:

I'm running Debian/Bullseye on an AMD64 machine.

I'm trying to update a site using FileZilla with the same settings
I've
been using but cannot get a connection. I've tried this on several
sites
with the same results. Here's the FileZilla dialogue of a session
connect attempt:

Status:Resolving address of 
Status:Connecting to :21...
Status:Connection established, waiting for welcome message...
Status:Initializing TLS...
Status:Verifying certificate...
Status:TLS connection established.
Status:Server does not support non-ASCII characters.
Status:Logged in
Status:Retrieving directory listing of "/"...
Command:CWD /
Response:250 OK. Current directory is /
Command:PWD
Response:257 "/" is your current location
Command:TYPE I
Response:200 TYPE is now 8-bit binary
Command:PASV
Response:227 Entering Passive Mode (,141,8).
Command:MLSD
Response:150 Accepted data connection
Error:GnuTLS error -15: An unexpected TLS packet was received.
Error:The data connection could not be established: ECONNABORTED
-
Connection aborted
Response:226 72 matches total
Error:Failed to retrieve directory listing

at which point the connection seems to be severed by FileZilla.

When I try a command line ftp session, I also find that I cannot do
an
"ls" after logging in.

However I can connect from my server which is running Debian/Buster.
Something seems to be going wrong with GnuTLS once the connection is
established on Bullseye. This is a new behaviour as it wasn't doing
this
last week.



Hi Gary,

I can confirm this issue.

Please file a bug report against filezilla and it will be looked into
by myself once 3.52.0.5 has transitioned into unstable (imminent).

Regards

Phil

I don't think it is just a FileZilla problem as it also seems to crop up 
with the command-line ftp program.

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[songbird]

Gary Dale wrote:
...

  thanks for the heads-up!  :)

  i don't always need to use it, but today i finally updated some files
and went to connect and no dice.  good thing i have a stable booting
partition i can get things done with if i have to.


  songbird

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Eike Lantzsch]

On Wednesday, 13 January 2021 17:33:12 -03 Gary Dale wrote:
> On 2021-01-13 14:54, Eike Lantzsch wrote:
> > On Wednesday, 13 January 2021 16:42:17 -03 Gary Dale wrote:
> >> On 2021-01-12 22:53, Philip Wyett wrote:
> >>> On Tue, 2021-01-12 at 21:27 -0500, Gary Dale wrote:
>  I'm running Debian/Bullseye on an AMD64 machine.
> 
>  I'm trying to update a site using FileZilla with the same
>  settings
>  I've
>  been using but cannot get a connection. I've tried this on
>  several
>  sites
>  with the same results. Here's the FileZilla dialogue of a session
>  connect attempt:
> 
>  Status:Resolving address of 
>  Status:Connecting to :21...
>  Status:Connection established, waiting for welcome message...
>  Status:Initializing TLS...
>  Status:Verifying certificate...
>  Status:TLS connection established.
>  Status:Server does not support non-ASCII characters.
>  Status:Logged in
>  Status:Retrieving directory listing of "/"...
>  Command:CWD /
>  Response:250 OK. Current directory is /
>  Command:PWD
>  Response:257 "/" is your current location
>  Command:TYPE I
>  Response:200 TYPE is now 8-bit binary
>  Command:PASV
>  Response:227 Entering Passive Mode (,141,8).
>  Command:MLSD
>  Response:150 Accepted data connection
>  Error:GnuTLS error -15: An unexpected TLS packet was
>  received.
>  Error:The data connection could not be established:
>  ECONNABORTED
>  -
>  Connection aborted
>  Response:226 72 matches total
>  Error:Failed to retrieve directory listing
> 
>  at which point the connection seems to be severed by FileZilla.
> 
>  When I try a command line ftp session, I also find that I cannot
>  do
>  an
>  "ls" after logging in.
> 
>  However I can connect from my server which is running
>  Debian/Buster.
>  Something seems to be going wrong with GnuTLS once the connection
>  is
>  established on Bullseye. This is a new behaviour as it wasn't
>  doing
>  this
>  last week.
> >>>
> >>> Hi Gary,
> >>>
> >>> I can confirm this issue.
> >>>
> >>> Please file a bug report against filezilla and it will be looked
> >>> into
> >>> by myself once 3.52.0.5 has transitioned into unstable (imminent).
> >>>
> >>> Regards
> >>>
> >>> Phil
> >>
> >> I don't think it is just a FileZilla problem as it also seems to
> >> crop
> >> up with the command-line ftp program.
> >
> > You might also try lftp. But since it seems to be a TLS problem the
> > result might be the same.
> > Does TLS work when you download mail with your mail-client?
> >
> > Kind regards
> > Eike
> > --
> > Eike Lantzsch ZP6CGE
>
> I already did the ftp command, as noted in the initial e-mail.

No, I don't think you did what I recommended. I wrote lftp.
ELL-EFF-TEE-PEE
That is a totally different program and far more potent than ftp.

> Ftp
> connects but can't get a remote directory listing, without which it
> can't seem to transfer files. Things work with Buster but not with
> Bullseye.
>
> I'm not having any problems with Thunderbird (my e-mail client) with
> accounts connecting through SSL/TLS and StartTLS.

--
Eike Lantzsch ZP6CGE

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Eike Lantzsch]

On Wednesday, 13 January 2021 16:42:17 -03 Gary Dale wrote:
> On 2021-01-12 22:53, Philip Wyett wrote:
> > On Tue, 2021-01-12 at 21:27 -0500, Gary Dale wrote:
> >> I'm running Debian/Bullseye on an AMD64 machine.
> >>
> >> I'm trying to update a site using FileZilla with the same settings
> >> I've
> >> been using but cannot get a connection. I've tried this on several
> >> sites
> >> with the same results. Here's the FileZilla dialogue of a session
> >> connect attempt:
> >>
> >> Status:Resolving address of 
> >> Status:Connecting to :21...
> >> Status:Connection established, waiting for welcome message...
> >> Status:Initializing TLS...
> >> Status:Verifying certificate...
> >> Status:TLS connection established.
> >> Status:Server does not support non-ASCII characters.
> >> Status:Logged in
> >> Status:Retrieving directory listing of "/"...
> >> Command:CWD /
> >> Response:250 OK. Current directory is /
> >> Command:PWD
> >> Response:257 "/" is your current location
> >> Command:TYPE I
> >> Response:200 TYPE is now 8-bit binary
> >> Command:PASV
> >> Response:227 Entering Passive Mode (,141,8).
> >> Command:MLSD
> >> Response:150 Accepted data connection
> >> Error:GnuTLS error -15: An unexpected TLS packet was received.
> >> Error:The data connection could not be established:
> >> ECONNABORTED
> >> -
> >> Connection aborted
> >> Response:226 72 matches total
> >> Error:Failed to retrieve directory listing
> >>
> >> at which point the connection seems to be severed by FileZilla.
> >>
> >> When I try a command line ftp session, I also find that I cannot do
> >> an
> >> "ls" after logging in.
> >>
> >> However I can connect from my server which is running
> >> Debian/Buster.
> >> Something seems to be going wrong with GnuTLS once the connection
> >> is
> >> established on Bullseye. This is a new behaviour as it wasn't doing
> >> this
> >> last week.
> >
> > Hi Gary,
> >
> > I can confirm this issue.
> >
> > Please file a bug report against filezilla and it will be looked
> > into
> > by myself once 3.52.0.5 has transitioned into unstable (imminent).
> >
> > Regards
> >
> > Phil
>
> I don't think it is just a FileZilla problem as it also seems to crop
> up with the command-line ftp program.

You might also try lftp. But since it seems to be a TLS problem the
result might be the same.
Does TLS work when you download mail with your mail-client?

Kind regards
Eike
--
Eike Lantzsch ZP6CGE

FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Gary Dale]

I'm running Debian/Bullseye on an AMD64 machine.

I'm trying to update a site using FileZilla with the same settings I've 
been using but cannot get a connection. I've tried this on several sites 
with the same results. Here's the FileZilla dialogue of a session 
connect attempt:


Status:    Resolving address of 
Status:    Connecting to :21...
Status:    Connection established, waiting for welcome message...
Status:    Initializing TLS...
Status:    Verifying certificate...
Status:    TLS connection established.
Status:    Server does not support non-ASCII characters.
Status:    Logged in
Status:    Retrieving directory listing of "/"...
Command:    CWD /
Response:    250 OK. Current directory is /
Command:    PWD
Response:    257 "/" is your current location
Command:    TYPE I
Response:    200 TYPE is now 8-bit binary
Command:    PASV
Response:    227 Entering Passive Mode (,141,8).
Command:    MLSD
Response:    150 Accepted data connection
Error:    GnuTLS error -15: An unexpected TLS packet was received.
Error:    The data connection could not be established: ECONNABORTED - 
Connection aborted

Response:    226 72 matches total
Error:    Failed to retrieve directory listing

at which point the connection seems to be severed by FileZilla.

When I try a command line ftp session, I also find that I cannot do an 
"ls" after logging in.


However I can connect from my server which is running Debian/Buster. 
Something seems to be going wrong with GnuTLS once the connection is 
established on Bullseye. This is a new behaviour as it wasn't doing this 
last week.

Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye

[Philip Wyett]

On Tue, 2021-01-12 at 21:27 -0500, Gary Dale wrote:
> I'm running Debian/Bullseye on an AMD64 machine.
> 
> I'm trying to update a site using FileZilla with the same settings
> I've 
> been using but cannot get a connection. I've tried this on several
> sites 
> with the same results. Here's the FileZilla dialogue of a session 
> connect attempt:
> 
> Status:Resolving address of 
> Status:Connecting to :21...
> Status:Connection established, waiting for welcome message...
> Status:Initializing TLS...
> Status:Verifying certificate...
> Status:TLS connection established.
> Status:Server does not support non-ASCII characters.
> Status:Logged in
> Status:Retrieving directory listing of "/"...
> Command:CWD /
> Response:250 OK. Current directory is /
> Command:PWD
> Response:257 "/" is your current location
> Command:TYPE I
> Response:200 TYPE is now 8-bit binary
> Command:PASV
> Response:227 Entering Passive Mode (,141,8).
> Command:MLSD
> Response:150 Accepted data connection
> Error:GnuTLS error -15: An unexpected TLS packet was received.
> Error:The data connection could not be established: ECONNABORTED
> - 
> Connection aborted
> Response:226 72 matches total
> Error:Failed to retrieve directory listing
> 
> at which point the connection seems to be severed by FileZilla.
> 
> When I try a command line ftp session, I also find that I cannot do
> an 
> "ls" after logging in.
> 
> However I can connect from my server which is running Debian/Buster. 
> Something seems to be going wrong with GnuTLS once the connection is 
> established on Bullseye. This is a new behaviour as it wasn't doing
> this 
> last week.
> 
> 

Hi Gary,

I can confirm this issue.

Please file a bug report against filezilla and it will be looked into
by myself once 3.52.0.5 has transitioned into unstable (imminent).

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


signature.asc
Description: This is a digitally signed message part

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

[Andrei POPESCU]

On Lu, 30 mar 20, 12:47:45, Martin wrote:
> On Sun, 29 Mar 2020 at 20:59, Andrei POPESCU  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


signature.asc
Description: PGP signature

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

[Martin]

On Sun, 29 Mar 2020 at 20:59, Andrei POPESCU  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

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

[Andrei POPESCU]

On Du, 29 mar 20, 16:40:03, Martin wrote:
> On Sun, 29 Mar 2020 at 13:33, Andrei POPESCU  wrote:
> >
> > > Pinned packages:
> > >  libpython3.8-minimal -> 3.8.2-1 with priority -3
> > >  libcrypt1 -> 1:4.4.15-1 with priority -3
> > >  libcrypt1:i386 -> 1:4.4.15-1 with priority -3
> > >  powertop -> 2.10-1+b1 with priority 3
> > >  openssh-server -> 1:8.1p1-1 with priority 3
> > >  grub-efi-amd64 -> 2.04-3 with priority 3
> > >  isc-dhcp-client -> 4.4.1-2 with priority 3
> >
> > 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


signature.asc
Description: PGP signature

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

[Martin]

On Sun, 29 Mar 2020 at 13:33, Andrei POPESCU  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 -3
> >  libcrypt1 -> 1:4.4.15-1 with priority -3
> >  libcrypt1:i386 -> 1:4.4.15-1 with priority -3
> >  powertop -> 2.10-1+b1 with priority 3
> >  openssh-server -> 1:8.1p1-1 with priority 3
> >  grub-efi-amd64 -> 2.04-3 with priority 3
> >  isc-dhcp-client -> 4.4.1-2 with priority 3
>
> 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

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

[Andrei POPESCU]

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 -3
>  libcrypt1 -> 1:4.4.15-1 with priority -3
>  libcrypt1:i386 -> 1:4.4.15-1 with priority -3
>  powertop -> 2.10-1+b1 with priority 3
>  openssh-server -> 1:8.1p1-1 with priority 3
>  grub-efi-amd64 -> 2.04-3 with priority 3
>  isc-dhcp-client -> 4.4.1-2 with priority 3

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


signature.asc
Description: PGP signature

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

[Martin]

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  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

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

[Martin]

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 -3
 libcrypt1 -> 1:4.4.15-1 with priority -3
 libcrypt1:i386 -> 1:4.4.15-1 with priority -3
 powertop -> 2.10-1+b1 with priority 3
 openssh-server -> 1:8.1p1-1 with priority 3
 grub-efi-amd64 -> 2.04-3 with priority 3
 isc-dhcp-client -> 4.4.1-2 with priority 3


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 

Running apt update makes no difference to that.

Best regards,
Marty

On Sun, 29 Mar 2020 at 07:56, Andrei POPESCU  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

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

[Andrei POPESCU]

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


signature.asc
Description: PGP signature

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

[Martin]

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.