I just did a clean install of 13.1 and noticed it’s like the latest Kubuntu - it doesn’t have the option to install a 32-bit runtime environment. This option made life easy. So what 13.1 package will install the full 32-bit runtime environment? My RSI - IDL will not run under 13.1, whereas it used to run just fine under previous opensuse versions with the 32-bit runtime environment preinstalled.
Hi Carlos - this is the problem I had with the latest Kubuntu - this approach of tying only the 32-bit parts for individual packages for install, rather than allowing the whole 32-bit subsystem to be installed, only really works for repo packages. RSI IDL is a non-repo package. I don’t know what 32-bit parts I need (RSI IDL) - all I know is that everything worked fine when I installed the option “32-bit runtime environment” from the software list in the installer on the pre-13.x versions of OpenSuSE. Is there a meta-package to replace that pre-13.x option? Do you know the option I’m talking about (from the previous versions’ installers)?
Well, I sound like I know more than I do know - all I really know is that when that option to install the 32-bit environment went away - some of my non repo software went poof! and no longer works after install.
On 2014-02-23 05:06, PattiMichelle wrote:
> Hi Carlos - this is the problem I had with the latest Kubuntu - this
> approach of tying only the 32-bit parts for individual packages for
> install, rather than allowing the whole 32-bit subsystem to be
> installed, only really works for repo packages. RSI IDL is a non-repo
> package. I don’t know what 32-bit parts I need (RSI IDL) - all I know
> is that everything worked fine when I installed the option “32-bit
> runtime environment” from the software list in the installer on the
> pre-13.x versions of OpenSuSE. Is there a meta-package to replace that
> pre-13.x option? Do you know the option I’m talking about (from the
> previous versions’ installers)?
> Well, I sound like I know more than I do know - all I really know is
> that when that option to install the 32-bit environment went away - some
> of my non repo software went poof! and no longer works after install.
Ah, I understand.
I suggest you report this as a bug in Bugzilla, or raise the issue on
the factory mail list, to attract the attention of people that do the
packaging and such things.
Thanks - do you have an appropriate bz link? I had to drop back to 12.3, but found it will not install correctly (video card incompatibility) on my latest HP EliteBook 8470p So now I’m back to the 8440 running 12.3.
It may be an upstream problem for Linux in general - Kubuntu also is taking the line that only the “needed” (i.e., by specific repo packages) 32-bit compatability should be installed. But that seems odd since hard drives are huge these days, and the 32-bit compatability package is very small compared to everything else. I’ve never needed a partition bigger than 20GB to hold the system drive. I guess far-upstream Linux developers are trying hard to make Linux distros fit on thumb drives?
I raised the same question about a month ago, no useful ‘easy’ solution appeared
I found running ‘ldd executable’ in konsole usually identified missing libs which I then dug up using Package Search.
If ldd reveals no obvious missing libs, perhaps then run the executable from CLI and watch for ‘missing this or that’ error messages.
I agree that HDD space should not be an issue (even thumb drives are 64GB now),
but clearly the more repos enabled, the longer it takes to run updates too.
Sounds like rolling the dice. :\ There aren’t any guarantees when packages are named, are there? (i.e., with or without 32-bit in their names) Was something wrong with the old method of just installing the 32-bit subsystem (or not) that I didn’t hear about? I don’t remember anyone having trouble with that.
Thanks, this may do it. I’ll give it a try. Why did they remove the 32-bit subsystem install from YaST 12.3 → 13.x? I don’t remember any issues of substance… What is CLI? As I said, this also appears to have shown up in Kubuntu just recently, so it is probably some upstream kernel development thing (as in users say, “Why did they do that?”). Well, time to try reinstalling again…
I’ve been doing that… The nearest hint I’ve gotten from ITT is that their GUI interface is 32-bit and it always worked up until they ghosted the ‘generic’ 32-bit runtime install package, breaking 13.1 for folks like me… No Joy Here!
patti@linux-enhj:~/RSI/idl/bin> ldd ./idlde
not a dynamic executable
> As I said, this also
> appears to have shown up in Kubuntu just recently, so it is probably
> some upstream kernel development thing (as in users say, “Why did they
> do that?”). Well, time to try reinstalling again…
No, possibly a packaging decision.
The alternative is to install ALL the -32bit packages, which are a lot.
It is more efficient for properly packaged 32 bit application to
explicitly name what they need.
Of course, some don’t. Typically proprietary rpms (or tars).
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Yes, I use a lot of those (proprietary tars) - and friendliness to software like this (not tied to
a specific OS) is one of the key strengths of *nix. So I need this package Pattern, and
I don’t think there is any reason at all for OpenSuse to write users like me out of their
support plans as the entire distro WITH the old -32 bit support Pattern installed will
fit on a $10 USB thumb drive.
It’s sort of a Windows trick, if you think about it, making an OS basically
hostile to non-Repo software by removing that Pattern (without a lot of dead-chicken-waving
by a Opensuse wizard - I love FOLDOC), when there’s no clear advantage. Also, the 32-bit
support Pattern I’m talking about didn’t install all 32-bit versions of every
package - right? Just certain 32-bit libs (i’m guessing here - but it
was not a big set of packages) which allowed 64-bit KDE opensuse to automatically
run 32 bit software, like ITT’s Interactive Data Language, with no problems.
(You could also run Gnome apps in KDE without installing Gnome, and that now
seems broken… but - I digress…)
Anyway, I finally had to downgrade to 12.2 - but now I’m absolutely stuck since LTS
for that stopped before Heartbleed happened.
I guess I’ll check out bugzilla this morning. But I feel like I’m seriously
missing something here - why would they make this change when there’s
no advantage and many users are orphaned by it?
I guess I could try reinstalling 12.2 somewhere, write down the contents of
that Pattern, and post/use it. The trouble is that they may have changed
names and references of the packages within that Pattern (I just learnt
that these were called “patterns” yesterday). So you see why it’s a problem
for folks like me…
On Sat 26 Apr 2014 04:26:01 PM CDT, PattiMichelle wrote:
Geeze, I’m dense - slowly beginning to “get” this - yes, it’s a
“Pattern” in YaST. A one-click install of all needed 32-bit stuff.
What it did was prevent me from having to spend days (or more)
trouble-shooting non-repo software at the expense of a few megabytes of
Is there a way to get that “Pattern” back into 13.x version of YaST?
Why not use zypper?
zypper se -t pattern 32bit
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
i | 32bit | 32-Bit Runtime Environment | pattern
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE 13.1 (Bottle) (x86_64) GNOME 3.10.1 Kernel 3.11.10-7-desktop
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
Thanks! I hope this will get fixed by 13.2… Anyway, I thought of a fix? Just look at what all packages are in the 32-bit envrionment “pattern” in 12.3, and select all those in 13.x? That would at least get most of them…