LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 04-14-2017, 07:15 PM   #31
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 WMaker/XFCE
Posts: 289

Rep: Reputation: 64

Didier, when will the official documents be updated to reflect your explanation? Also the slack wiki is showing the same language as the official Slackware Documentation page. It is obvious that someone decided to break away from the official standard and why montagdude needs to be cognisant of the difference when he writes the code to ignore the "bad" usage of dashes, which is why I pointed this out in my post. Hopefully the exception code can handle reading from the right.
 
Old 04-14-2017, 07:15 PM   #32
montagdude
Member
 
Registered: Apr 2016
Posts: 456

Original Poster
Rep: Reputation: 303Reputation: 303Reputation: 303Reputation: 303
Quote:
Originally Posted by bamunds View Post
The official slackware packages don't always have four words ex aspell-en-7.1_0-x86_64-1.txz, at-spi2-atk-2.18.1-x86_64-1.txz, and polkit-kde-agent-1-9d74ae3_20120104git-x86_64-2.txz. So although there maybe a common standard it is not strictly held to by all developers.
There's nothing wrong with those package names. Like I said, they must have at least four words separated by dashes. The problem with yours was that they had less than four.

Quote:
Originally Posted by bamunds View Post
As I indicated in an earlier post, those packages were created using rmp2tgz and src2pkg. I would have thought that since rpm2tgz is a standard slackware package that it would set the package name correctly? And while src2pkg is not official, it is widely used for conversion of Debian packages when rpm's aren't available.
Well, I've never used those tools, so I'm not sure whether they are always supposed to produce valid package names automatically or how much of that is up to the user. If you can reproduce the invalid package names using those tools, it might be worth opening a new thread about that to figure out for sure how to avoid the problem in the future.

Quote:
Originally Posted by bamunds View Post
I've also been told that there is a number of limited places to put dashes and everything else must be underscore, ex -1bamunds_SBo is acceptable but -1bamunds-SBo would not be acceptable. For anyone else coming across this page in the future, the following link is from the Slackware official documentation site http://docs.slackware.com/howtos:sla...ding_a_package about building packages and describes package naming. What would be the simple way for a person to test their /var/log/packages for compliance going forward?
Yes, that link has it correct. Package names should have the form: app-version-arch-tag

