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

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

Installing old/deprecated packages

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

Contents

  Installing old/deprecated packages riveravaldez <riveravaldezmail@gmail.com> - 2021-09-05 05:20 +0200
    Re: Installing old/deprecated packages Linux-Fan <Ma_Sys.ma@web.de> - 2021-09-05 14:50 +0200
      Re: Installing old/deprecated packages riveravaldez <riveravaldezmail@gmail.com> - 2021-09-06 05:50 +0200
        Re: Installing old/deprecated packages Linux-Fan <Ma_Sys.ma@web.de> - 2021-09-06 16:10 +0200
          Re: Installing old/deprecated packages Andrei POPESCU <andreimpopescu@gmail.com> - 2021-09-12 10:30 +0200

#239696 — Installing old/deprecated packages

Hi,

I have this `phwmon.py`[1] which I use with fluxbox to have a couple
of system monitors at hand. It depends on some python2 packages, so
stopped working some time ago.
I've just made it work, installing manually (# apt-get install packages.deb)
this packages that I've downloaded from Debian OldStable official archives:

python-psutil
python-is-python2 (this is in fact in Testing)
python-numpy
python-pkg-resources
python-cairo
libffi6
python-gobject-2
python-gtk2

Therefore, my questions:

How safe is this?

Is it better to install them as I did, or adding the corresponding line in
sources.list and pull them from there? Is there any difference?

Thanks a lot in advance and sorry (I previously asked this in another
thread...)

Kind regards!

1] https://gitlab.com/o9000/phwmon

[toc] | [next] | [standalone]

#239710

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

riveravaldez writes:

> I have this `phwmon.py`[1] which I use with fluxbox to have a couple
> of system monitors at hand. It depends on some python2 packages, so
> stopped working some time ago.

Any specific reason for preferring `phwmon.py` over a tool like `conky`?

> I've just made it work, installing manually (# apt-get install packages.deb)
> this packages that I've downloaded from Debian OldStable official archives:
>
> python-psutil
> python-is-python2 (this is in fact in Testing)
> python-numpy
> python-pkg-resources
> python-cairo
> libffi6
> python-gobject-2
> python-gtk2
>
> Therefore, my questions:
>
> How safe is this?

IMHO it's pretty OK because that is quite similar to having upgraded from an  
old system with the legacy packages installed to a new release where they  
are no longer part of.

> Is it better to install them as I did, or adding the corresponding line in
> sources.list and pull them from there? Is there any difference?

There are differences: Whenever you install packages, you may not notice  
that they are only avaliable in old releases because the output of
`apt-cache search` and similar tools will include old packages. Also,  
running a release with stable+oldstable in sources.list is less common than  
the other case: stable in sources.list and some oldstable packages leftover  
from upgrades. In case bugs are fixed in the oldstable package, you will get  
them automatically if you have them in sources.list.

My personal choice would be to install the packages without adding the  
oldstable repositories as to be reminded that they are obsolete and are  
likely to stop working in the future.

Be aware that libraries like `python-psutil` may not work with newer  
kernels. Here (on oldstable with a backported kernel 5.10) the script would  
not run due to excess fields reported by the kernel for disk statistics:

| $ ./phwmon.py 
| Traceback (most recent call last):
|   File "./phwmon.py", line 341, in <module>
|     HardwareMonitor()
|   File "./phwmon.py", line 128, in __init__
|     self.initDiskIo()
|   File "./phwmon.py", line 274, in initDiskIo
|     v = psutil.disk_io_counters(perdisk=False)
|   File "/usr/lib/python2.7/dist-packages/psutil/__init__.py", line 2131, in disk_io_counters
|     rawdict = _psplatform.disk_io_counters(**kwargs)
|   File "/usr/lib/python2.7/dist-packages/psutil/_pslinux.py", line 1121, in disk_io_counters
|     for entry in gen:
|   File "/usr/lib/python2.7/dist-packages/psutil/_pslinux.py", line 1094, in read_procfs
|     raise ValueError("not sure how to interpret line %r" % line)
| ValueError: not sure how to interpret line ' 259       0 nvme0n1 42428 17299 3905792 8439 49354 7425 3352623 15456 0 48512 26929 43429 11 476835656 3033 0 0\n'

See also: https://forums.bunsenlabs.org/viewtopic.php?id=967

[...]

> [1] https://gitlab.com/o9000/phwmon

Btw. it looks as if `python-is-python2` is not needed for this to run?  
`phwmon.py` states `python2` explicitly.

HTH
Linux-Fan

öö

PS: If you are interested in my thoughts on status bars, see here:
    https://masysma.lima-city.de/32/i3bar.xhtml

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

#239732

