LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
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 11-30-2017, 06:32 PM   #106
Gordie
Member
 
Registered: Aug 2007
Distribution: Slackware, Puppy
Posts: 306

Rep: Reputation: 89

Quote:
Originally Posted by travis82 View Post
Awesome. Works great with sbotools here. Many thanks. Is to possible to have an option to upgrade all upgradable packages?
As it stands now even blacklisted packages that are upgradeable are marked. Would not make me a happy camper if upgrading took precedence over blacklists. Would surely screw up my system bigtime
 
Old 11-30-2017, 09:38 PM   #107
montagdude
Member
 
Registered: Apr 2016
Distribution: Slackware
Posts: 724

Original Poster
Rep: Reputation: 526Reputation: 526Reputation: 526Reputation: 526Reputation: 526Reputation: 526
Quote:
Originally Posted by travis82 View Post
Awesome. Works great with sbotools here. Many thanks. Is to possible to have an option to upgrade all upgradable packages?
The way to do that is to filter by upgradable packages, then tag all of them (the fastest way to do that is to tag all of the groups on the left), and then hit 'u' to upgrade them. It's a little non-intuitive, I know, but it works well.
 
Old 11-30-2017, 09:42 PM   #108
montagdude
Member
 
Registered: Apr 2016
Distribution: Slackware
Posts: 724

Original Poster
Rep: Reputation: 526Reputation: 526Reputation: 526Reputation: 526Reputation: 526Reputation: 526
Quote:
Originally Posted by Gordie View Post
As it stands now even blacklisted packages that are upgradeable are marked. Would not make me a happy camper if upgrading took precedence over blacklists. Would surely screw up my system bigtime
That shouldn't happen. Nothing listed in the blacklisted filter should also appear in the upgradable filter, and even if they did, there is no option to upgrade, reinstall, or remove them. Are you sure you are blacklisting correctly? Do the packages in question appear in the blacklisted filter?

I have Plasma 5 from the ktown repository installed on my system, and I've blacklisted them. They all appear in the blacklisted filter, but not the upgradable one. In my /etc/sboui/package_blacklist, I have:

Code:
# This one will blacklist all Alien Bob packages
[0-9]+alien
 
Old 11-30-2017, 11:28 PM   #109
Gordie
Member
 
Registered: Aug 2007
Distribution: Slackware, Puppy
Posts: 306

Rep: Reputation: 89
Quote:
Originally Posted by montagdude View Post
That shouldn't happen. Nothing listed in the blacklisted filter should also appear in the upgradable filter, and even if they did, there is no option to upgrade, reinstall, or remove them. Are you sure you are blacklisting correctly? Do the packages in question appear in the blacklisted filter?

I have Plasma 5 from the ktown repository installed on my system, and I've blacklisted them. They all appear in the blacklisted filter, but not the upgradable one. In my /etc/sboui/package_blacklist, I have:

Code:
# This one will blacklist all Alien Bob packages
[0-9]+alien
Oh Boy. What a nut I am. I was under the impression that the blacklist was controlled by sbopkg. I could have really messed things up.

Thanks for the tip. Works just like you say now for me.

EDIT - The blacklist from sbopkg had enough effect that I didn't catch on and look for a better way.
For instance, the blacklisted items also showed on the updated list. When you tried to update a red window appeared telling you that the item was blacklisted and giving you a chance to back out

Last edited by Gordie; 12-01-2017 at 11:28 AM.
 
Old 12-04-2017, 05:17 PM   #110
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 Multilib
Posts: 366

Rep: Reputation: 82
montagdude - feature request....maybe OR this might just be me realizing the strength of sboui..:-)
With sbopkg I'm able to modify the .slackbuild and .info files. The .slackbuild I'll modify to all for the latest version to be built and I also often add the mulitlib suggested options of LDFLAGS="-L /usr/lib${LIBDIRSUFFIX}" so that the packages build as 64 bit and don't accidentally get built with the 32 bit libraries (of course unless I'm trying to build a 32 bit app). The .info package gets modified for pulling the latest version and MD5SUM value available from the developers site. I could eliminate sbopkg from my system and use only sboui if I know how to accomplish the same steps within sboui.

For the 64 bit library reference I'm wondering if this is where the system environment CLO's or install/upgrade modifiers could be used?
For the version control I'm not aware of anyway to make that happen, unless since we are using 'vi' for the read/editor could I actually make the change and exit with ":wq" which would overwrite the existing .info or .slackbuild and when the install happens the edited (local in sbopkg terms) file would be used?

Or have I already forgotten more than I knew at one time?
 
Old 12-04-2017, 11:33 PM   #111
montagdude
Member
 
Registered: Apr 2016
Distribution: Slackware
Posts: 724