None of the four components can contain dashes, except for the app portion. As for testing compliance, sboui-0.2.1 (when it's released) will give you warnings about any that are invalid.

Quote:
Originally Posted by bamunds View Post
As for my package names causing the segfault... I've removed, renamed and installpkg the three offending packages and indeed sboui-0.2 now runs correctly. I haven't fully tested yet, but will continue to provide feedback.

When I now look at keepassxc it's dependencies have all four packages listed and marked as installed. When I look at libinput (a dependency of keepassxc) it shows that it is a dependency for qt5, qt5-webkit, and keepassxc. This is consistent with my written records of dependencies. So it looks like you've identified the issue in 0.2 and how to enhance 0.2.1.

...

I can say that the application interface now starts in less than one second! Fantastic!
Excellent!

Quote:
Originally Posted by bamunds View Post
Also I'm surprised that sboui-0.1.1 did NOT seg fault for this reason. Is it a result of the new code you inserted looking for all packages?
The reason is that version 0.1.1 used a shell script to query the list of installed packages, whereas now it's handled in C++. Compiled languages are faster but have the possibility to segfault if they try to access a memory location that doesn't exist. In this case, it happened to you because the C++ code I wrote assumes that each package has at least four words separated by dashes. If it's actually less than four, it will end up trying to access an invalid memory location. The shell script method would have just returned empty strings instead, but not attempted to access any invalid memory location.

Quote:
Originally Posted by bamunds View Post
What about the build warnings about the 'rows' variable not being used?
Yes I'm sure that I had modified the CMAKE statement in the slackbuild correctly and used that corrected script to build the installed package. Could it be an issue with either my cmake-3.5.2-x86_64-1, gdb-7.11.1-x86_64-1, or gdbm-1.12-x86_64-1 versions? Or maybe the build environment, I didn't set any special environments?
The warnings about unused variables are expected. Actually, the fact that you saw them means that you compiled it successfully with the debug flags as intended. The only question is whether that debug sboui version was actually installed after you built it. Based on the output you posted, it looked like the old, non-debug version was still installed. If you want to try again, change the BUILD variable in the SlackBuild script from 1 to 2. Then, you can check the entry for sboui in /var/log/packages after installing and make sure it ends with -2_mntg instead of -1_mntg.

Quote:
Originally Posted by bamunds View Post
Do I need to rebuild without the debug code setting or can I continue to run with it as is?
Either way is fine.

Quote:
Originally Posted by bamunds View Post
When will 0.2.1 be on git?
I can't say exactly, but maybe this weekend or early next week.
 
Old 04-14-2017, 08:10 PM   #33
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 WMaker/XFCE
Posts: 289

Rep: Reputation: 64
Quote:
Originally Posted by montagdude View Post
There's nothing wrong with those package names. Like I said, they must have at least four words separated by dashes. The problem with yours was that they had less than four.
Actually the official document description says it must be four parts, no at-least in what is written. It also doesn't say that the app name can contain dashes. Instead dashes are delimiters between the four parts and underscrore is to be used to link words within the parts. Which is why I'm wondering if anyone is going to update what is written to clarify dashes are allowed in the app part?

Quote:
Originally Posted by montagdude View Post
Well, I've never used those tools, so I'm not sure whether they are always supposed to produce valid package names automatically or how much of that is up to the user. If you can reproduce the invalid package names using those tools, it might be worth opening a new thread about that to figure out for sure how to avoid the problem in the future.
I'll check the documentation and then contact the original developers to ask for any clarification.

Quote:
Originally Posted by montagdude View Post
... If you want to try again, change the BUILD variable in the SlackBuild script from 1 to 2. Then, you can check the entry for sboui in /var/log/packages after installing and make sure it ends with -2_mntg instead of -1_mntg.
Done, as a standard Release and everything is working fine.

Quote:
Originally Posted by montagdude View Post
I can't say exactly, but maybe this weekend or early next week.
Great thanks.
 
Old 04-14-2017, 10:16 PM   #34
bassmadrigal
Senior Member
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 3,750

Rep: Reputation: 1846Reputation: 1846Reputation: 1846Reputation: 1846Reputation: 1846Reputation: 1846Reputation: 1846Reputation: 1846Reputation: 1846Reputation: 1846Reputation: 1846
Quote:
Originally Posted by bamunds View Post
Actually the official document description says it must be four parts, no at-least in what is written. It also doesn't say that the app name can contain dashes. Instead dashes are delimiters between the four parts and underscrore is to be used to link words within the parts. Which is why I'm wondering if anyone is going to update what is written to clarify dashes are allowed in the app part?
This is just semantics. The package filename does have to have four parts, the name, the version, the arch, and the build tag. As others have said, it just uses dashes as delimiters and counts from the right to left. This is why it's important to not have dashes mixed into other locations, because it can screw with the package manager. If we use your previous example of sddm where you had a dash in the tag, we can use some color to better illustrate how the package manager views things.

app-name-version-arch-tag
sddm-0.12.0-x86_64-1alien-SBo

So, as you can see, the package manager would think the name of this program is sddm-0.12.0, with the version being x86_64.

If we look at two examples of the package names with not enough dashes, it sees the following.

XnViewMP-linux-0.83.x64
brave-0.13.0.x86_64
brave-0.13.5.x86_64
skypeforlinux-64

As you can now see, the package manager can't even assign these packages a name, and most wouldn't have a version assigned. This is why it was able to have brave installed twice, because upgradepkg can't find a package name to upgrade.

SlackDocs does specifically state that dashes are not to be used in the VERSION string, but it doesn't mention that the app name can't have dashes... although, if you're not familiar with how the package manager works, I could see that causing confusion. But you can always look at official packages to see how it's done there. Several official Slackware packages names contain dashes -- and when I say several, there's 401 packages out of 1332, or 30%, that contain at least one dash in their name in Slackware 14.2 (and just for fun... 226 have at least 2 dashes (17%), and 10 have 3 dashes (0.7%) and there aren't any that contain 4 or more dashes).

