[SOLVED] Need a Little Help with deb2tgz

enorbet · 09-28-2016, 11:20 PM

LOL, while I have forgotten many *Nix commands from lack of usage (and I do about equal parts GUI and CLI - I boot to runlevel 3, NOT X) I have never noticed "readelf" and what a little gem it is!

Here's my output

Code:

 readelf -d /usr/bin/kpackage3 | grep NEEDED
 0x00000001 (NEEDED)                     Shared library: [libkio.so.4]
 0x00000001 (NEEDED)                     Shared library: [libkdeui.so.4]
 0x00000001 (NEEDED)                     Shared library: [libkdesu.so.4]
 0x00000001 (NEEDED)                     Shared library: [libkwalletclient.so.1]
 0x00000001 (NEEDED)                     Shared library: [libkdecore.so.4]
 0x00000001 (NEEDED)                     Shared library: [libDCOP.so.4]
 0x00000001 (NEEDED)                     Shared library: [libresolv.so.2]
 0x00000001 (NEEDED)                     Shared library: [libutil.so.1]
 0x00000001 (NEEDED)                     Shared library: [libart_lgpl_2.so.2]
 0x00000001 (NEEDED)                     Shared library: [libidn.so.11]
 0x00000001 (NEEDED)                     Shared library: [libkdefx.so.4]
 0x00000001 (NEEDED)                     Shared library: [libqt-mt.so.3]
 0x00000001 (NEEDED)                     Shared library: [libmng.so.1]
 0x00000001 (NEEDED)                     Shared library: [liblcms.so.1]
 0x00000001 (NEEDED)                     Shared library: [libjpeg.so.62]
 0x00000001 (NEEDED)                     Shared library: [libGL.so.1]
 0x00000001 (NEEDED)                     Shared library: [libXmu.so.6]
 0x00000001 (NEEDED)                     Shared library: [libXt.so.6]
 0x00000001 (NEEDED)                     Shared library: [libXrandr.so.2]
 0x00000001 (NEEDED)                     Shared library: [libXcursor.so.1]
 0x00000001 (NEEDED)                     Shared library: [libXfixes.so.3]
 0x00000001 (NEEDED)                     Shared library: [libXinerama.so.1]
 0x00000001 (NEEDED)                     Shared library: [libXft.so.2]
 0x00000001 (NEEDED)                     Shared library: [libfontconfig.so.1]
 0x00000001 (NEEDED)                     Shared library: [libfreetype.so.6]
 0x00000001 (NEEDED)                     Shared library: [libexpat.so.1]
 0x00000001 (NEEDED)                     Shared library: [libpng.so.3]
 0x00000001 (NEEDED)                     Shared library: [libXext.so.6]
 0x00000001 (NEEDED)                     Shared library: [libSM.so.6]
 0x00000001 (NEEDED)                     Shared library: [libICE.so.6]
 0x00000001 (NEEDED)                     Shared library: [libXrender.so.1]
 0x00000001 (NEEDED)                     Shared library: [libX11.so.6]
 0x00000001 (NEEDED)                     Shared library: [libxcb-xlib.so.0]
 0x00000001 (NEEDED)                     Shared library: [libxcb.so.1]
 0x00000001 (NEEDED)                     Shared library: [libXau.so.6]
 0x00000001 (NEEDED)                     Shared library: [libXdmcp.so.6]
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [libfam.so.0]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [libacl.so.1]
 0x00000001 (NEEDED)                     Shared library: [libattr.so.1]
 0x00000001 (NEEDED)                     Shared library: [libstdc++.so.6]
 0x00000001 (NEEDED)                     Shared library: [libz.so.1]
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]

That's already a BIG help. Respect! and while I'm handing out kudos the wine-staging build script I was referring to above was written by dugan, another capable slacker.

bassmadrigal · 09-29-2016, 07:11 AM

So, is kpackage3 a 32bit binary package that you install? Or are you compiling it as a 64bit program?

If you run ldd /usr/bin/kpackage3, it should let you know if any of those are missing.

enorbet · 09-29-2016, 12:11 PM