Original Poster
Rep: Reputation: 526Reputation: 526Reputation: 526Reputation: 526Reputation: 526Reputation: 526
Quote:
Originally Posted by bamunds View Post
montagdude - feature request....maybe OR this might just be me realizing the strength of sboui..:-)
With sbopkg I'm able to modify the .slackbuild and .info files. The .slackbuild I'll modify to all for the latest version to be built and I also often add the mulitlib suggested options of LDFLAGS="-L /usr/lib${LIBDIRSUFFIX}" so that the packages build as 64 bit and don't accidentally get built with the 32 bit libraries (of course unless I'm trying to build a 32 bit app). The .info package gets modified for pulling the latest version and MD5SUM value available from the developers site.
You can modify the files for a SlackBuild by using the Browse Files option and then editing and saving them. Your changes will get overwritten once you sync the repo, though.

Quote:
Originally Posted by bamunds View Post
I could eliminate sbopkg from my system and use only sboui if I know how to accomplish the same steps within sboui.
You will still need sbopkg or other similar tool. sboui is not meant to be a full package manager. It relies on the package manager to create and sync the local repository and to install/upgrade packages.

Quote:
Originally Posted by bamunds View Post
For the 64 bit library reference I'm wondering if this is where the system environment CLO's or install/upgrade modifiers could be used?
For the version control I'm not aware of anyway to make that happen, unless since we are using 'vi' for the read/editor could I actually make the change and exit with ":wq" which would overwrite the existing .info or .slackbuild and when the install happens the edited (local in sbopkg terms) file would be used?

Or have I already forgotten more than I knew at one time?
I think you could set LDFLAGS and other environment variables for configure scripts as build options. I'm not sure, because I haven't tried it, but it seems like it should work.

Last edited by montagdude; 12-05-2017 at 08:47 AM. Reason: typed sboui when I meant sbopkg
 
1 members found this post helpful.
Old 12-05-2017, 03:33 PM   #112
bamunds
Member
 
Registered: Sep 2013
Location: Mounds View MN
Distribution: Slackware64-14.2 Multilib
Posts: 366

Rep: Reputation: 82
Quote:
Originally Posted by montagdude View Post
You can modify the files for a SlackBuild by using the Browse Files option and then editing and saving them. Your changes will get overwritten once you sync the repo, though.
Great this is the conclusion I thought of when writing further in my first post. Also with a simple sync the old file is returned. I don't think sbopkg is persistent with local edits after syncing either, so the steps are the same.

Quote:
Originally Posted by montagdude View Post
You will still need sbopkg or other similar tool. sboui is not meant to be a full package manager. It relies on the package manager to create and sync the local repository and to install/upgrade packages.
Actually sbotools will be the package manager in my case. Since sbotools is also a package manager and can be used in place of sbopkg.

Quote:
Originally Posted by montagdude View Post
I think you could set LDFLAGS and other environment variables for configure scripts as build options. I'm not sure, because I haven't tried it, but it seems like it should work.
I'll give it a try and leave feedback here. If nothing else I can always simply Browse files and with the reader/editor of 'vi' the LDFLAGS can be added to the .slackbuild.
 
Old 12-08-2017, 12:41 AM   #113
Gordie
Member
 
Registered: Aug 2007
Distribution: Slackware, Puppy
Posts: 306

Rep: Reputation: 89
Not sure what to make of this. sbopkg showed Leafpad, elinks, lame and virtualbox-kernel as being upgradable. sboui didn't pick any of them as upgradable.

I used sbopkg to upgrade them
 
Old 12-08-2017, 01:07 AM   #114
montagdude
Member
 
Registered: Apr 2016
Distribution: Slackware
Posts: 724

Original Poster
Rep: Reputation: 526Reputation: 526Reputation: 526Reputation: 526Reputation: 526Reputation: 526
Quote:
Originally Posted by Gordie View Post
Not sure what to make of this. sbopkg showed Leafpad, elinks, lame and virtualbox-kernel as being upgradable. sboui didn't pick any of them as upgradable.

I used sbopkg to upgrade them
Is it possible you had some of those installed from another repository (e.g. alien), and they were blacklisted? Did you happen to write down the installed versions prior to upgrading?

For virtualbox-kernel, I have a hunch that sbopkg may have thought it was upgradable when it really wasn't due to the kernel tag that is added to the end of the version number, but I'm not familiar enough with how sbopkg handles packages like that to say for sure.

Last edited by montagdude; 12-08-2017 at 01:09 AM.
 
Old 12-08-2017, 01:13 AM   #115
Gordie
Member
 
Registered: Aug 2007
Distribution: Slackware, Puppy
Posts: 306

Rep: Reputation: 89
Quote:
Originally Posted by montagdude View Post
Is it possible you had some of those installed from another repository (e.g. alien), and they were blacklisted? Did you happen to write down the installed versions prior to upgrading?

For virtualbox-kernel, I have a hunch that sbopkg may have thought it was upgradable when it really wasn't due to the kernel tag that is added to the end of the version number, but I'm not familiar enough with how sbopkg handles packages like that to say for sure.
I have copies of all. They are not blacklisted, I checked that first. Not a big deal for me but sure is curious

leafpad-0.8.18.1-x86_64-1_SBo

lame-3.99.5-x86_64-1_SBo

elinks-git20131231-x86_64-2_SBo

virtualbox-5.0.40-x86_64-1_SBo
 
1 members found this post helpful.
Old 12-08-2017, 01:37 AM   #116
montagdude
Member
 
