Search Results for 'ppa'

[Member DaveW]

Caprea,
I followed your suggestion, and the procedure given in the “upgrading-antix-17-to-antix-19” link.
The procedure was very well explained and straight forward. However, I ran into a snag at step #5.

The system said it could not install libpam-elogind-compat due to a held package which had something to do with an incorrect version of libpam-elogind.
So, I tried “$ apt purge libpam-elogind ” and followed that with “$ apt-get install libpam-elogind ” Both commands appeared to finish successfully.

During the ‘purge’ there was a line: “removing systemd”. So, I thought, perhaps that would take care of the problem.
But when all of the steps were finished, the system did not fully reboot. The boot dialogue proceeded, but then hung. I don’t recall the last few lines of the dialogue, but there was no indication of a failure, before the screen went blank.

Perhaps there would have been a way to salvage it, but in the end, it was quicker to re-install antix 17 from LiveUSB, and refresh the /home directory with the backups for that computer. So, it’s up and running… and apparmor is working, now.

I think my original problem (which prevented install of apparmor) may have been caused, several months ago, when I must have installed Calibre (an ebook reader) from a Testing repository. The installed version was much higher than the one in the Stretch repos, and it probably came with some incompatible dependencies.
One issue that remains is that the Calibre version in the Stretch repos (2.75.1+dfsg-1) seems to be broken (according to Synaptic). This is not a big deal, since I have another ebook reader installed, and I have not made use of Calibre since installing it, on the previous system (except to test it right after the install).

So… it’s up and running.
Thank you, both, Skidoo and Caprea, for your help!

[Anonymous]

___________________________

caprea has a great eye for catching details.
perl-base 5.28.1-6 (installed) depends on libc6 (greaterthanorequal v2.28)
and neither of those are present in stretch repos
and there’s probably “no way back” now that the system contains libc6 v2.28

The pasted output from apt policy shows a pin priority of 100. Forensically, is this a clue toward figuring out what (apparently), at some point, temporarily changed the debian.list contents?

Stock antiX has no apt preferences rule(s) specifying “Pin-Priority: 100”, right?
I doubt that any operation performed via the packageinstaller utility would have caused a “Pin-Priority: 100” rule to be created; on the other hand, I’m not entirly confident that we can ruleout that possibility.

DaveW, if you have used any of the frighteningly-polular “curl | sudo bash” installers (Golang, python pip, pypy, et al), possibly an installer “did ya a favor”(!) and temporarily enabled debian sid repository to grab the latest-greatest version of some lib (and oops, oh well, that lib pkg has a libc6 2.28+ dependency…)

[Anonymous]

__________________________

caprea has a great eye for catching details.
perl-base 5.28.1-6 (installed) depends on libc6 >= 2.28
and neither of those are present in stretch repos
and there’s probably “no way back” now that the system contains libc6 v2.28

The pasted output from apt policy shows a pin priority of 100.
Forensically, is this a clue toward figuring out what (apparently),
at some point, temporarily changed the debian.list contents?

Stock antiX has no apt preferences rule(s) specifying “Pin-Priority: 100”, right?
I doubt that any operation performed via the packageinstaller utility would have caused a “pin-priority: 100” rule to be created; on the other hand, I’m not entirly confident that we can ruleout that possibility.

DaveW, if you have used any of the frighteningly-polular “curl | sudo bash” installers (Golang, python pip, pypy, et al), possibly an installer “did ya a favor”(!) and temporarily enabled debian sid repository to grab the latest-greatest version of some lib (and oops, oh well, that lib pkg has a libc6 >=2.28 dependency…)

[Anonymous]

caprea has a great eye for catching details.
perl-base 5.28.1-6 (installed) depends on libc6 >= 2.28
and neither of those are present in stretch repos
and there’s probably “no way back” now that the system contains libc6 v2.28

The pasted output from apt policy shows a pin priority of 100.
Forensically, is this a clue toward figuring out what (apparently),
at some point, temporarily changed the debian.list contents?

Stock antiX has no apt preferences rule(s) specifying “Pin-Priority: 100”, right?
I doubt that any operation performed via the packageinstaller utility would have caused a “pin-priority: 100” rule to be created; on the other hand, I’m not entirly confident that we can ruleout that possibility.

DaveW, if you have used any of the frighteningly-polular “curl | sudo bash” installers (Golang, python pip, pypy, et al), possibly an installer “did ya a favor”(!) and temporarily enabled debian sid repository to grab the latest-greatest version of some lib (and oops, oh well, that lib pkg has a libc6 >=2.28 dependency…)

[Member DaveW]

Skidoo,
/etc/apt/sources.list.d/debian.lst shows the following active repositories…