Quote:
(The dashes should appear as above, so if the version has a subversion like say 1.0 RC2 make sure you use 1.0_RC2 not 1.0-RC2. The arch should be something like i486 for example. The tag should consist of the build number and your initals, e.g. 1zb for Zaphod Beeblebrox's first build, 2zb for his second build, etc. Official slackware packages have only numbers as tags.)
But if you feel it should be better specified, it is a wiki that once registered, you're able to edit as well. And even though it is hosted on a subdomain of slackware.com, it doesn't mean it is official documentation. Anyone is free to write an article and add it there (I wrote an article on how to use UUIDs in your lilo and fstab, but it certainly isn't anything official). So, while it may be hosted on an official Slackware server (not sure if it is hosted on the Slackware server or just using the subdomain and being hosted somewhere else), it might not be considered "official documentation". If you're not comfortable with your editing skills, there is a discussion tab that allows you to make suggestions for someone else to incorporate.
 
1 members found this post helpful.
Old 04-15-2017, 09:58 AM   #35
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 WMaker/XFCE
Posts: 289

Rep: Reputation: 64
@bassmadrigal I really appreciate the example and clarification that you continue to provide to those learning the Slackware way. While my package names were not compliant with the package description, installpkg and upgradepkg both allowed me to install the packages, and allowed me to install more than one package of an application, so I could run either as desired from the command line with specific name rather than a link to only "brave". I've read the documents and the "slackware-way" for installing packages and I'm wondering if why they aren't complete on this subject, so I'll pursue the comment as you've suggested.

Perhaps someone could further help educate me on naming generation. Does anyone know why the three rpm binary packages converted using the "official" rpm2targz package builder didn't get the proper naming?

I call it an "official" package because it is installed in every default installation, and it is specifically mention in the Slackware Esssentials, Slackware Wiki, and documentation link from slackware.com under Package installation. I know that it is an ageless package which has existed in Slackware for over 15 years. Is it maintained still?

I read on many LQ threads that rpm2targz is a packager of last resort if one can't find an "unofficial" Slackbuild or build from source. I've even read that gnashley's src2pkg is a better tool, however when using it, it too doesn't generate the package naming convention as seen in my XnView package name, unless one forces the options (yes I also RTFM and the Tutorials/Examples). Slackbuilds doesn't even mention the naming convention to use for creating a slackbuild script. I've always looked for packages in the following order:
1) packages.slackware.com (extra directory has some nice ones)
2) slackbuilds,
3) rpm binaries on OpenSuSe (seems they are best quality for rpm2targz )
4) debian packages and then convert with src2pkg
5) straight source to config/make/make install (I've actually only done this once and it failed after installpkg).

I'm sure many senior member experts here would have number 5) as number 2). The question is which will produce the more compliant "slackware-way" package in both name and file system placement rpm2targz or src2pkg? (Sorry gnashley I'm not trying to bash your package, the documentation is excellent, the tool is complex, the results are mixed compared to packages converted with rpm2targz.)

Thanks, and again I'll head over to the documentation project to request clarity in on naming conventions.
 
Old 04-15-2017, 10:20 AM   #36
solarfields
Member
 
Registered: Feb 2006
Location: Outer Shpongolia
Distribution: Slackware
Posts: 700

Rep: Reputation: Disabled
bassmadrigal,

iirc, a slackware package is being read backwards, therefore you can have dashes in the name, but not in the version. Also, the tag is separated by a _ not a -
 
Old 04-15-2017, 12:47 PM   #37
bassmadrigal
Senior Member
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 3,750

Rep: Reputation: 1846Reputation: 1846Reputation: 1846Reputation: 1846Reputation: 1846Reputation: 1846Reputation: 1846Reputation: 1846Reputation: 1846Reputation: 1846Reputation: 1846
Personally, my order is as follows:

1. Official Slackware packages
2. SBo
3. Eric's packages
4. Create my own SlackBuiild
4.1. Prefer building from source
4.2. If source isn't available, I'll manually extract the package's contents and repackage them into a Slackware package. (That's what I did with discord.)

I haven't used rpm2tgz or deb2tgz in quite a few years, mainly because I was running into similar issues to what you're seeing now. I haven't used src2pkg in a much longer period of time.

I'm not sure if {rpm,deb}2tgz take into account package names. They might just use what's already there rather than verifying it is a proper name. I know I wouldn't want to code something to figure that out, especially if the original rpms or debs can come with broken names. But to know that, someone would have to dig through the scripts to see how the handle it.

