SlackBuild Installation of mono-4.2.2.10 fails (Slackware64-current)
 

I am trying to install KeePass 2.30, and that installation fails because mono is not installed. However, when I attempt the mono installation (I'm using the step by step instructions from "SlackBuild Usage HOWTO"), it fails because it can't find msc.

Well, I can't find msc in any of the mirrors, so I have run into a wall here. Any help would be appreciated.

if you are on current using on it scripts made for Slackware stable and hoping that they will work doesn't always go well.

you are better off using a dedicated repository for current or, in this phase when SBo's submissions are closed because everything is getting ready for 14.2, SBo's git master branch.

you can clone the two repository above alternatively with these two commands

Thank you, Ponce! I'll give that a try this evening when I get back home. I'll let you know the results.

Just as an FYI, there's a version of Keepass that doesn't have the mono/.NET dependency. It is called KeepassX. I'm running version 2.something on current now. I don't know if it will read regular Keepass databases or not though, which you'd want to check if you are considering switching.

I've also been using KeePassX for years. There's also a version that runs on Android which makes it handy. I keep a copy of my keepass database on Google Drive and keep all my laptops and phone in sync. I'm sure a similar configuration would work for the mono/.Net version. But, unless I already had an existing database that required it, I don't know what features would justify the extra dependency.

Maybe the Firefox KeeFox plugin that integrates KeePass is justification?

I have used KeePass on all my Windows machines for years. I have used it on all my Linux boxes for years, too, both KeePassX and KeePass2. But I can't for the life of me get it to install on this new Slackware64-current box. The mono build always fails during the mcs phase, regardless of which mono.SlackBuild I use.

This is so frustrating. I opted for -current because of its use of the newer kernel. Now I'm wondering if I should pack it in and do a clean install using the stable version. My whole reason for going to Slackware as opposed to Fedora or Mint or Debian is that I want to learn Linux this time around instead of just pointing and clicking my way through the eye candy. I expected some woes along the way, but whoa! Luckily I have a Windows laptop right next to me that I can grab passwords from.

So, I reckon I'll take suggestions from you guys about whether or not I might have better luck with KeePass2 if I use the stable version of Slackware. OR, I'm more than willing to use another password manager as long as it's local and can read my KeePass2 database. I'm switching from NoteTab Pro to Bluefish to do my HTML editing for my web site, so I am not above swapping one app for another.

Thank y'all for even caring enough to consider helping. It's encouraging.

Richard

According to the required line on mono.info, it requires libgdiplus. Do you have that installed? SlackBuilds won't get the required dependencies. The READMEs and/or info files should inform you what required dependencies you need to install before you can install that. Once you're more familiar with the process, you may want to look into more automated scripts like sbopkg and sqg to help make this easier.

My google-fu didn't find a different password manager that could natively use a KeePass2 database.

I'd be fairly confident that if you installed 14.1, you'd be able to use the 14.1 versions at SlackBuilds.org to get a usable setup. (I can't vouch for that though; I don't happen to have anything that needs mono/.Net.)

Given that we're already at '14.2 release candidate 2', installing 14.1 strikes me as a transient solution. 14.2 will be here 'Real Soon Now' and Slackbuilds.org will catch up 'Soon After That'

So, I guess I'd be tempted to either put up with the current awkwardness until that gets strightened out, or see about exporting your KeePass2 database to a form that KeePassX could use.

(My personal guess for "Real Soon Now" is Beltane)

We'll consider this solved, then.
 

Thank you, Linux users. I have persuaded myself that putting up with this current awkwardness until 14.2 gets released is probably the best advice to follow. I will also install libgdiplus and give the whole process another go.

Are we having fun yet?

KeepassX has support for the old keepass1 database as an imported database.

Also that KeePassX supports KeePass2 databases.

https://www.keepassx.org/faq/#q_2

You may also wish to make use of a bash script that comes installed with sbopkg. It generates queue files that allow you to do decent dependency resolution for SBo scripts.

Then edit /usr/bin/sqg with vim or nano and have it use Ponce's repo:

You can force sbopkg to use Ponce's repo too by editing /etc/sbopkg/sbopkg.conf:

Then run:

Or you can generate a queue file for a single application with sqg like so:

I've been running Slackware64-current by referring to ponce's repository on github for about a year without issues.

that's probably because David (55020) contributed also to that repository and much more than me in the last year :) (and this way the not-working stuff sensibly reduced)

I've had my hands full learning the ropes of Slackware during this time (after having ditched Debian). I wanted to contribute but rarely found anything broken! :)

You guys rock.
 

'Nuff said.

Almost there...
 

After reverting back to the stable release, I was able to get KeePass 2.30 installed with no problems. So I went back to -current.

I've spent the past days learning how to use Slackbuild from Ponce's pages, and things have gone well. I have done a clean -current install of Slackware64 and have multilib support up and running. The proprietary nVidia drivers are working; I am using OpenBox in KDE. Things are peachy keen.

However, when I run ./KeePass.Slackbuild, it errors out with this:
cp: cannot stat '/home/richard/Downloads/tmp/files/KeePass.desktop' : No such file or directory

Directly before that, the script had been busily extracting source files and had just started inflating TrlUtil.csproj. Then the process crapped out with the above error message.

Should I unzip the source myself to see if it even HAS a files subdirectory within it?

This shtuff is fun.