deb http://ftp.us.debian.org/debian/ stretch non-free contrib main
deb http://security.debian.org/ stretch/updates non-free contrib main

I tried “$ apt-mark showhold” but nothing was returned. You also asked about…

$ apt policy perl-base
perl-base:
Installed: 5.28.1-6
Candidate: 5.28.1-6
Version table:
*** 5.28.1-6 100
100 /var/lib/dpkg/status
5.24.1-3+deb9u5 500
500 http://ftp.us.debian.org/debian stretch/main i386 Packages
500 http://security.debian.org stretch/updates/main i386 Packages

Caprea,
Yes… I probably did install something from outside of the repos… but I don’t recall what it was. One of the links, that skidoo provided, gave version numbers of perl-base packages. And, as you said, the 5.28 version is Buster.

The other two computers (mentioned in original post) where apparmor install went uneventfully, have the 5.24 perl-base.

It would be worthwhile reverting to the earlier perl-base, if the only thing that it would break is the unknown program from outside. But, my guess is that a lot of other things are tangled up with it.
So… If reverting to the earlier version of perl-base is not feasible, without breaking everything, I can do a fresh install from a LiveUSB made from one of the others (after backing up personal stuff, like firefox and thunderbird profiles).

[Moderator caprea]

It looks like, however this happened, the version of perl-base that is installed on your system is a buster version.
The repos of antiX17 are set to stretch, normally. And the output of “apt policy libapparmor-perl” indicates also that you are actually using stretch.

Did you by chance install something from outside the repos or from buster ?
Unfortunately that would not be easy to solve, maybe impossible.(pearl-base from buster pulled in a higher libc6 and so on….)

[Forum Admin BitJam]

olsztyn wrote:

I am experiencing fatal error on boot after making the following changes, it appears resulting switching kernel from 4.9 to 4.19:
– On encrypted Live installed kernel 4.19 and switched to it
– Activated ufw
– Remastered Live
– Executed Live USB Maker to create a copy to another usb with checked ‘from running system’ and encrypted
– Live USB creator completed without errors
– Booting such created copy results in boot failure at the point when setting an encryption key is expected

I think this is a bug in LUM, triggered by the combination of things you did (but not your fault). The problem is that on encrypted live-usbs the actual kernel and initrd files are on a different partition. Apparently live-kernel-updater handles this correctly but clone mode in LUM does not.

If you are willing, you could try to fix this manually, assuming it is easy for you to replicate the original problem. Let’s say the encrypted live-usb you are starting from is sdb and the target live-usb is at sdc.

After running LUM in clone mode, mount /dev/sdb1 and /dev/sdc1. They should both have an /antiX/ directory that contains vmlinux and initrd.gz files. Copy these two files from sdb1 to sdc1. I think this will fix the problem and it will verify I’m on the right track to fixing it in the code. If this is not convenient for you, that’s fine. I will go ahead and try to fix the code anyway.

Context is worth 80 IQ points -- Alan Kay

[Anonymous]

As noted in my original post, Synaptic says libapparmor-perl has an unsatisfied dependency: perlapi-5.24.1

This is another detail I neglected to notice during my earlier reading.

a websearch for “libapparmor-perl perlapi-5.24.1”
led to this: https://forums.solydxk.com/viewtopic.php?t=7126
which mentions that an “apt upgrade” or “apt dist-upgrade” may be required to untangle the situation.

“I am using i386”
That’s often a good detail to consideer, but AFAIK all perl stuff is architecture-agnostic
(I would expect a repo to serve the same, identical, perl-whatever pkg to all requestors)

[Member olsztyn]

I have done some preliminary testing (64bit) and my observations are the following:
– Booted fine – needless to say…
– Creation of Live USB encrypted worked (apparently thanks to kernel 4.9 used and not 4.19)
– Persistence appears to work as expected
– Synaptic appears to be character based window, not gui. I am not sure this is Base feature or else…
– Unrelated, just comment, a bit struggled through typical roughness of IceWM, not having Fluxbox/Radiant yet available..
– I think I noticed twice that clicking on Logout, the Reboot option it actually proceded to shut down my laptop rather than rebooting.
– Ceni works as usual
– Included Firefox appears to work as expected
– Installed Kodi (17.6). Kodi worked as expected.
– After installation of Kodi however the only Desktop available in ‘Other Desktops’ was Kodi. The previously existing variants of IceWM were gone. I think this would happen in antiX 19 runit or not, so unrelated to runit.
– RAM use appears no different but I think this is expected.
– The sequence of green ‘OK’s during boot in three groups – is this representing various services starting in their levels?

