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

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

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

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

Contents

  FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Gary Dale <gary@extremeground.com> - 2021-01-13 03:30 +0100
    Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Philip Wyett <philip.wyett@kathenas.org> - 2021-01-13 05:20 +0100
      Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Gary Dale <gary@extremeground.com> - 2021-01-13 20:50 +0100
        Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye Eike Lantzsch <zp6cge@gmx.net> - 2021-01-13 21:00 +0100
          Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Gary Dale <gary@extremeground.com> - 2021-01-13 21:40 +0100
            Re: FileZilla / ftp / GnuTLS error connecting to sites with Testing/Bullseye Eike Lantzsch <zp6cge@gmx.net> - 2021-01-13 22:00 +0100
              Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Gary Dale <gary@extremeground.com> - 2021-01-14 01:50 +0100
                Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye songbird <songbird@anthive.com> - 2021-01-20 16:50 +0100
                  Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Philip Wyett <philip.wyett@kathenas.org> - 2021-01-20 17:40 +0100
                    Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye songbird <songbird@anthive.com> - 2021-01-20 21:00 +0100
                  Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Gary Dale <gary@extremeground.com> - 2021-01-28 16:20 +0100
                    Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye David Wright <deblis@lionunicorn.co.uk> - 2021-01-28 17:10 +0100
                      Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Gary Dale <gary@extremeground.com> - 2021-01-28 17:40 +0100
                      Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Gary Dale <gary@extremeground.com> - 2021-02-10 22:20 +0100
                        Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye songbird <songbird@anthive.com> - 2021-02-12 15:20 +0100
                          Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Gary Dale <gary@extremeground.com> - 2021-02-12 18:30 +0100
                            Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Greg Wooledge <wooledg@eeg.ccf.org> - 2021-02-12 19:30 +0100
                              Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye songbird <songbird@anthive.com> - 2021-02-12 22:20 +0100
                            Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Frank <zuiderduin@gmx.com> - 2021-02-12 20:20 +0100
                              Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Paul Scott <waterhorse@ultrasw.com> - 2021-02-12 20:40 +0100
                                Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Frank de Bruijn <frank.de.bruijn@ziggo.nl> - 2021-02-12 22:20 +0100
                                Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Gary Dale <gary@extremeground.com> - 2021-02-12 22:30 +0100
                              Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Gary Dale <gary@extremeground.com> - 2021-02-12 22:20 +0100
                                Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Frank <zuiderduin@gmx.com> - 2021-02-13 13:30 +0100
                                  Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye songbird <songbird@anthive.com> - 2021-02-13 15:40 +0100
                                    Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Frank <zuiderduin@gmx.com> - 2021-02-13 17:30 +0100
                            Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye songbird <songbird@anthive.com> - 2021-02-12 22:20 +0100
                              Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Gary Dale <gary@extremeground.com> - 2021-02-12 23:10 +0100
                                Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Andrei POPESCU <andreimpopescu@gmail.com> - 2021-02-13 09:10 +0100
                                  Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye songbird <songbird@anthive.com> - 2021-02-13 15:30 +0100
                                  Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Gary Dale <gary@extremeground.com> - 2021-02-16 22:50 +0100
                                    Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Philip Wyett <philip.wyett@kathenas.org> - 2021-02-16 23:10 +0100
                                      Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Gary Dale <gary@extremeground.com> - 2021-02-17 18:20 +0100
                                    Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Andrei POPESCU <andreimpopescu@gmail.com> - 2021-02-17 11:00 +0100
                                      Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye Gary Dale <gary@extremeground.com> - 2021-02-17 18:20 +0100
    Re: FileZilla / ftp / GnuTLS error connecting to sites with  Testing/Bullseye songbird <songbird@anthive.com> - 2021-01-14 00:10 +0100

Page 2 of 2 — ← Prev page 1 [2]

#231667

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

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

#231674

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

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

#231669

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.

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

#231685

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.

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

#231693

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

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

#231696

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

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

#231668

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

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

#231676

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.

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

#231683

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

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

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

#231691

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

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

#231767

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.

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

#231768

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

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

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

#231808

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.

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

#231786

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

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

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

#231807

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.

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

#230634

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web