I have no idea (yet) if it is possible to get source from KDE, but mine was simply copied over from a Slackware 12.0 install. Fortunately "ldd" is not one of the commands I've forgotten due to lack of usage. It's a fairly regularly used tool in the box. It seems revealing of the Unix philosophy that as useful as ldd is, it is a quantum leap in power when combined with "readelf". I am exceedingly grateful to you for that. The two together certainly reduce stumbling in the dim light with one eye closed.

I had no intention of recompiling kpackage (I renamed it kpackage3 to differentiate from the v4 offering by the same name that dropped pkgtool compatibility and basically castrated it in other important ways as well) since I have all the version 3 libraries installed on other boxen. That said, it seems I may have to rethink that on a 64bit multilib system. I expect to have it resolved in the next few days, in no small part, thanks to you.

FWIW the move to a parallel system has once again had a fringe benefit of discovering old bad habits that accrue over time. This current 14.0 32 bit started as v 12.0 (or possibly even 11.0 since if memory serves v11 didn't stick around as long as v10 or v12) and evolved into each increment "to here" via Upgrade, so a LOT of time has passed and the accumulation is substantial. The fresh install involves more interaction and commitment than a Live Edition or even a fresh install on a different box, and it is...well... refreshing. I'm pleased that I decided to bite the bullet now rather than later. This thread has served me well, as LQN often does.

bassmadrigal · 09-29-2016, 01:00 PM

While I was searching for kpackage build information, I decided to check SBo for it, hoping it was submitted back in the 12.0 era. Unfortunately, it wasn't. However, when searching SBo for kpackage, it did pull up smart. I haven't tried this (and I can't even do it right now, since I'm at work), but it seems like it might be a spiritual successor for kpackage and it explicitly supports pkgtool. Have you tried it at all?

And for my future reference, it seems it is part of the kdeadmin package up to Slackware 12.2 (since that's the last version containing KDE 3.5.x). I might try to do some digging on this tonight or this weekend.

bassmadrigal · 09-29-2016, 02:56 PM

Well, when I got home from work, my wife was taking a nap, so I decided to look into kpackage. Sorry if you wanted to figure this out yourself. If you do, stop reading now

Basically, it needs some files from 3 different packages. This is based off of Slackware 12.2, which had KDE 3.5.10. I'll give you my process in finding the packages I installed along with the absolute minimum files you need to get it to work (albeit, with an error on startup about DCOP missing, but everything seems to work fine).

So, to start, I created a temporary directory that I could install the packages to with installpkg's --root option.

Code:

mkdir kpackage

I then downloaded the kdeadmin package, as that is the one that contains kpackage and installed it into that directory.

Code:

wget http://slackware.cs.utah.edu/pub/slackware/slackware-12.2/slackware/kde/kdeadmin-3.5.10-i486-4.tgz
installpkg --root kpackage kdeadmin-3.5.10-i486-4.tgz

Then I tried starting it, and it complained that it couldn't find libkio.so.4:

Code:

jbhansen@craven-moorhead:~$ kpackage/usr/bin/kpackage 
kpackage/usr/bin/kpackage: error while loading shared libraries: libkio.so.4: cannot open shared object file: No such file or directory

So, I used http://packages.slackware.com/ to find that file on Slackware 12.2 (under the mode, change it to content to search for files), and I found it was contained in the kdelibs package. So I then downloaded that and installed it to the same location.

Code:

wget http://slackware.cs.utah.edu/pub/slackware/slackware-12.2/slackware/kde/kdelibs-3.5.10-i486-2.tgz
installpkg --root kpackage kdelibs-3.5.10-i486-2.tgz

I then tried starting it again, and it complained of the same error. That's right, you need to point to the new libs we added.

Code:

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:kpackage/usr/lib/ kpackage/usr/bin/kpackage

This time it complained about a missing libqt-mt.so.3, which back on the package.slackware.com website, showed it was part of qt-3.38b. So I downloaded that and installed it. This time, kpackage opened up (after an error about DCOP missing. I was able to browse through the packages and their contents, but I don't know if there's more functionality that you were looking for.

Anyway, I don't like the idea of installing 3 packages containing a ton of files for something that's only a part of one package, so I decided to use ldd to see what libraries were being referenced by the binary. That outputted the following:

Code:

jbhansen@craven-moorhead:~$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:kpackage/usr/lib/ ldd kpackage/usr/bin/kpackage | grep kpackage
 libkio.so.4 => kpackage/usr/lib/libkio.so.4 (0xf73fc000)
 libkdeui.so.4 => kpackage/usr/lib/libkdeui.so.4 (0xf7122000)
 libkdesu.so.4 => kpackage/usr/lib/libkdesu.so.4 (0xf710a000)
 libkwalletclient.so.1 => kpackage/usr/lib/libkwalletclient.so.1 (0xf70f8000)
 libkdecore.so.4 => kpackage/usr/lib/libkdecore.so.4 (0xf6ec2000)
 libDCOP.so.4 => kpackage/usr/lib/libDCOP.so.4 (0xf6e90000)
 libkdefx.so.4 => kpackage/usr/lib/libkdefx.so.4 (0xf6db4000)
 libqt-mt.so.3 => kpackage/usr/lib/libqt-mt.so.3 (0xf670f000)

I then created a new folder to create a Slackware package and the corresponding subdirectories (usr and lib) and I then copied all those files over.

Code:

mkdir -p package-kpackage/usr/{bin,lib}/
cp kpackage/usr/lib/{libkio.so.4,libkdeui.so.4,libkdesu.so.4,libkwalletclient.so.1,libkdecore.so.4,libDCOP.so.4,libkdefx.so.4,libqt-mt.so.3} package-kpackage/usr/lib/
cp kpackage/usr/bin/kpackage package-kpackage/usr/bin/

Then, I tried to run it again, and success. It seems to work fine.

Code:

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:package-kpackage/usr/lib/ package-kpackage/usr/bin/kpackage

So, now to make a Slackware package so this can be installed (note, I did type up a slack-desc so it would have information available to view, but it isn't necessary.

Code:

cd package-kpackage/
mkdir install
nano slack-desc
makepkg -l y -c n /tmp/kpackage-3.5.10-i486-1bass.tgz
installpkg /tmp/kpackage-3.5.10-i486-1bass.tgz

Then just run it. And it works

If you want to trust my work and download the package rather than doing it yourself, it will be available here (at least unless I decide to remove it from my server, but that won't be for at least months, if not substantially longer).

(NOTE: For those of you not completely following along, it should be noted that this package requires either multilib or a 32bit install)

enorbet · 09-29-2016, 05:03 PM

It seems this thread is off on a tangent for building a 64bit 14.2 and a package nobody apparently likes/appreciates but me, but I'm fine with that as long as anyone looking for deb2tgz help understnds that it has some problems in it's current state.

Yes i will trust your work and give it a shot, especially because I'm on what may prove to be a more time-consuming project - building a custom 4.4.14 kernel I didn't expect this to be a big deal at all since I do this quite regularly since I need realtime, tickless, low-latency kernel for deep audio work. However th most recent kernel I built was 3.12.0 and everything was as expected. Like Erik, I have come to prefer xconfig simply for the convenience of split window view. One used to get 2 splits (3 windows) with Header/Item and /Help all displayed all the time... Nice. I don't know whether the kernel has changed or xconfig has but now there is no help window or apparently file to show if there was one.

This isn't a huge deal for me since I'm pretty familiar with what I need so the Help window loss is not a major problem. What is, or may be a show stopper, for a time, is that some config items seem written in stone. For example Memory Model is apparently locked in as "Sparse' which as I understand it is only for multi CPU systems, not multicore. Also HighMemory shows options 4-64GB but none are selectable though a checkbox is present. I was doing "make xconfig" (as root) on the huge smp default kernel since it seems safer to remove items I know I don't need than to put in all the system requires. I think I'll try a fresh kernel and see what may be different , but I find this last bit rather odd behaviour.

Oh yes and I really don't know how to add yet more thanks for the kpackage build other than just piling on yet another ... Thank You

FWIW it is making what should become a complete migration faster and easier but not at all at the expense of understanding. Cool beans.

Edit- Update I had to also install libmng and libpng but after that it simply works a treat. Nice work.

BTW I know it must seem odd to care so much about such an insignificant app but I have a long bred distrust that PCs. although they theoretically should, actually WILL do the same thing the same way every time (shoot! Xfce opens up wrong 10-20% of the time) and an even deeper distrust of package managers. I prefer seeing it all laid out and if uninstalling I want to see it happen on-the-fly so I KNOW it did what I told it to do.... that neither it nor I screwed up.

bassmadrigal · 09-30-2016, 07:07 AM

Quote:

Originally Posted by enorbet

It seems this thread is off on a tangent for building a 64bit 14.2 and a package nobody apparently likes/appreciates but me, but I'm fine with that as long as anyone looking for deb2tgz help understnds that it has some problems in it's current state.

After a quick search, it seems someone forked the original to github and added support for non-gzipped packages. He doesn't have a Slackware package available to download, but he does have a SlackBuild that should build a Slackware package for it. Theoretically, it should support discord-canary, but I haven't tried it (back at work again without easy access to my computer). In fact, looking through the script, it should even generate a slack-desc based on information in the deb's metadata. It seems like it should work great if you just want to convert a package. However, if you're interested in submitting that package to SBo, you'd likely need to do something like the SlackBuild I provided earlier. I doubt SBo would accept a requirement of deb2tgz for a SlackBuild to build.

Quote:

Originally Posted by enorbet

I don't know whether the kernel has changed or xconfig has but now there is no help window or apparently file to show if there was one.

Unfortunately, I still use menuconfig (when I do occasionally rebuild the kernel, but it isn't a frequent event as I'm usually happy with Pat's), so I'm not sure what's going on there.

Quote:

Originally Posted by enorbet

Oh yes and I really don't know how to add yet more thanks for the kpackage build other than just piling on yet another ... Thank You

FWIW it is making what should become a complete migration faster and easier but not at all at the expense of understanding. Cool beans.

Glad I could help out

Quote:

Originally Posted by enorbet

Edit- Update I had to also install libmng and libpng but after that it simply works a treat. Nice work.

That's odd, but now looking back, I did do this all on a kinda Frankenstein 14.1 install (bits of original 14.1, some of an older -current recompiled, some completely upgraded outside of what Pat provided) rather than a 14.2 install, so there could've been missing dependencies that slipped through. But I'm glad you figured it out. And I can't take credit for the readelf thing. I found out about it on this forum, probably around a year ago (I think it was ponce who posted it on someone's thread to find what was missing). As you say, it is quite the powerful tool.

Quote:

Originally Posted by enorbet

BTW I know it must seem odd to care so much about such an insignificant app but I have a long bred distrust that PCs. although they theoretically should, actually WILL do the same thing the same way every time (shoot! Xfce opens up wrong 10-20% of the time) and an even deeper distrust of package managers. I prefer seeing it all laid out and if uninstalling I want to see it happen on-the-fly so I KNOW it did what I told it to do.... that neither it nor I screwed up.

No worries. I know we get stuck on things that we're familiar with and if we don't see any benefit to switching, then why should we. You won't get any judgement from me by sticking with tried and true (although, there are times I may make suggestions, like moving from 32bit to 64bit earlier in this thread -- but if you weren't interested, I would've dropped it with no hard feelings).

I'm just glad I could help you out with this transition and make it as smooth as possible

enorbet · 09-30-2016, 06:50 PM

Quote:

Originally Posted by bassmadrigal

After a quick search, it seems someone forked the original to github and added support for non-gzipped packages. He doesn't have a Slackware package available to download, but he does have a SlackBuild that should build a Slackware package for it. Theoretically, it should support discord-canary, but I haven't tried it (back at work again without easy access to my computer). In fact, looking through the script, it should even generate a slack-desc based on information in the deb's metadata. It seems like it should work great if you just want to convert a package. However, if you're interested in submitting that package to SBo, you'd likely need to do something like the SlackBuild I provided earlier. I doubt SBo would accept a requirement of deb2tgz for a SlackBuild to build.

Thankfully the need for deb2tgz is very slight since at least source, if not SBs, are so common. In this case my problem was simply that Discord-Canary is currently strictly 64 bit. On the new multilib system, merely extracting the .deb and manually copying (writing into) the apropraite directories in /usr did the trick. For a "very experimental" app it works flawlessly.

NOTE - Since it is free of charge (they hope to make money on addons while keeping the base service free of cost) and allows "conference calls" the devs hope to "do a coup" on Skype and the like, it may become of interest to many.

Quote:

Originally Posted by bassmadrigal

Unfortunately, I still use menuconfig (when I do occasionally rebuild the kernel, but it isn't a frequent event as I'm usually happy with Pat's), so I'm not sure what's going on there.

Understood. I was educated "hardcore", too

and am often very thankful that GUI doesn't dominate what survives and what gets abandoned. While it does have a massive share among so many users, if they want someone able to fix what they break while providing them with service, text will survive. It is, after all the nuts and bolts above machine language.

Quote:

Originally Posted by bassmadrigal

That's odd, but now looking back, I did do this all on a kinda Frankenstein 14.1 install (bits of original 14.1, some of an older -current recompiled, some completely upgraded outside of what Pat provided) rather than a 14.2 install, so there could've been missing dependencies that slipped through. But I'm glad you figured it out. And I can't take credit for the readelf thing. I found out about it on this forum, probably around a year ago (I think it was ponce who posted it on someone's thread to find what was missing). As you say, it is quite the powerful tool.

Yup. This is the positive flip side of a long-standing, evolved OpSys - Everything tends to "just be there". I used to install Dropline Gnome just to make some few GTK apps compile w/o problems (despite disliking Gnome, and even more intensely now) but that compromise is thankfully of less value now. I must add I'm finding problems with Xfce that I've never seen before and haven't yet concluded if that's specific to newer version Xfce or just 64 bit. Example - many customizations are either flaky or missing such as simply choosing an image file for Desktop Wallpaper. That, too, may seem a minor detail but is important to me since I tend to have no Desktop Icons, preferring a handful of Panel Icons and Krunner.

Quote:

Originally Posted by bassmadrigal

No worries. I know we get stuck on things that we're familiar with and if we don't see any benefit to switching, then why should we. You won't get any judgement from me by sticking with tried and true (although, there are times I may make suggestions, like moving from 32bit to 64bit earlier in this thread -- but if you weren't interested, I would've dropped it with no hard feelings).

We do, and in this case the graphic overview environment just speaks to me in a rather good example of "A picture is worth 1,000 words". I can do a lot of system maintenance and troubleshooting in less time than I can "cd /foo/foo2/foo3/foo4" and see the results in close to realtime.

Quote:

Originally Posted by bassmadrigal

I'm just glad I could help you out with this transition and make it as smooth as possible

It's working out very well. Between upgrading to 14.2 as well as 64 bit Multilib I have new (and actually improved) functionality. I'm even grateful for the struggle side as that's what makes us strong. A minor issue that should get solved soon is removing Pulseaudio since I have no need of it's "benefits" and it doesn't play nice with jack, which is a must have for me. On a more basic front, the kernel thing is still a bit perpelexing as i really don't grasp why, or even how it locks me out of options it displays such as the above mentioned HIGHHMEM and SPARSE areas.

I decided to try a build of the longterm stable 4.7.5 and did "make oldconfig" based on HUGE, selected 90% defaults on NEW, and only removed most support for hardware I know I don't have and likely never will. While it boots just fine as expected and is indeed "snappier" the NVIDIA installer seems confused, reporting "a driver already exists" when that is clearly impossible since there are in fact two separate /lib/{kernel version) directories, one for 4.4.14 and one for 4.7.5. Overriding works but it feels like it still needs tweaking as it....hmmm... occasionally 'stumbles". That's the best I can describe it for now as I don't know which has the major blame, nvidia or weird kernel option behaviour. Thankfully I often enjoy troubleshooting and problem solving and this too will fall.

"Not interested"? Oh Hell no! This is FUN! Many thanks.

bassmadrigal · 09-30-2016, 08:25 PM

Quote:

Originally Posted by enorbet

I must add I'm finding problems with Xfce that I've never seen before and haven't yet concluded if that's specific to newer version Xfce or just 64 bit. Example - many customizations are either flaky or missing such as simply choosing an image file for Desktop Wallpaper. That, too, may seem a minor detail but is important to me since I tend to have no Desktop Icons, preferring a handful of Panel Icons and Krunner.

I have a hard time believing this is due to it being 64bit. I'd imagine it is something that fell through the cracks with the updated XFCE, or, if you're carrying over configs, incompatible settings. If I remember right, the new XFCE version dropped support for some theme (or the theme was removed from Slackware, I don't really remember since I don't normally use XFCE or gtk apps). There were a lot of troubles on the forum until people picked a different theme (I think new one was something like adiwata).

Quote:

Originally Posted by enorbet

It's working out very well. Between upgrading to 14.2 as well as 64 bit Multilib I have new (and actually improved) functionality. I'm even grateful for the struggle side as that's what makes us strong. A minor issue that should get solved soon is removing Pulseaudio since I have no need of it's "benefits" and it doesn't play nice with jack, which is a must have for me. On a more basic front, the kernel thing is still a bit perpelexing as i really don't grasp why, or even how it locks me out of options it displays such as the above mentioned HIGHHMEM and SPARSE areas.

I ended up looking at a few of my configs (well, I ran make menuconfig) I had floating around (I picked the stock 3.10.17 for 14.1, a custom 3.18.24 based on Pat's 3.18 config, and a stock 4.4.14 for 14.2 -- all 64bit), and Sparse was set as the default with no other options, and there is no HIGHMEM option in any of the menus (nor is there any mention of it in the configs). I think HIGHMEM is only for 32bit kernels, as 64bit kernels don't have the same limitations 32bit kernels had in regards to addressable memory. In fact, I did some searching after this and found this gentoo wiki article that states it is specifically for x86 architecture, not x86_64.

Then, checking the help for the sparse section, it states that it will be the only option on some systems, and it specifically states "memory hotplug systems". However, doing some digging on Google, it seems this is another 32bit vs 64bit difference. According to this site (search for Memory Model), 64bit systems will only have sparse available because they won't bump into the addressing limits of RAM.

Quote:

If you have a 32-bit processor, selecting Flat Memory is what you need. CPUs with a larger address space support (like 64-bit CPUs) most likely only allow you to select "Sparse Memory" as you are not likely to have more than a few thousand terabytes of RAM ;-) When "Sparse Memory" is selected, "Sparse Memory virtual memmap" should be selected as well.

Quote:

Originally Posted by enorbet

I decided to try a build of the longterm stable 4.7.5 and did "make oldconfig" based on HUGE, selected 90% defaults on NEW, and only removed most support for hardware I know I don't have and likely never will. While it boots just fine as expected and is indeed "snappier" the NVIDIA installer seems confused, reporting "a driver already exists" when that is clearly impossible since there are in fact two separate /lib/{kernel version) directories, one for 4.4.14 and one for 4.7.5. Overriding works but it feels like it still needs tweaking as it....hmmm... occasionally 'stumbles". That's the best I can describe it for now as I don't know which has the major blame, nvidia or weird kernel option behaviour. Thankfully I often enjoy troubleshooting and problem solving and this too will fall.

Unfortunately, I have next to no experience with Nvidia drivers on Slackware. If you haven't already, you could check out the SlackBuilds on SBo that are managed by kingbeowulf. I know he has a lot of experience with the drivers and the issue might already be solved with the scripts. If they aren't, you could try emailing him or creating a new post on the forum about it to see if he sees it and can respond to it (or someone else who is also familiar with Nvidia drivers).

enorbet · 10-01-2016, 02:06 AM

Quote:

Originally Posted by bassmadrigal

I have a hard time believing this is due to it being 64bit. I'd imagine it is something that fell through the cracks with the updated XFCE, or, if you're carrying over configs, incompatible settings. If I remember right, the new XFCE version dropped support for some theme (or the theme was removed from Slackware, I don't really remember since I don't normally use XFCE or gtk apps). There were a lot of troubles on the forum until people picked a different theme (I think new one was something like adiwata).

I wasn't casting blame at Slack 64bit but rather Xfce on 64 bit systems. Even the one on 14.0 32 bit is not ideal. I'm actually rooting for the influx of bucks to make Enlightenment truly ready for prime time. That one can choose either a "normal" desktop or a tiling desktop for essentially the same environment has me just short of drooling.

Quote:

Originally Posted by bassmadrigal

I ended up looking at a few of my configs (well, I ran make menuconfig) I had floating around (I picked the stock 3.10.17 for 14.1, a custom 3.18.24 based on Pat's 3.18 config, and a stock 4.4.14 for 14.2 -- all 64bit), and Sparse was set as the default with no other options, and there is no HIGHMEM option in any of the menus (nor is there any mention of it in the configs). I think HIGHMEM is only for 32bit kernels, as 64bit kernels don't have the same limitations 32bit kernels had in regards to addressable memory. In fact, I did some searching after this and found this gentoo wiki article that states it is specifically for x86 architecture, not x86_64.

Then, checking the help for the sparse section, it states that it will be the only option on some systems, and it specifically states "memory hotplug systems". However, doing some digging on Google, it seems this is another 32bit vs 64bit difference. According to this site (search for Memory Model), 64bit systems will only have sparse available because they won't bump into the addressing limits of RAM.

I thought that might be the case in HIGHMEM but was a bit puzzled by SPARSE and unlike you I had bad luck with searches. In any case it's hard to not trust Linus which is why I went ahead and built one. I'm already confident that 4.7.5 will work a treat. I strongly suspect the problem with recognition was nvidia in this case as I jumped right in to the latest beta. I intend to roll back to stable tonight. FWIW as much as I love and appreciate SlackBuilds, I trust nvidia more. I am a huge nvidia fan which hails back some 20+ years when they were the only company other than Matrox making drivers for IBM's OS/2, which was my first real GUI OpSys, up from DOS with Shells. They've been building and distributing in Linux only a year or two less than I've been running Linux, 17 years.

Every day I see progress and I spend more time in 64 bit each day. I'm even seriously considering putting 64 bit on my old Thinkpad. Now seems to be the time.

bassmadrigal · 10-01-2016, 07:00 AM

Quote:

Originally Posted by enorbet

I wasn't casting blame at Slack 64bit but rather Xfce on 64 bit systems. Even the one on 14.0 32 bit is not ideal.

What I meant is that I suspect you'd see the same problems on a 32bit 14.2 install, but that's just speculation.

But I'm glad to see things going swimmingly. Good luck working through your remaining issues and let us know if you need help

enorbet · 10-02-2016, 03:36 AM

UPDATE : I'm pleased to report that rolling back to stable nvidia 367.44 worked a treat and now everything, including to my distinct pleasure, Wine !, works better than than it does in 32 bit. I can enable CSMT and not only does it open every time properly but it does it FAST! and even multiple instances work flawlessly. This may possibly have little or nothing to do with 32 bit vs/ 64 bit but rather old cluttered system vs/ fresh, new, clean system. So the custom 4.7.5 kernel is terrific as longterm stable should be. I'll pare it down some more later since my basic needs for realtime, low-latency are met and it runs great, and it's already about 17% smaller than HUGE. Gone are the days when one could pare a kernel down to fit on a floppy but shoot! most people don't still even have floppies!

Everything that remains now seems minor with one glaring exception. I really REALLY need to remove Pulseaudio and so far it eludes me. I followed the instructions at Docs Slackware.com and while I got to the kdm login screen (one failsafe reason I use it) most everything opens and crashes from any desktop. Thankgully just reinstalling the pulseaudio.txz from the DVD got me back to a working environment but this cannot stand. I NEED Jack and it, and I, (with no political concerns over "he who shall not be named") don't like it. It is always "underfoot" and my keyboard controls no longer work and I have zero need for such a networked software-level manager since my semi-pro sound card has hardware mixers/multiplexers. So this is what I will be working on now until it is fait accomplit. It may take a lot of time since so many apps are now dependent on pulse. Arrrggh! Seriously why are so many jumping on this ridiculous bandwagon? It's even ported to Mac now. Is it because most people these days use onboard crap audio?

I may post a new thread polling how many actually like pulseaudio, how many hate it and how many successfully have removed it. OK enough ranting and back to work.

bassmadrigal · 01-13-2017, 09:52 PM

For those who may come across this looking for discord SlackBuilds, upon hearing they came out with an official client, I have updated my SlackBuilds for this. I have a SlackBuild for both the "stable" client and the "ptb" (public testing build) client. I don't use discord at all, so I can't comment on if they work or not, but both builds started up fine and didn't dump errors to the console (always a good sign).

https://github.com/bassmadrigal/slac...nished/discord

Feel free to test and comment.

EDIT: Discord is still only 64bit.