With my very limited understanding I have a feeling that runit seems a good path to continue in order to stay away from systemd mess, service start and management better controlled…

Edit:
It looks like runit is very much in favor and systemd is not:
https://www.slant.co/versus/12956/12960/~systemd_vs_runit

• This reply was modified 3 years, 5 months ago by olsztyn.

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Member DaveW]

Skidoo,
Thank you for your reply.
As you suggested, I waited a day, and rechecked. Symantic still shows that the apparmor related packages are broken.

You asked about the following…

$ apt policy libapparmor-perl
libapparmor-perl:
Installed: (none)
Candidate: 2.11.0-3+deb9u2
Version table:
2.11.0-3+deb9u2 500
500 http://ftp.us.debian.org/debian stretch/main i386 Packages

I see that you were using an amd64 repository, while I am using i386. Perhaps there is an issue with something in the 32 bit area of the repository?

As noted in my original post, Synaptic says libapparmor-perl has an unsatisfied dependency: perlapi-5.24.1 (Synaptic says: “make sure all required repositories are added and enabled.”) There is also mention of a possible broken “held package”.

Apparently, perlapi-5.24.1 is contained in perl-base. Synaptic shows this as already present on my system. However, assuming that the mentioned file is corrupted, I attempted ‘apt reinstall perl-base’ and was informed that the file could not be downloaded, because it could not be found in the repositories. I found that it is available for download from a debian site, but I would rather use antix distribution sources.

Could this be the “held package”?

$ apt list -a perl-base
Listing… Done
perl-base/now 5.28.1-6 i386 [installed,local]
perl-base/oldstable,oldstable 5.24.1-3+deb9u5 i386

I appreciate your suggestions. I’m still baffled.

[Anonymous]

The tone has been turning kind of nasty. We’ve been sniping at each other more.
I think there are two contributing factors to that:

First, this has been a long process. We’ve put in a lot of energy, and
I think some of us are coming to a point where that is rubbing us a bit raw.

Secondly, discussions run through a progression. In the beginning, you
get the most dedicated people who are currently available. The people
who care enough to make sure they are there. Then as the discussion
progresses, you get more people involved. Each round of new people has
a cost. You have to revisit things, help catch them up, sometimes
reconsider significant chunks of what you have already thought in light
of comments they make. The first couple times this happens, we call it
additional review from a wider audience. It’s essential for doing a good job.

Each successive round of people drifting in has a higher cost.
Typically each successive round of people wondering in are willing to
dedicate less energy, and have less context in what has come before.
Some of the costs grow higher. They are more likely to bring up things
that are well settled without new insight. The earlier participants
know where some of the pain points are, and are more likely to know
where to be careful in what they say to be respectful. After a certain
point, the people drifting in might have apparently really simple ideas
that are unworkable because they disregard the needs of some segment of
the community. Hearing these again and again can be harmful.

I think both factors are contributing.

So, I think we’ve accomplished what we can accomplish here in this discussion.
Continuing the discussion would simply escalate tensions for all of us
and I don’t think has any probability of significantly increasing the ballot.

^— Above, those are not my words.
I copypasted this from a post a few days ago by Sam Hartman (the current Debian Project Leader)
https://lists.debian.org/debian-vote/2019/12/msg00064.html

[Anonymous]

FYI I just checked libapparmor-perl and found that it is available & that I was able to successfully install to antiX 17 system

$ apt policy libapparmor-perl
libapparmor-perl:
  Installed: (none)
  Candidate: 2.11.0-3+deb9u2
  Version table:
     2.11.0-3+deb9u2 500
        500 http://ftp.us.debian.org/debian stretch/main amd64 Packages

Even if you had altered your sources.list.d/debian.list, and your system is trying to download from “testing” branch… the libapparmor-perl package is still available from the current testing (bullseye) repository.

I guess I don’t have the appropriate repository. Where I should I look?

Nooooo it doesn’t work (work out well) like that. Don’t get a wild hair to change the configured repositories.

? On your system, what is the output of
apt policy libapparmor-perl

Synaptic shows the same repositories as were used in the two previous successful installs.

Well, I’ll suggest you just sit tight, then tomorrow apt update and try again.
I’ve noticed some ‘net slowness today and several intermittently unresponsive servers.

Hi, A week ago, I installed apparmor and configured apparmor, on two 32 bit computers running Antix 17. The installation files were downloaded with Synaptic, and configured with help of instructions on a debian site, and Firejail support site. Both systems seem to be working okay.

Today, I attempted to do the same with another computer, which is also running 32 bit Antix 17 with Firejail.

But when making selections on Synaptic, the selected lines indicate broken packages. So, instead of using synaptic, I ran the following from terminal:

root@my-antix17:/home/myhome# apt install apparmor apparmor-utils
Reading package lists… Done
Building dependency tree
Reading state information… Done
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:
apparmor : Depends: libapparmor-perl but it is not going to be installed
apparmor-utils : Depends: libapparmor-perl but it is not going to be installed
Depends: python3-apparmor (= 2.11.0-3+deb9u2) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
root@my-antix17:/home/myhome#

Synaptic says libapparmor-perl has dependency perlapi-5.24.1 (with complaint: “make sure all required repositories are added and enabled.”) Synaptic shows the same repositories as were used in the two previous successful installs.

perlapi-5.24.1 is contained in perl-base. Synaptic shows this as already present. I attempted ‘apt reinstall perl-base’ and was informed that the file could not be downloaded.

I guess I don’t have the appropriate repository. Where I should I look?

Thanks!

• This topic was modified 3 years, 5 months ago by DaveW.
• This topic was modified 3 years, 5 months ago by DaveW.

[Anonymous]

For THAT (contextual help on-demand, vs continually displayed)

I (sudo apt install zim) installed zim.
During firstrun, zim prompted to create a default notebook. IIRC, I specified “myhelp”.
Today, I didn’t remember that detail offhand.
After downloading the image from your post (SavedAs ~/Pictures/blenderkeys-640×360.png),
I launched zim and created 2 notes (nodes? zimwiki pages?) named “leafpad” and “blender”.
While viewing the “blender” page, I used “Insert Image” from zim’s toolbar,
then saved the zim notebook and closed zim.

“sudo updatedb && locate blender” because I don’t know where zim stores its assets.
(and now, while typing this, I realize that I apparently created a zim “page” named “first”
then added “leafpad” and “blender” as SUBpages nested under “first”)

“zim –help”
usage: zim [OPTIONS] [NOTEBOOK [PAGE]]

Contrary to syntax indicated “zim –help”, my various attempts to “view a specified node” failed.
zim blender
(so what the hell was the point in settng a default notebook?)
zim myhelp blender
zim ~/myhelp.nbk blender
Via “locate blender”, I discovered that zim (confusingly, IMO) has applied “.txt” to page asset filename. Trial-n-error, I discovered that supplying the page asset pathstring (zim ~/myhelp.nbk/first/blender.txt) a successful zim “goto node” launchstring.
______________

So, to achieve on-demand, popup help, you can (I tested)
simply create a zim wiki containing “pages” named to match program names (aka, procnames)
and create a keybind to call this one-liner launchstring:
zim ~/myhelp.nbk/first/$(cat /proc/$(xdotool getwindowpid $(xdotool getwindowfocus))/comm).txt

You will probably want to insert a keymap image at TOP of the wiki page
( top= before/above the mandatory pagename hyperlink )
and you can probably remove the auto-inserted datetimecreated text and/or setup a zimwiki page template.
Remember, during use (while viewing the popped up wiki page) the page is editable ~~ you can scroll and type additional helptext, or project notes or whatever, or even insert additional images.
______________

The “page//subpage” hierarchy I had chosen (apparently, but I don’t recall doing so), it affects the pathstring in the example I’ve presented. If you use a flat (no subpages) page structure, maybe you would omit the “first/” substring from the hardcoded portion of the keybind launchstring? Headscratch ~~ upon reopening the zim notebook used in the screenshot, I don’t see any “click to expand” icon denoting a subtree structure. Left pane just shows 4 page items: “blender”, “Home”(bolded), “lxterminal”, and “leafpad”.

[Anonymous]

Confusingly, some distros (ubuntu and downstream) permit the first non-root user account to launch synaptic without password challenge, and with full permissions. Other distros (I cannot recall any by name, offhand) configure the system to outright forbid launch of synaptic by non-root users…

Your “grayed out” result indicates that you have launched synaptic without elevated permissions.
In the current version of antiX, non-root user is permitted to launch synaptic “just to look around, learn what’s installed”. To actually perform most operations within synaptic, you will need to launch it with elevated permissions

To launch with elevated permissions:

Alt+F2 —} gExec
type synaptic into the runbox and tick “Run as root”

Alternatively, at the terminal emulator command prompt, type
sudo synaptic (or gksu synaptic)

If you wound up in this situation by “using an icon” or by clicking a desktop menu entry,
apparently that launcher file contains an “Exec=” line in which the sudo prefix has been omitted.
You can “fix” by
sudo leafpad /usr/share/applications/synaptic.desktop
Edit the “Exec=” line to read as
Exec=sudo synaptic
then Save the edited synaptic.desktop file.