Registered: Apr 2016
Distribution: Slackware
Posts: 724

Original Poster
Rep: Reputation: 526Reputation: 526Reputation: 526Reputation: 526Reputation: 526Reputation: 526
Okay, thanks. I'll look into it.
 
Old 12-08-2017, 08:36 AM   #117
montagdude
Member
 
Registered: Apr 2016
Distribution: Slackware
Posts: 724

Original Poster
Rep: Reputation: 526Reputation: 526Reputation: 526Reputation: 526Reputation: 526Reputation: 526
Quote:
Originally Posted by Gordie View Post
I have copies of all. They are not blacklisted, I checked that first. Not a big deal for me but sure is curious

leafpad-0.8.18.1-x86_64-1_SBo

lame-3.99.5-x86_64-1_SBo

elinks-git20131231-x86_64-2_SBo

virtualbox-5.0.40-x86_64-1_SBo
Going by the version number, those are all the latest releases. However, the SlackBuilds for leafpad, lame, and elinks were all updated recently without changing the version number. sboui checks whether a package is upgradable by comparing the version number in the installed package with what is in the .info file, so that's why none of them were marked as upgradable by sboui. sbopkg must check the SlackBuild scripts themselves for changes. I wonder if it would be better to do it that way in sboui. That might introduce complications with blacklisting, though. I'll have to give it some thought.

Last edited by montagdude; 12-08-2017 at 08:38 AM.
 
Old 12-08-2017, 08:53 AM   #118
bassmadrigal
Senior Member
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 4,533

Rep: Reputation: 2486Reputation: 2486Reputation: 2486Reputation: 2486Reputation: 2486Reputation: 2486Reputation: 2486Reputation: 2486Reputation: 2486Reputation: 2486Reputation: 2486
Quote:
Originally Posted by montagdude View Post
Going by the version number, those are all the latest releases. However, the SlackBuilds for leafpad, lame, and elinks were all updated recently without changing the version number. sboui checks whether a package is upgradable by comparing the version number in the installed package with what is in the .info file, so that's why none of them were marked as upgradable by sboui. sbopkg must check the SlackBuild scripts themselves for changes. I wonder if it would be better to do it that way in sboui. That might introduce complications with blacklisting, though. I'll have to give it some thought.
Ideally, if a SlackBuild (or info) is updated without a new version number, the $BUILD should be incremented. I checked lame and that was the case there (went from BUILD 1 to BUILD 2). Pat does the same thing with the official tree (incrementing BUILD if the version didn't change), so it might be something to consider adding to yours, as I imagine this is one of the things sbopkg checks to determine upgrades.
 
2 members found this post helpful.
Old 12-08-2017, 08:57 AM   #119
montagdude
Member
 
Registered: Apr 2016
Distribution: Slackware
Posts: 724

Original Poster
Rep: Reputation: 526Reputation: 526Reputation: 526Reputation: 526Reputation: 526Reputation: 526
Quote:
Originally Posted by bassmadrigal View Post
Ideally, if a SlackBuild (or info) is updated without a new version number, the $BUILD should be incremented. I checked lame and that was the case there (went from BUILD 1 to BUILD 2). Pat does the same thing with the official tree (incrementing BUILD if the version didn't change), so it might be something to consider adding to yours, as I imagine this is one of the things sbopkg checks to determine upgrades.
Yup, I think you are right. It would be fairly simple to add the BUILD number to the check for upgradable packages, and I don't think it would cause problems with anything else.
 
Old 12-08-2017, 12:14 PM   #120
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,136
Blog Entries: 4

Rep: Reputation: 1565Reputation: 1565Reputation: 1565Reputation: 1565Reputation: 1565Reputation: 1565Reputation: 1565Reputation: 1565Reputation: 1565Reputation: 1565Reputation: 1565
Quote:
Originally Posted by bassmadrigal View Post
Ideally, if a SlackBuild (or info) is updated without a new version number, the $BUILD should be incremented
When SBo increments BUILD, it's a signal to people that they will probably want to redo an existing package. If an update just fixes a broken DOWNLOAD url, or corrects typos in the README, or maybe adds new optional deps, we don't increment BUILD. It's not a "revision number" for the SlackBuild script: we've got git for that, or the ChangeLog if you prefer.

Furthermore, it's my (controversial) opinion that the user (or the tool) should sometimes override the SlackBuild's default BUILD number in the resulting package's name -- for example, if package B needs a rebuild because it depends on a new version of package A, or because you want to change some options, are you going to use the same build number? And if you increment the package's build, what are you going to do later, if the SlackBuild gets a new BUILD?
 
1 members found this post helpful.
  


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 01:55 PM
[SOLVED] Call for Testers: MATE 1.14 for -Current willysr Slackware 13 05-27-2016 09:08 AM
Updating w3af to version 1.6.49 in SBo, need testers mralk3 Slackware 3 12-12-2015 06:54 PM
Call for Testers: MATE 1.8 willysr Slackware 137 08-06-2014 02:50 AM
ncurses-5.2-28 conflicts with file from package ncurses-5.2-12 tubby Linux - Software 4 06-16-2002 01:00 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 05:33 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