Quote:
Originally Posted by solarfields View Post
bassmadrigal,

iirc, a slackware package is being read backwards, therefore you can have dashes in the name, but not in the version. Also, the tag is separated by a _ not a -
That is correct. The example I used above was from a broken package name that bamunds provided earlier in the thread. There was a dash in the tag separating 1alien from SBo rather than an underscore, so it threw off the parsing of the package name.

@montagdude, sorry for derailing your thread
 
Old 04-15-2017, 02:03 PM   #38
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 WMaker/XFCE
Posts: 289

Rep: Reputation: 64
montagdude, I also must apologize for derailing your thread about the sboui tool. I will only post with input about the tool going forward.
Please post when the next release is available.
Should I do any cleanup of the /var/log/packages earlier posts to compact this thread?
 
Old 04-15-2017, 04:53 PM   #39
montagdude
Member
 
Registered: Apr 2016
Posts: 456

Original Poster
Rep: Reputation: 303Reputation: 303Reputation: 303Reputation: 303
It's okay, it was mostly related to the topic anyway. But I would say any further discussion of how src2pkg and rpm2tgz name packages should go in its own thread.
 
Old 04-17-2017, 08:09 PM   #40
montagdude
Member
 
Registered: Apr 2016
Posts: 456

Original Poster
Rep: Reputation: 303Reputation: 303Reputation: 303Reputation: 303
sboui-0.2.1 has been released on Github. This release is mostly to fix bugs and improve robustness. Here are the changes:
  • Don't warn about skipping dependencies unless actually installing the package
  • Actually close .info file in ShellReader::close() (woops! but had no noticeable effect in use)
  • Check for and warn about invalid installed package names (previously would segfault)
  • Check for and warn about missing .info files when encountered
  • Better check for upgradable pacakges. A package is considered upgradable if installed_version != upgradable_version, except when the only difference is a trailing tag starting with an underscore in installed_version (some packages for kernel modules are like this). Previously, anything after the available_version text was considered a tag, even if it didn't begin with an underscore.
  • Restore original selection after pressing Esc in ComboBoxes.
It will be available on SBo next time they update the site (usually towards the end of the week). Or, you can get the SlackBuild from my Github page if you want to try it out right away.

About testing for upgradable packages, I wouldn't mind having some discussion about that. The only way to make sure a package is marked as upgradable is to do a strict test for whether installed_version = available_version. The problem with that is that some SlackBuilds append a tag to the version string during install. For example, virtualbox-kernel appends "_${uname -r}" to the version number, so a strict installed_version = available_version test would always mark it as upgradable even if it's really at the latest version. The test I am using now (described above in the list) is the best way I can think of to do it, but it is possible for it to miss something that should be marked upgradable in some unusual circumstances.
 
Old 04-23-2017, 11:44 PM   #41
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 WMaker/XFCE
Posts: 289

Rep: Reputation: 64
montagdude, tonight I tried to upgrade sboui from within sboui. Is that supported? The results first show that a package is being upgraded from a different repository and asks to proceed (nice little touch) then it showed the package installed (and I like the little popup screen that says Packages failed/installed/etc). The only problem was when I checked /var/log/packages it still reported that sboui-0.2 was installed and not sboui-0.2.1. I sync'd again and then look for Upgradeable packages sboui again shows up for upgrade. Tried and second time and got same results as first.

I thought I'd try a sbotools cli upgrade to make sure it wasn't a sbotools shortfall. Sboupgrade sboui says: libconfig (libconfig-1.5-x86_64-1_SBo) is already installed.
sboui (sboui-0.2-x86_64-2_mntg) is already installed. If I attempt to sboinstall sboui-0.2.1 is says "Unable to locate sboui-0.2.1 in the SlackBuilds.org tree" However I confirmed at slackbuilds.org that sboui-0.2.1 is in the tree. What I found was that I had to removepkg the local slackbuild package (found in /tmp) and then sboinstall sboui to get the latest version sboui-0.2.1 to install. It was like it wouldn't upgrade something that doesn't have an SBo tag. However, I also have alienbob's version of ffmpeg installed (same version number as in slackbuilds.org), and when I attempted to re-install (since version number wouldn't show in an upgrade list) it it had no problem removing the existing package, building new and installing. So perhaps this is an "upgrade" only issue?

