Problems with testing repos?

Forum Forums Official Releases antiX-17 “Heather Heyer” Problems with testing repos?

  • This topic has 9 replies, 4 voices, and was last updated Jan 17-10:11 am by skidoo.
Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #31673
    Member
    dirkddirkd

    I have been using Antix17 for about three years now, without a single glitch, using the ‘testing’ branch of Debian. But now, all of a sudden, in the last few weeks, it seems to be breaking down. For mysterious reasons, the Mirage photo viewer has disappeared from my system, and it seems no longer present in the repos either. My HP Deskjet 5550 printer is no longer functioning, with complaints of a missing filter and Synaptic gives error messages about ‘release files’ that are no longer present in the repos.

    Of course, I have considered upgrading to Antix19, but I hate being forced to do so in a hurry, in stead of doing it when I have ample time. Can I fix these problems without upgrading? Or am I paying the price for using ‘testing’?

    #31674
    Member
    Avatarskidoo

    To correct the ‘release files’ issue on your system, follow the quick steps in this linked post:
    https://www.antixforum.com/forums/topic/expkeysig-error/

    re: mirage
    nothing has changed ~~ the identical version is available from debian stretch and buster repositories.
    After freshening your release files (a once in a blue moon procedure), try reinstalling mirage & post back to say how it goes.

    “HP Deskjet 5550 printer is no longer functioning, with complaints of a missing filter”

    filter? To me, that suggests a program-specific problem. Test whether printing from some other (different) application is successful & post back to share the result.

    #31676
    Member
    dirkddirkd

    Thank you, Skidoo.

    I had seen this post before, but since I never actually saw EXPKEYSIG error, I didn’t bother. I followed the procedure and all went well.

    $ wget ‘http://repo.antixlinux.com/antix-archive-keyring.asc’
    –2020-01-14 11:04:11– http://repo.antixlinux.com/antix-archive-keyring.asc
    Resolving repo.antixlinux.com (repo.antixlinux.com)… 72.143.17.194
    Connecting to repo.antixlinux.com (repo.antixlinux.com)|72.143.17.194|:80… connected.
    HTTP request sent, awaiting response… 200 OK
    Length: 4053 (4.0K) [text/plain]
    Saving to: ‘antix-archive-keyring.asc’

    antix-archive-keyri 100%[===================>] 3.96K –.-KB/s in 0.003s

    2020-01-14 11:04:11 (1.27 MB/s) – ‘antix-archive-keyring.asc’ saved [4053/4053]

    dd@dokux:~
    $ sudo apt-key add antix-archive-keyring.asc
    [sudo] password for dd:
    OK
    dd@dokux:~
    $ sudo apt-get update
    Hit:1 http://files.eid.belgium.be/debian stretch InRelease
    Hit:2 http://ftp.be.debian.org/debian stretch-updates InRelease
    Hit:3 http://files2.eid.belgium.be/debian stretch InRelease
    Hit:4 http://ftp.be.debian.org/debian testing InRelease
    Ign:5 http://dl.google.com/linux/chrome/deb stable InRelease
    Hit:6 http://download.virtualbox.org/virtualbox/debian stretch InRelease
    Hit:7 http://security.debian.org testing-security InRelease
    Hit:8 http://nl.mxrepo.com/antix/testing testing InRelease
    Hit:9 http://dl.google.com/linux/chrome/deb stable Release
    Reading package lists… Done

    The printer problem was not application specific, it seems. Couldn’t even print a test page. But re-installing the printer (and removing the old one) seems to have solved it. Should have thought about that before, but I was thinking that maybe all these problems were somehow connected.

    Mirage is still causing problems. Here’s how it looks like in Synaptic. I tried to do a complete removal but it wouldn’t let me, with the following error messages

    E: cups-daemon: subprocess installed post-installation script returned error exit status 1
    E: cups-core-drivers: dependency problems – leaving unconfigured
    E: cups: dependency problems – leaving unconfigured
    E: printer-driver-gutenprint: dependency problems – leaving unconfigured
    E: printer-driver-cups-pdf: dependency problems – leaving unconfigured
    E: printer-driver-hpcups: dependency problems – leaving unconfigured

    Attachments:
    #31682
    Forum Admin
    anticapitalistaanticapitalista

    You should not have stretch and testing repos enabled.
    Either stick to stretch (too late it seems) or use only testing.

    Then do apt-get update && apt-get upgrade

    Philosophers have interpreted the world in many ways; the point is to change it.

    antiX with runit - leaner and meaner.

    #31683
    Forum Admin
    anticapitalistaanticapitalista

    BTW testing is beyond antiX-19 ie uses newer packages.
    Some apps are also being removed from testing since testing no longer supports python2.7
    That is why mirage (and others) is/are no longer in the Debian testing repos,

    Philosophers have interpreted the world in many ways; the point is to change it.

    antiX with runit - leaner and meaner.

    #31684
    Member
    dirkddirkd

    Oh, that explains everything I guess… Thanks! Ditching Python2.7 seems a big change. I’ll keep that in mind when upgrading to Antix19.

    I think I can live without Mirage for a while, now that I am reassured about why the problem came up. I still have Feh, and even Picasa if needs be.

    • This reply was modified 1 month, 1 week ago by dirkd.
    #31734
    Member
    Avatarskidoo

    I have been using Antix17 for about three years now, without a single glitch, using the ‘testing’ branch of Debian. But now, all of a sudden, in the last few weeks, it seems to be breaking down

    ouch. Sorry, I missed that important detail.

    #31786
    Member
    fungalnetfungalnet

    Any ideas why python2 can’t coexist with python3 in Debian?

    #31797
    Member
    Avatarskidoo

    WHY == debian policy

    Technically, nothing prevents python 2.7 + python 3.xx from coexisting on a system.
    ( same is true for perl 6 Raku + perl 5.28 )
    They can coexist, across years have coexisted, on debian-based systems.

    Anyone using a debian-based system that is tracking {“future Debian11 Bullseye”, aka testing} repositories should bear in mind that maintainers are abandoning / removing packages which depend on python2. Ultimately, prior to the release of Debian 11, we can expect that the python-defaults https://tracker.debian.org/pkg/python-defaults will be preconfigured with python3 as the default python engine _and_ we should probably expect that a debian-packaged python2 engine will be absent from the debian repositories.

    an excerpt from https://debian-python.readthedocs.io/en/latest/debian-policy.html
    (© Copyright 2015, Barry Warsaw. Revision f6463120.)

    On the move to Python 3

    Debian currently supports two Python stacks, one for Python 2 and one for Python 3. The long term goal for Debian is to reduce this to one stack, dropping the Python 2 stack at some time.

    PEP 404 states that no more major Python 2 releases are planned, although the last released major version 2.7 will see some extended support, documented in PEP 466.

    Packages in Debian should use Python 3 if Python 3 is supported. New packages should use Python 3 from the initial upload, new upstream versions for existing packages should use Python 3 if the new upstream version supports it.

    Programs should use Python 3, and should not be packaged for Python 2 as well. Python 3 should be used for the packaging if the packaging scripts use Python.
    Python libraries should be always packaged for Python 3 if supported. Python 2 libraries should be packaged, if applications found in the reverse dependencies are not yet supported by Python 3.
    Existing Python 2 libraries should not be dropped before the last reverse dependency is removed.

    Python packaging
    Versions

    At any given time, the binary package python will represent the current default Debian Python version. The binary package python3 will represent the current Debian Python 3 version. As far as is reasonable, python and python3 should be treated as separate runtime systems with minimal interdependencies. In some cases, Python policy explicitly references Python helper programs such as python-support and python-central. None of these references apply to Python 3. It is a design goal to fully specify required interfaces and functions in policy for Python 3 and to avoid enshrining specific implementation details in policy. Except as noted, policy for Python 3 is the same as Python with the addition of the version number as needed to distinguish them.

    The default Debian Python version should always be the latest stable upstream release that can be fully integrated in the distribution. There may be newer supported or unsupported versions included in the distribution if they are not fully integrated for a particular release.

    Apart from the default version, legacy versions of Python or beta versions of future releases may be included as well in the distribution, as long as they are needed by other packages, or as long as it seems reasonable to provide them. (Note: For the scope of this document, Python versions are synonymous to feature releases, i.e. Python 2.7 and 2.7.1 are sub-minor versions of the same Python version 2.7, but Python 2.6 and 2.7 are indeed different versions.) …

    #31798
    Member
    Avatarskidoo

    pasting here a draft that I started back on Jan 14.
    I was unsure, and still am, what the intended “point” of such a post will be.

    .
    .
    .
    .
    .
    _____________________________

    Because python3 -driven programs each have a considerably larger memory footprint
    (same can be noted for programs compiled to use gtk3 toolkit)
    I had hoped we could collectively formulate a plan to avoid the “forced deprecation” resulting from dropped packages.

    perl5.28 and python2.7 and the various python-* packages (and gtk2 packages) will remain accessible from debian9 repositories thru 2024, but it would eventually be necessary to build the packages from source and serve ’em from antiX repository. Since those “deprecated” packages will seldom, if ever, receive updates from upstream elsewhere, we can expect they should not demand frequent “maintenance”.

    Adopting a full set of the (too) many perl-* and python-* packages is probably infeasable. I am advocating use of in-house versions of select packages, primarily those necessary to support the lightweight programs which have traditionally been preinstalled in antiX. Also, wherever feasible (as in, just involves setting a compile-time option) I would advocate supplying in-house versions of built-against-gtk2 programs: spaceFM, lxterminal and / or roxterm, lxappearance…

    Is mirage such a great program that we cannot find a suitable replacement?
    That question, framed that way, misses the point.
    Does ANY suitably lightweight (memory footprint) python3+gtk3 alternative to mirage exist?

    There will can never be a gtk3 equivalent to lxappearance.
    Increasingly, across versions, gtk3 themes are becoming “compiled” balls of spaghetti code plus size-scaled assets.
    In order to at least see (preview) gtk3 themes while tweaking them, I have forked / hacked awf-gtk

    [Date: Sun, 05 Jan 2020 07:26:46 +0000] [ftpmaster: Scott Kitterman]
    https://ftp-master.debian.org/removals.txt
    Removed the following packages from unstable:

    cherrytree | 0.37.6-1.1 | source, all
    Closed bugs: 947338
    ——————- Reason ——————-
    RoQA; python2-only; depends on pygtk/gtksourceview, deprecated; upstream is rewriting it in C++, so there’s no hope for a py3k port

Viewing 10 posts - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.