On 9/5/21, Linux-Fan <Ma_Sys.ma@web.de> wrote:
> riveravaldez writes:
>
>> I have this `phwmon.py`[1] which I use with fluxbox to have a couple
>> of system monitors at hand. It depends on some python2 packages, so
>> stopped working some time ago.
>
> Any specific reason for preferring `phwmon.py` over a tool like `conky`?

Hi, Linux-Fan, thanks a lot for your answers.

`conky` is great, but you have to see the desktop to see `conky`, and I
tend to work with maximized windows.
Monitors like `phwmon.py` or the ones that come by default with IceWM
for instance are permanently visible in the sys-tray/taskbar (no matter
you're using fluxbox, openbox+tint2, etc.). That's the only reason:
minimal and visible.

>> I've just made it work, installing manually (# apt-get install
>> packages.deb)
>> this packages that I've downloaded from Debian OldStable official
>> archives:
>>
>> python-psutil
>> python-is-python2 (this is in fact in Testing)
>> python-numpy
>> python-pkg-resources
>> python-cairo
>> libffi6
>> python-gobject-2
>> python-gtk2
>>
>> Therefore, my questions:
>>
>> How safe is this?
>
> IMHO it's pretty OK because that is quite similar to having upgraded from an
> old system with the legacy packages installed to a new release where they
> are no longer part of.

Thanks!

>> Is it better to install them as I did, or adding the corresponding line
>> in
>> sources.list and pull them from there? Is there any difference?
>
> There are differences: Whenever you install packages, you may not notice
> that they are only avaliable in old releases because the output of
> `apt-cache search` and similar tools will include old packages. Also,
> running a release with stable+oldstable in sources.list is less common than
> the other case: stable in sources.list and some oldstable packages leftover
> from upgrades. In case bugs are fixed in the oldstable package, you will get
> them automatically if you have them in sources.list.
>
> My personal choice would be to install the packages without adding the
> oldstable repositories as to be reminded that they are obsolete and are
> likely to stop working in the future.

Thanks again. Very informative and educational.
When you say 'as to be reminded that they are obsolete', how/when/where
the system will remind me this?, will it be?

> Be aware that libraries like `python-psutil` may not work with newer
> kernels. Here (on oldstable with a backported kernel 5.10) the script would
>
> not run due to excess fields reported by the kernel for disk statistics:
>
> | $ ./phwmon.py
> | Traceback (most recent call last):
> |   File "./phwmon.py", line 341, in <module>
> |     HardwareMonitor()
> |   File "./phwmon.py", line 128, in __init__
> |     self.initDiskIo()
> |   File "./phwmon.py", line 274, in initDiskIo
> |     v = psutil.disk_io_counters(perdisk=False)
> |   File "/usr/lib/python2.7/dist-packages/psutil/__init__.py", line 2131,
> in disk_io_counters
> |     rawdict = _psplatform.disk_io_counters(**kwargs)
> |   File "/usr/lib/python2.7/dist-packages/psutil/_pslinux.py", line 1121,
> in disk_io_counters
> |     for entry in gen:
> |   File "/usr/lib/python2.7/dist-packages/psutil/_pslinux.py", line 1094,
> in read_procfs
> |     raise ValueError("not sure how to interpret line %r" % line)
> | ValueError: not sure how to interpret line ' 259       0 nvme0n1 42428
> 17299 3905792 8439 49354 7425 3352623 15456 0 48512 26929 43429 11 476835656
> 3033 0 0\n'

Yes, indeed. I didn't mentioned it but I had to "fix" that as seen in:
https://gitlab.com/o9000/phwmon/-/issues/3#note_374558691

Essentially, convert:

`elif flen == 14 or flen == 18:`

to

`elif flen == 14 or flen == 18 or flen == 20:`

In /usr/lib/python2.7/dist-packages/psutil/_pslinux.py

Supposedly shouldn't be problematic, but I'm not sure. Any
comment on this?

> See also: https://forums.bunsenlabs.org/viewtopic.php?id=967

Thanks. Checked.

> [...]
>
>> [1] https://gitlab.com/o9000/phwmon
>
> Btw. it looks as if `python-is-python2` is not needed for this to run?
> `phwmon.py` states `python2` explicitly.

Probably, not sure. But if I'm remembering properly it was pulled as
a dependency's dependency.

> HTH
> Linux-Fan
>
> öö
>
> PS: If you are interested in my thoughts on status bars, see here:
>     https://masysma.lima-city.de/32/i3bar.xhtml

Thanks a lot, LF!
I'm checking it right now. Very interesting.

Best regards.

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

#239746

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

riveravaldez writes:

> On 9/5/21, Linux-Fan <Ma_Sys.ma@web.de> wrote:
> > riveravaldez writes:
> >
> >> I have this `phwmon.py`[1] which I use with fluxbox to have a couple
> >> of system monitors at hand. It depends on some python2 packages, so
> >> stopped working some time ago.
> >
> > Any specific reason for preferring `phwmon.py` over a tool like `conky`?
>
> Hi, Linux-Fan, thanks a lot for your answers.
>
> `conky` is great, but you have to see the desktop to see `conky`, and I
> tend to work with maximized windows.
> Monitors like `phwmon.py` or the ones that come by default with IceWM
> for instance are permanently visible in the sys-tray/taskbar (no matter
> you're using fluxbox, openbox+tint2, etc.). That's the only reason:
> minimal and visible.

That makes sense. In case you still want to try conky, there might be means  
to make it appear as a dedicated panel that is not overlapped by maximized  
windows, although I did not test that back when I was using Fluxbox (now on  
i3). See e.g.

https://superuser.com/questions/565784/can-conky-remain-always-visible-alongside-other-windows
https://forum.salixos.org/viewtopic.php?t=1166

[...]

> > There are differences: Whenever you install packages, you may not notice
> > that they are only avaliable in old releases because the output of
> > `apt-cache search` and similar tools will include old packages. Also,
> > running a release with stable+oldstable in sources.list is less common than
> > the other case: stable in sources.list and some oldstable packages leftover
> > from upgrades. In case bugs are fixed in the oldstable package, you will  
> > get them automatically if you have them in sources.list.
> >
> > My personal choice would be to install the packages without adding the
> > oldstable repositories as to be reminded that they are obsolete and are
> > likely to stop working in the future.
>
> Thanks again. Very informative and educational.
> When you say 'as to be reminded that they are obsolete', how/when/where
> the system will remind me this?, will it be?

There is no automatism for this that I am aware of. There are tools like  
`deborphan` and `aptitude search ~o` that may tell you about them. The  
release notes recommend proactively removing obsolete packages:

https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html#for-next

> > Be aware that libraries like `python-psutil` may not work with newer
> > kernels. Here (on oldstable with a backported kernel 5.10) the script would
> >
> > not run due to excess fields reported by the kernel for disk statistics:

[...]

> Yes, indeed. I didn't mentioned it but I had to "fix" that as seen in:
> https://gitlab.com/o9000/phwmon/-/issues/3#note_374558691
>
> Essentially, convert:
>
> `elif flen == 14 or flen == 18:`
>
> to
>
> `elif flen == 14 or flen == 18 or flen == 20:`
>
> In /usr/lib/python2.7/dist-packages/psutil/_pslinux.py
>
> Supposedly shouldn't be problematic, but I'm not sure. Any
> comment on this?

It's pretty much how I would go about it for a short-term solution. Any  
upgrade/reinstallation of the respective python package may revert your  
change. I would not mind that too much, given that there will not be any  
"unexpected" upgrades to the package while its repositories are not enabled  
in sources.list :)

[...]

> > PS: If you are interested in my thoughts on status bars, see here:
> >     https://masysma.lima-city.de/32/i3bar.xhtml
>
> Thanks a lot, LF!
> I'm checking it right now. Very interesting.

You're welcome. If anything is unclear/wrong there, feel free to tell me  
directly via e-mail :)

HTH
Linux-Fan

öö

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

#239906

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

On Lu, 06 sep 21, 16:04:29, Linux-Fan wrote:
> riveravaldez writes:
> 
> > On 9/5/21, Linux-Fan <Ma_Sys.ma@web.de> wrote:
> > >
> > > My personal choice would be to install the packages without adding the
> > > oldstable repositories as to be reminded that they are obsolete and are
> > > likely to stop working in the future.
> > 
> > Thanks again. Very informative and educational.
> > When you say 'as to be reminded that they are obsolete', how/when/where
> > the system will remind me this?, will it be?
> 
> There is no automatism for this that I am aware of. There are tools like
> `deborphan` and `aptitude search ~o` that may tell you about them.

In aptitude's interactive mode there is a special section for them, that 
only shows up if there are any. Does this count as "automatism"? :)

For completeness, obsolete packages can also happen within the same 
release, e.g. old linux-image packages. APT is configured to keep one 
older version by default, the others are fair game for 'autoremove'.

> The release notes recommend proactively removing obsolete packages:
> 
> https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html#for-next

Yes, though some care might be needed, depending on the situation[1].

E.g. leafpad was replaced by mousepad in buster. If you just execute the 
'aptitude purge ~o' aptitude might want to remove the entire LXDE 
environment, because the lxde metapackage in buster has
'Depends: leafpad | mousepad'.

The solution in this particular case is to tell aptitude to install (and 
set as 'automatic') mousepad in the same run[2].

[1] Always inspect the list of proposed removals by apt/itude carefully 
before confirming. In case it looks wrong just ask on the list with the 
copy-paste of the full output.
[2] There are several methods to do that, depending on your familiarity 
with aptitude.

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

[toc] | [prev] | [standalone]

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

csiph-web