Having used the tool for a while it is a huge assistance to use over the cli of sbotools. It offers a great way for users to to keep their slackbuilds up to date.

There are some additional improvements I'd like to suggest. First, when showing the packages for upgrade, you show in the lower screen the Installed and Available versions, but only the version number and not the build number, it might be helpful (like with the sboui which was a local build) to know that I am replacing a local build with an slackbuild (assuming that actually is possible and works). After an upgrade the slack-desc are not presented to the user, that might be a nice option on that "Failed/Installed/etc" screen to offer to see the "Read Readme" again so that any last minute instructions not included in the info file are seen now from the Slack-Desc file. Another nice touch would be if I could see the last screen of install for a package, in (this case I'm thinking the Package Description, Executing Install, Cleaning) as an option on that "installed" list of options. I suggest the last because if I select any other "Readme or View Files" as I'm flipped to text viewer I see that last set of console outputs and thought that would be nice to have seen that before or option to see when I'm taken back to the install/upgrade screen of sboui.

Really enjoying the program. Thank you developing it and hope my feedback is helpful. Cheers, Brian
 
Old 04-24-2017, 01:15 PM   #42
montagdude
Member
 
Registered: Apr 2016
Posts: 456

Original Poster
Rep: Reputation: 303Reputation: 303Reputation: 303Reputation: 303
Quote:
Originally Posted by bamunds View Post
montagdude, tonight I tried to upgrade sboui from within sboui. Is that supported?
Yes, it is, but you will need to quit and start it again to for the changes to take effect.

Quote:
Originally Posted by bamunds View Post
The results first show that a package is being upgraded from a different repository and asks to proceed (nice little touch) then it showed the package installed (and I like the little popup screen that says Packages failed/installed/etc). The only problem was when I checked /var/log/packages it still reported that sboui-0.2 was installed and not sboui-0.2.1. I sync'd again and then look for Upgradeable packages sboui again shows up for upgrade. Tried and second time and got same results as first.

I thought I'd try a sbotools cli upgrade to make sure it wasn't a sbotools shortfall. Sboupgrade sboui says: libconfig (libconfig-1.5-x86_64-1_SBo) is already installed.
sboui (sboui-0.2-x86_64-2_mntg) is already installed. If I attempt to sboinstall sboui-0.2.1 is says "Unable to locate sboui-0.2.1 in the SlackBuilds.org tree" However I confirmed at slackbuilds.org that sboui-0.2.1 is in the tree. What I found was that I had to removepkg the local slackbuild package (found in /tmp) and then sboinstall sboui to get the latest version sboui-0.2.1 to install. It was like it wouldn't upgrade something that doesn't have an SBo tag. However, I also have alienbob's version of ffmpeg installed (same version number as in slackbuilds.org), and when I attempted to re-install (since version number wouldn't show in an upgrade list) it it had no problem removing the existing package, building new and installing. So perhaps this is an "upgrade" only issue?
I've noticed something like this before with sbotools, but I need to do some more testing to find out what exactly it is doing. I think the "sboupgrade" command may not work with packages installed from a different repository. The reinstall operation would have worked, because sboui first removes the package and then installs again with the reinstall operation.

Anyway, I do have a plan to deal with these little quirks of the different tools. In the next version, sboui will first try the regular upgrade command, but then it will check to make sure it was actually upgraded by comparing the installed version with the version available in the SBo repo. If it wasn't upgraded, but there wasn't an error during the operation (like an MD5 mismatch), it will use the reinstall method to upgrade it instead.

Quote:
Originally Posted by bamunds View Post
There are some additional improvements I'd like to suggest. First, when showing the packages for upgrade, you show in the lower screen the Installed and Available versions, but only the version number and not the build number, it might be helpful (like with the sboui which was a local build) to know that I am replacing a local build with an slackbuild (assuming that actually is possible and works).
There are already a couple new features in the development branch to help with this. The first is an action presented when you select an entry in the list called "Show package info," which will display the name, available version, whether it is installed, and for installed packages, the installed version and complete package name. The second is a package blacklist. It works more or less the same way as the blacklist for slackpkg, except that it operates only on installed packages, so it prevents upgrade/remove/reinstalling but not installing in the first place. You can use regex patterns to make sure packages with a specific build/tag are not changed.

