| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 23 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 54:07:18 |
| Calls: | 583 |
| Files: | 1,139 |
| D/L today: |
179 files (27,921K bytes) |
| Messages: | 111,699 |
I've been using XnView MP for several years, originally installed via
the xnview website using a deb file. Occasionally, updates have appeared
and the new deb has installed without problem. I hadn't updated my
v1.7.2 for some time, and saw v1.9.2 was available, so I downloaded the
deb as usual. However, on trying to install I get a dependency issue:
Error: Dependency is not satisfiable: libglig2.0-0 (>= 2.33.14)
In the Mint forum, the reason is given here: <https://forums.linuxmint.com/viewtopic.php?p=2620200#p2620200>
A different solution is proposed in the xnview forum at: <https://newsgroup.xnview.com/viewtopic.php?p=202285#p202285>
It seems strange to me that the problem still exists. As I don't use
XnView MP that much it seems simpler to stay with the old version.
A different solution is proposed in the xnview forum at: <https://newsgroup.xnview.com/viewtopic.php?p=202285#p202285>
Jeff Layman wrote:
A different solution is proposed in the xnview forum at:
<https://newsgroup.xnview.com/viewtopic.php?p=202285#p202285>
Since you are into trusting the outside .deb not from repo/s, that
answer seems best.
There is also a flatpak 1.9.2 along w/ some 'unverified' remarks:
https://flathub.org/apps/com.xnview.XnViewMP
I don't use flatpaks.
Jeff Layman wrote:
I don't use flatpaks.
I don't either, but I think it is a better idea than snaps.
I also 'understand' the necessity for 'alternate' package schemes in a
world of 'disparate' linux distro/s which make for greater difficulty in dev/s being able to provide a working package for 'all of them'.
Mike Easter wrote:
Jeff Layman wrote:
I don't use flatpaks.
I don't either, but I think it is a better idea than snaps.
I also 'understand' the necessity for 'alternate' package schemes in a
world of 'disparate' linux distro/s which make for greater difficulty
in dev/s being able to provide a working package for 'all of them'.
Isn't that why they invented the appimage? I don't understand why these aren't more popular; I like using them because they always work.
Monsieur wrote:
Mike Easter wrote:
Jeff Layman wrote:
I don't use flatpaks.
I don't either, but I think it is a better idea than snaps.
I also 'understand' the necessity for 'alternate' package schemes in a
world of 'disparate' linux distro/s which make for greater difficulty
in dev/s being able to provide a working package for 'all of them'.
Isn't that why they invented the appimage? I don't understand why these
aren't more popular; I like using them because they always work.
My understanding of flatpak vs appimage is that the later is 'simpler'
and the former is more sandboxy.
In my world, the sandboxing idea isn't as important; but what IS more important is the 'availability' of 'apps'.
My 'understanding' (of something I know nothing about - more like 'I
hear') is that it is easier to dev a flatpak from source than the
others, and consequently there are more of those at flathub; but I don't know if that is true.
Flathub doesn't enforce[1] that "the app developer" is also "the flatpak creator". Which sets off more than a few alarm bells for me.
Flathub doesn't enforce[1] that "the app developer" is also "the
flatpak creator". Which sets off more than a few alarm bells for
me.
[1] Or, at least in the past "anyone" could create a flatpak and
upload it to flathub.
Packages are contributed by both Flathub administrators and
application developers, with a stated preference for submissions
from the developers themselves.
wp's article on this topic ref/s this flathub page:
EasyOS is designed from scratch to support containers. Any app can--
run in a container, in fact an entire desktop can run in a
container. Container management is by a simple GUI, no messing
around on the commandline. .... Easy Containers are extremely
efficient, with almost no overhead -- the base size of each
container is only several KB.
While using Easy, everything happens in RAM. App startup appears to
be almost instantaneous, even very large apps such as LibreOffice
startup in the blink of an eye. Ditto when starting a container,
blink of an eye. Depends on your PC of course!
I also 'understand' the necessity for 'alternate' package schemes in a
world of 'disparate' linux distro/s which make for greater difficulty in dev/s being able to provide a working package for 'all of them'.
Mike Easter wrote:
I also 'understand' the necessity for 'alternate' package schemes in a
world of 'disparate' linux distro/s which make for greater difficulty in
dev/s being able to provide a working package for 'all of them'.
ItrCOs not the developersrCO job to provide the packaging for particular distros. Leave that to the distro maintainers: they take your source code, and build it and package it in a form that hooks nicely into their distro- specific dependency system.
Lawrence D'Oliveiro wrote:
ItrCOs not the developersrCO job to provide the packaging for
particular distros. Leave that to the distro maintainers: they take
your source code, and build it and package it in a form that hooks
nicely into their distro- specific dependency system.
Well, yes, but... (or yabbut...)
... the distro maintainers are very busy and 'understaffed' :-) They
can't 'keep up' w/ all of the source and compiling for each release.
There is a 'world' of software dev/s out there, who come up w/ a 'linux' product/source and look around at each other and say, "Now what do I
do?"
Lawrence D'Oliveiro wrote:
Mike Easter wrote:
I also 'understand' the necessity for 'alternate' package schemes in a
world of 'disparate' linux distro/s which make for greater difficulty in >>> dev/s being able to provide a working package for 'all of them'.
ItrCOs not the developersrCO job to provide the packaging for particular
distros. Leave that to the distro maintainers: they take your source
code,
and build it and package it in a form that hooks nicely into their
distro-
specific dependency system.
Well, yes, but... (or yabbut...)
... the distro maintainers are very busy and 'understaffed' :-) They
can't 'keep up' w/ all of the source and compiling for each release.
There is a 'world' of software dev/s out there, who come up w/ a 'linux' product/source and look around at each other and say, "Now what do I do?"
Mike Easter wrote:
... the distro maintainers are very busy and 'understaffed' :-) They
can't 'keep up' w/ all of the source and compiling for each release.
There is a 'world' of software dev/s out there, who come up w/ a
'linux' product/source and look around at each other and say, "Now
what do I do?"
Which bit of "if you're not happy with the way person X does it, you're quite welcome to do it yourself" do you not understand?
I always say, 'Nobody wants to compile.'
Mike Easter wrote:
I always say, 'Nobody wants to compile.'
And, in the case of the OP, I don't think it is 'open source'. It is free and available cross-platform for linux, Mac, & Win, but flathub calls it 'proprietary'.
At its site the linux is available as a .deb, .tgz, or appimage.-a I don't know how to interpret the contents of the tgz.
Chris Elvidge wrote:
I always say, 'Nobody wants to compile.'
Which bit of "if you're not happy with the way person X does it, you're
quite welcome to do it yourself" do you not understand?
And, in the case of the OP, I don't think it is 'open source'. It is
free and available cross-platform for linux, Mac, & Win, but flathub
calls it 'proprietary'.
On Mon, 7 Jul 2025 09:55:42 -0700, Mike Easter wrote:
And, in the case of the OP, I don't think it is 'open source'. It is
free and available cross-platform for linux, Mac, & Win, but flathub
calls it 'proprietary'.
So if you have trouble with it, nobody can fix it except the original developers.
On Mon, 7 Jul 2025 09:29:25 -0700, Mike Easter wrote:
Chris Elvidge wrote:
I always say, 'Nobody wants to compile.'
Which bit of "if you're not happy with the way person X does it, you're
quite welcome to do it yourself" do you not understand?
Those coming from a Windows background are understandably a little scared
of the process, considering the myriad of things that can go wrong in that environment.
On Mon, 7/7/2025 6:48 PM, Lawrence D'Oliveiro wrote:
On Mon, 7 Jul 2025 09:29:25 -0700, Mike Easter wrote:
Chris Elvidge wrote:
I always say, 'Nobody wants to compile.'
Which bit of "if you're not happy with the way person X does it, you're >>>> quite welcome to do it yourself" do you not understand?
Those coming from a Windows background are understandably a little scared >> of the process, considering the myriad of things that can go wrong in that >> environment.
We are weary of the process, but not scared of it.
[...]
Todays dev, is a careless son of a bitch.
"Oh, heh heh, yes, I must have had Boost installed on my
machine when I built that." Or "Don't you have the same utterly
weird collection of bits and bobs on your computer as I do ???"
Todays dev, is a careless son of a bitch.
On 2025-07-08, Paul wrote:
We are weary of the process, but not scared of it.
I think you mean "wary" (as in "cautious"), not "weary" (as in "tired"); right?
To paraphrase Samuel Johnson: rCLThey who are tired of building from source are tired of liferCY.
Sir, when a man is tired of London, he is tired of life; for there is in London all that life can afford."
On Tue, 8 Jul 2025 02:05:06 -0400, Paul wrote:
Todays dev, is a careless son of a bitch.
This is why build scripts have dependency checks in them. All the good
build systems (Autotools, CMake etc) offer elaborate mechanisms for performing these checks.
I once compiled something and it worked out perfectly; so there.
That doesn't mean that one should expect that result.
I could tell you about one project I attempted to build.
It was a project that used some NVidia SDK libraries for the build. The
build got half way along, and an error message said "Version mismatch". That's it. That's the context.
You don't report "Version Mismatch, executable ABC wants version 10 of
SDK, SDK provided is version 9". No contextual helpful hint at all, as
to what the things are where the versions don't match.
On Tue, 7/8/2025 5:40 PM, Lawrence D'Oliveiro wrote:
On Tue, 8 Jul 2025 02:05:06 -0400, Paul wrote:
Todays dev, is a careless son of a bitch.
This is why build scripts have dependency checks in them. All the good
build systems (Autotools, CMake etc) offer elaborate mechanisms for
performing these checks.
I could tell you about one project I attempted to build.
It was a project that used some NVidia SDK libraries
for the build. The build got half way along, and an error
message said "Version mismatch". That's it. That's the context.
You don't report "Version Mismatch, executable ABC wants version 10
of SDK, SDK provided is version 9". No contextual helpful hint at
all, as to what the things are where the versions don't match.
By giving the builder no hint at all, what the two word error message
means, am I supposed to systematically download one 2GB kit after
another and "try them and see if the problem goes away". Well,
fuck you and the chuck wagon you rode in on.
A person in the old days, would realize an error message was
required, and they would say to themselves "if *I* was building
the package, what information would I appreciate getting
to resolve the issue". And the error message content is
tuned for the context of the situation.
I've built plenty of stuff over the years. We had to at work, because
we were on Unix boxes and no software was provided. (Yes, we had
expensive CAD software, but there were no creature comforts at all.)
For example, there was no web browser at the time. That's why,
on one occasion, I spent 40 hours building NCSA Mosaic... when I had
no build tree and I had to start from scratch. That was a domino
build, where I had to make myself a libjpeg, a libtiff, I had to
invent the oxygen I was breathing. And that is why it took all week.
It worked. But, the IT department was watching me (they watched
everybody, with regard to downloads), and I got a phone call to
"delete that browser -- license violation" that did not allow
NCSA Mosaic to be used in a commercial setting.
So I and my crew, went back to using Lynx, like always.
Can you imagine trying to do electrical engineering design,
using Lynx to look up datasheets for electronic parts ? It's
an experience
And this is why we build.
Because we have nothing.
Paul
On Tue, 8 Jul 2025 15:00:52 -0700, Mike Easter wrote:
I once compiled something and it worked out perfectly; so there.
That doesn't mean that one should expect that result.
Of course you should. Otherwise thererCOs a bug in the build script.
Or yourCOre on Microsoft Windows.
On Tue, 8 Jul 2025 22:38:33 -0400, Paul wrote:
I could tell you about one project I attempted to build.
It was a project that used some NVidia SDK libraries for the build. The
build got half way along, and an error message said "Version mismatch".
That's it. That's the context.
You don't report "Version Mismatch, executable ABC wants version 10 of
SDK, SDK provided is version 9". No contextual helpful hint at all, as
to what the things are where the versions don't match.
All you had to do was look at the source of the build script. These things are usually easy to modify, e.g. to add more debug messages. Or maybe
there was already an option to produce more verbose messaging -- this
would have been apparent from looking at the build script.