Quote:
Originally Posted by bamunds View Post
After an upgrade the slack-desc are not presented to the user, that might be a nice option on that "Failed/Installed/etc" screen to offer to see the "Read Readme" again so that any last minute instructions not included in the info file are seen now from the Slack-Desc file.
I might be able to make it so the actions list is re-displayed after the operation is complete. I'll look into it.

Quote:
Originally Posted by bamunds View Post
Another nice touch would be if I could see the last screen of install for a package, in (this case I'm thinking the Package Description, Executing Install, Cleaning) as an option on that "installed" list of options. I suggest the last because if I select any other "Readme or View Files" as I'm flipped to text viewer I see that last set of console outputs and thought that would be nice to have seen that before or option to see when I'm taken back to the install/upgrade screen of sboui.
Would a keyboard shortcut that drops to a view of the command line output do the job you're describing?

Quote:
Originally Posted by bamunds View Post
Really enjoying the program. Thank you developing it and hope my feedback is helpful. Cheers, Brian
I'm glad you like it, and I really appreciate your feedback and suggestions.

Last edited by montagdude; 04-24-2017 at 01:19 PM.
 
Old 04-24-2017, 02:08 PM   #43
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 WMaker/XFCE
Posts: 289

Rep: Reputation: 64
Quote:
Originally Posted by montagdude View Post
Yes, it is, but you will need to quit and start it again to for the changes to take effect.
Great, thought as much and had tried quitting to run ls /var/log/packages | grep sboui. That's when I found the issue.
Quote:
Originally Posted by montagdude View Post
I've noticed something like this before with sbotools,...
are you finding it with sbopkg or other tool?
Quote:
Originally Posted by montagdude View Post
..when you select an entry in the list called "Show package info," which will display the name, available version, whether it is installed, and for installed packages, the installed version and complete package name. The second is a package blacklist. It works more or less the same way as the blacklist for slackpkg, except that it operates only on installed packages, so it prevents upgrade/remove/reinstalling but not installing in the first place. You can use regex patterns to make sure packages with a specific build/tag are not changed.
Great ideas.
Quote:
Originally Posted by montagdude View Post
Would a keyboard shortcut that drops to a view of the command line output do the job you're describing?
Yes it would.

Keep up the great work!
 
Old 04-24-2017, 09:36 PM   #44
montagdude
Member
 
Registered: Apr 2016
Posts: 456

Original Poster
Rep: Reputation: 303Reputation: 303Reputation: 303Reputation: 303
Quote:
Originally Posted by bamunds View Post
are you finding it with sbopkg or other tool?
It doesn't happen with sbopkg, because sbopkg doesn't have a separate upgrade option. You just use the regular install option, which builds and installs the package with `upgradepkg --reinstall --install-new`. Installs, reinstalls, and upgrades are all taken care of naturally with that command. sbotools uses the same upgradepkg command, but it also checks first to see if the package is upgradable. It appears that the check does not detect packages installed from places other than SBo. Whether that's intentional or not, I'm not sure.

Last edited by montagdude; 04-24-2017 at 09:37 PM.
 
Old 04-25-2017, 04:29 PM   #45
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 WMaker/XFCE
Posts: 289

Rep: Reputation: 64
I just attempted to use sboui to upgrade keepassxc and realized that there is no way to insert options. sbotools progresses by asking about building dependencies and also if there are any options to insert. Keepassxc allows for XC_HTTP=ON and XC_AUTO_TYPE=OFF, but with sboui there is no place that was obvious to setup these options and pass to sboupgrade. So I dropped out to cli and ran the upgrade from there. Did I miss something about entering options for the building of packages?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Call for Testers: MATE 1.17 willysr Slackware 25 04-21-2017 12:55 PM
[SOLVED] Call for Testers: MATE 1.14 for -Current willysr Slackware 13 05-27-2016 08:08 AM
Updating w3af to version 1.6.49 in SBo, need testers mralk3 Slackware 3 12-12-2015 05:54 PM
Call for Testers: MATE 1.8 willysr Slackware 137 08-06-2014 01:50 AM
ncurses-5.2-28 conflicts with file from package ncurses-5.2-12 tubby Linux - Software 4 06-16-2002 12:00 AM


All times are GMT -5. The time now is 09:00 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration