LinuxQuestions.org
Review your favorite Linux distribution.
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 12-01-2016, 06:28 PM   #46
bassmadrigal
Senior Member
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 4,301

Original Poster
Rep: Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278

Quote:
Originally Posted by 55020 View Post
Yes, that's what the inside of my head calls "version pinning" or "freezing". I must say, thank you for the feedback. My own use is primarily for test building, and I get the SBo packages I use every day as an accidental reward but what you're using it for is primarily to make packages, which is a bit more interesting and important
Sorry for the constant feedback on something you haven't had time to work on. It's gotta be "comforting" to keep getting things added to that already long TODO list

Quote:
Originally Posted by 55020 View Post
I might have the chance to restart work on slackrepo this weekend
Awesome! Don't worry, we won't hold you to any timelines But I will keep an eye on your github to check out the changes.

Quote:
Originally Posted by 55020 View Post
It's still a bit puzzling and worrying why qt5 hates you; congrats on the workround.
I have no idea what's up with qt5. If it helps, this is what Eric's checkpkg script finds in one of the recent build logs (I only have the last two because I cleared a ton space in case it was related to a full harddrive). If you happen to be interested in full, almost 200K line log file, you can grab it http://bassmadrigal.tk/temp/qt5-build.1.log.gz.

Code:
root@slackrepo:/var/log/slackrepo/SBo/libraries/qt5# ~jbhansen/checkpkg -l build.1.log
++ Checking logfile 'build.1.log' (no news is good news):
138240 :db2.cpp:34:20: fatal error: sqlcli.h: No such file or directory
138243 :gmake: *** [db2.o] Error 1
138247 :ibase.cpp:34:19: fatal error: ibase.h: No such file or directory
138250 :gmake: *** [ibase.o] Error 1
138258 :oci.cpp:34:17: fatal error: oci.h: No such file or directory
138261 :gmake: *** [oci.o] Error 1
138266 :/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/../../../../x86_64-slackware-linux/bin/ld: cannot find -lodbc
138267 :collect2: error: ld returned 1 exit status
138269 :gmake: *** [odbc] Error 1
138277 :psql.cpp:34:22: fatal error: libpq-fe.h: No such file or directory
138280 :gmake: *** [psql.o] Error 1
138288 :sqlite2.cpp:34:20: fatal error: sqlite.h: No such file or directory
138291 :gmake: *** [sqlite2.o] Error 1
138295 :tds.cpp:34:22: fatal error: sybfront.h: No such file or directory
138298 :gmake: *** [tds.o] Error 1
138382 :tslib.cpp:34:19: fatal error: tslib.h: No such file or directory
138385 :gmake: *** [tslib.o] Error 1
138393 :libinput.cpp:34:22: fatal error: libinput.h: No such file or directory
138396 :gmake: *** [libinput.o] Error 1
138491 :Project ERROR: mirclient development package not found
138507 :eglfs-brcm.cpp:36:22: fatal error: bcm_host.h: No such file or directory
138510 :gmake: *** [eglfs-brcm.o] Error 1
138515 :/usr/include/xf86drm.h:40:17: fatal error: drm.h: No such file or directory
138518 :gmake: *** [eglfs-egldevice.o] Error 1
138522 :eglfs-mali.cpp:34:30: fatal error: EGL/fbdev_window.h: No such file or directory
138525 :gmake: *** [eglfs-mali.o] Error 1
138530 :eglfs-mali-2.cpp:41:5: error: 'mali_native_window' was not declared in this scope
138533 :eglfs-mali-2.cpp:41:25: error: 'w' was not declared in this scope
138537 :gmake: *** [eglfs-mali-2.o] Error 1
138541 :eglfs-viv.cpp:35:28: fatal error: EGL/eglvivante.h: No such file or directory
138544 :gmake: *** [eglfs-viv.o] Error 1
138631 :openvg.cpp:40:23: fatal error: VG/openvg.h: No such file or directory
138634 :gmake: *** [openvg.o] Error 1
138638 :openvg.cpp:40:23: fatal error: VG/openvg.h: No such file or directory
138641 :gmake: *** [openvg.o] Error 1
138645 :openvg.cpp:38:23: fatal error: vg/openvg.h: No such file or directory
138648 :gmake: *** [openvg.o] Error 1
138652 :openvg.cpp:38:23: fatal error: vg/openvg.h: No such file or directory
138655 :gmake: *** [openvg.o] Error 1
142415 :items/qquickrepeater.cpp:503:1: internal compiler error: Segmentation fault
142422 :make[3]: *** [.obj/qquickrepeater.o] Error 1
142426 :make[2]: *** [sub-quick-make_first-ordered] Error 2
142429 :make[1]: *** [sub-src-make_first] Error 2
142432 :make: *** [module-qtdeclarative-make_first] Error 2
142435 ::-( libraries/qt5 FAILED )-:
Initially, I did have a lot of optional dependencies, but I commented them out of the hintfile. Here's the original I was first trying, but later I commented out all but NUMJOBS. I can try to build it again (and possibly again) over the next week to see if I can get lucky. I may also try moving the VM to my desktop which is only a bit more powerful (but I'm hoping to build a new AMD Zen system within the next few months), but it has loads of RAM (32GB) and tons of HD space.

Code:
root@slackrepo:~# cat /etc/slackrepo/SBo/hintfiles/qt5.hint
ADDREQUIRES="freetds OpenAL libwebp opus snappy postgresql"
OPTIONS="PROPRIETARY_CODECS=yes"
PRAGMA="abstar"
NUMJOBS="-j1"
In the next day or two, I'll probably try and build qt5 with just the SlackBuild just to make sure it isn't related to slackrepo (although, I imagine that's highly unlikely since it's crapping out during compilation).
 
Old 12-01-2016, 08:14 PM   #47
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,114
Blog Entries: 4

Rep: Reputation: 1525Reputation: 1525Reputation: 1525Reputation: 1525Reputation: 1525Reputation: 1525Reputation: 1525Reputation: 1525Reputation: 1525Reputation: 1525Reputation: 1525
Quote:
Originally Posted by bassmadrigal View Post
In the next day or two, I'll probably try and build qt5 with just the SlackBuild just to make sure it isn't related to slackrepo (although, I imagine that's highly unlikely since it's crapping out during compilation).
Well... that's exactly how this crazyness started. I had a small script to help test SlackBuilds for the 14.1 release, but the script didn't work with unusual SlackBuilds. So, whenever there was a failure, the question always needed to be answered: what is broken? the script, or the SlackBuild, or something new in -current? And that is still always the question today, except that I don't use -current at the moment.
 
Old 12-02-2016, 12:16 PM   #48
slalik
Member
 
Registered: Nov 2014
Location: Moscow, Russia
Distribution: Slackware
Posts: 119

Rep: Reputation: 54
Quote:
Originally Posted by bassmadrigal View Post
Quote:
Originally Posted by slalik View Post
As for jdk, the problem could be resolved with a hint that allows to add options to wget/curl.

In srcfunctions.sh there is a case statement that adds an option to curl for dropbox. As a temporary solution, I added another line for oracle:
Code:
*download.oracle.com*) curlboredom="${curlboredom} --cookie oraclelicense=accept-securebackup-cookie" ;;
I thought I was going crazy... I was digging through that file and couldn't find any reference to dropbox. I just assumed the latest package mirrored what was on github. Now I realize that he has made some changes since his 2.0rc1 release, so I'll clone the repo and start using that instead. (With that nifty change added in.)
I don't know if it's obvious that also the hint
Code:
PRAGMA="download_basename"
is needed to ask slackrepo to use curl instead of wget when downloading jdk.
 
1 members found this post helpful.
Old 12-02-2016, 12:27 PM   #49
bassmadrigal
Senior Member
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 4,301

Original Poster
Rep: Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278
Quote:
Originally Posted by slalik View Post
I don't know if it's obvious that also the hint
Code:
PRAGMA="download_basename"
is needed to ask slackrepo to use curl instead of wget when downloading jdk.
It wasn't, but I haven't tried it yet (I already manually downloaded the current version... I would've had to wait until the next version is out and then troubleshoot when it didn't work). Thanks for the heads up. I'll add that to my hint file for jdk
 
Old 12-02-2016, 01:33 PM   #50
montagdude
Member
 
Registered: Apr 2016
Distribution: Slackware
Posts: 647

Rep: Reputation: 488Reputation: 488Reputation: 488Reputation: 488Reputation: 488
Quote:
Originally Posted by bassmadrigal View Post
I'm not too familiar with git (David gave me some quirk and dirty lessons so I now know enough to cause trouble), but if I don't commit and just keep them as a separate branch, can't I update the initial branch without issue? Then, before I go to actually build, I just recheckout the custom branch so it doesn't try to rebuild qt5.
Git doesn't let you check out a different branch if you have uncommitted changes on the working branch. I'm not really sure why; it's a kind of annoying limitation sometimes.
 
1 members found this post helpful.
Old 12-02-2016, 02:24 PM   #51
bassmadrigal
Senior Member
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 4,301

Original Poster
Rep: Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278
Quote:
Originally Posted by montagdude View Post
Git doesn't let you check out a different branch if you have uncommitted changes on the working branch. I'm not really sure why; it's a kind of annoying limitation sometimes.
Good to know. Maybe I'll just create a git diff of all the changes and save it separately. Then when the updates are applied, I can create the new branch (or check it out if it's still created) and apply the patch.
 
Old 12-03-2016, 08:23 AM   #52
slalik
Member
 
Registered: Nov 2014
Location: Moscow, Russia
Distribution: Slackware
Posts: 119

Rep: Reputation: 54
Quote:
Originally Posted by atelszewski View Post
2. When public update comes, I do:
Code:
git checkout 14.2
git pull
git checkout local
git rebase 14.2
slackrepo update
I have no proper understanding of git (slackrepo is my first use of it) so I'm not sure about anything. What I do, I created local branch and I'm always on it, never checkout to/from 14.2. I configured the local branch so that 'git pull' always does rebase:
Code:
git config branch.local.rebase true
When an update happens I simply do 'git pull'.

My setting is different in the sense that I created a separate local repository and point slackrepo to it. In this local repository I have the above local branch.

Unfortunately, 'slackrepo update' doesn't want to work with my local repository directly (my guess is that slackrepo contructed to work with a remote repository), so I do
Code:
cd /var/lib/slackrepo/SBo/slackbuilds
git pull --rebase
slackrepo update
 
Old 12-15-2016, 02:41 PM   #53
atelszewski
Member
 
Registered: Aug 2007
Distribution: Slackware
Posts: 792

Rep: Reputation: Disabled
Hi,

I'm going to dare to say that at its current state, slackrepo is more geared towards end users than at SlackBuilds developers :-^

What I mean is that, it's extremely helpful for those who want to build and keep the packages up to date.
No doubt about that.

But developing SlackBuilds becomes a pain and it boils down to the automatic rebuilds.
I would love to see a possibility of preventing rebuilding of a package and marking it as up to date.

It would be helpful in situation where you, for example:
- update the README,
- update the download URL in the .info,
- and so on.

@David, maybe instead of implementing your own heuristics to detect when a package needs rebuild, it would be better to leave this decision to the user?
Say, you pass --developer option and slackrepo asks some additional questions about what to do?

That would be probably the best approach, since there are many possible changes, that do not need the rebuild.
And it would dramatically lessen the job you need to put in developing of slackrepo.

--
Best regards,
Andrzej Telszewski
 
Old 12-15-2016, 03:11 PM   #54
bassmadrigal
Senior Member
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 4,301

Original Poster
Rep: Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278
Quote:
Originally Posted by atelszewski View Post
Hi,

I'm going to dare to say that at its current state, slackrepo is more geared towards end users than at SlackBuilds developers :-^

What I mean is that, it's extremely helpful for those who want to build and keep the packages up to date.
No doubt about that.

But developing SlackBuilds becomes a pain and it boils down to the automatic rebuilds.
I would love to see a possibility of preventing rebuilding of a package and marking it as up to date.

It would be helpful in situation where you, for example:
- update the README,
- update the download URL in the .info,
- and so on.

@David, maybe instead of implementing your own heuristics to detect when a package needs rebuild, it would be better to leave this decision to the user?
Say, you pass --developer option and slackrepo asks some additional questions about what to do?

That would be probably the best approach, since there are many possible changes, that do not need the rebuild.
And it would dramatically lessen the job you need to put in developing of slackrepo.

--
Best regards,
Andrzej Telszewski
I think this would be the ideal situation to add a IGNORE=yes|no option within the hintfile. This would tell slackpkg to ignore any changes to that slackbuild and use the previously compiled version. This could be useful for both developers and end-users, developers for the reasons you state... any minor change would invoke at least rebuilding that, if not a whole chain of other programs, possibly for a simple change of the README. End-users could use it to sit at a specific version if a newer one adds incompatibilities or for something like qt5. That takes forever and a day to compile on some systems (if it compiles at all), and it would be nice to allow your repo to sit at a specific version... then if you deem an upgrade is worth it, you can remove the IGNORE (or change it to no).

I think for developers it would also be extremely handy to have a /etc/slackrepo/$repo/slackbuilds/ folder that can either override files in the regular repo (kinda like your own hintfiles can override the pre-provided ones -- this could allow you to easily change SlackBuilds if you need to tailor them to your system) or you can add your own SlackBuilds so you can test them with the various packages before submission to SBo. If there's an update for one of those programs pushed to SBo, you could simply tell the user and ask which version they want to use (if you really wanted, you could provide a diff like slackpkg does with .new files... but that's starting to ask for a lot... well, a lot more ).

Just some food for thought
 
Old 12-15-2016, 03:27 PM   #55
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2 on Lenovo Thinkpad W520
Posts: 7,701

Rep: Reputation: 2618Reputation: 2618Reputation: 2618Reputation: 2618Reputation: 2618Reputation: 2618Reputation: 2618Reputation: 2618Reputation: 2618Reputation: 2618Reputation: 2618
My suggestion would be not to upgrade the SlackBuilds @ slackbuilds.org but for a good reason.

good reason={security fix|major bug fix}.

"new upstream version" is generally not a good reason. Exceptions should have a very convincing rationale.

After all that seems to be the policy for the distribution itself.

Food for thought?
 
Old 12-15-2016, 03:38 PM   #56
atelszewski
Member
 
Registered: Aug 2007
Distribution: Slackware
Posts: 792

Rep: Reputation: Disabled
Hi,

Quote:
Originally Posted by Didier Spaier View Post
My suggestion would be not to upgrade the SlackBuilds @ slackbuilds.org but for a good reason.

good reason={security fix|major bug fix}.

"new upstream version" is generally not a good reason. Exceptions should have a very convincing rationale.

After all that seems to be the policy for the distribution itself.

Food for thought?
That's not the topic of this thread.

--
Best regards,
Andrzej Telszewski
 
Old 12-15-2016, 03:42 PM   #57
bassmadrigal
Senior Member
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 4,301

Original Poster
Rep: Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278
Quote:
Originally Posted by Didier Spaier View Post
My suggestion would be not to upgrade the SlackBuilds @ slackbuilds.org but for a good reason.

good reason={security fix|major bug fix}.

"new upstream version" is generally not a good reason. Exceptions should have a very convincing rationale.

After all that seems to be the policy for the distribution itself.

Food for thought?
The question with that though, who makes the decision? Is it the SBo admins who may not be intimately familiar with that program and the benefits/downsides of a newer version but have an overall idea of the ideals of the SBo project? Or should it be the package maintainer who (hopefully) monitors their upstream sources and decides when/if an update is worthy of pushing to SBo, but they may not have the same ideas of what makes an update "worth it"?

It's a tough question and both have their benefits/drawbacks. I don't know if I have an answer for you... But with my SlackBuilds, I tend to not update them unless there's a good reason behind it.
 
Old 12-15-2016, 03:51 PM   #58
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2 on Lenovo Thinkpad W520
Posts: 7,701

Rep: Reputation: 2618Reputation: 2618Reputation: 2618Reputation: 2618Reputation: 2618Reputation: 2618Reputation: 2618Reputation: 2618Reputation: 2618Reputation: 2618Reputation: 2618
Quote:
Originally Posted by bassmadrigal View Post
The question with that though, who makes the decision? Is it the SBo admins who may not be intimately familiar with that program and the benefits/downsides of a newer version but have an overall idea of the ideals of the SBo project? Or should it be the package maintainer who (hopefully) monitors their upstream sources and decides when/if an update is worthy of pushing to SBo, but they may not have the same ideas of what makes an update "worth it"?
Until now, practically the package maintainers make the decision.

My question is "don't we need a more restrictive rule?"

But atelszewski is right, this is not the topic of this thread, furthermore I am just an end user, so forget my suggestion.
 
Old 12-15-2016, 04:11 PM   #59
atelszewski
Member
 
Registered: Aug 2007
Distribution: Slackware
Posts: 792

Rep: Reputation: Disabled
Hi,

Quote:
Originally Posted by Didier Spaier View Post
But atelszewski is right, this is not the topic of this thread, furthermore I am just an end user, so forget my suggestion.
The input from the end user is actually important.
And you know where is the correct place to e-mail it ;-)

--
Best regards,
Andrzej Telszewski
 
Old 12-16-2016, 07:26 PM   #60
bassmadrigal
Senior Member
 
Registered: Nov 2003
Location: Newport News, VA
Distribution: Slackware
Posts: 4,301

Original Poster
Rep: Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278Reputation: 2278
Is OPTIONS in the hintfile ran like normal commands before the SlackBuild? I'm asking because I tried rebuilding gst-plugins-bad after I rebuilt opencv after enabling qt5 in opencv. Once I did, gst-plugins-bad errorred out stating:

Code:
/usr/include/qt5/QtCore/qbasicatomic.h:61:4: error: #error "Qt requires C++11 support"
Based on this stackexchange question, I believe it will be able to be solved by adding "export CXXFLAGS=-std=c++11" to the SlackBuild, but I'd rather not modify it for something so simple as this, so I was thinking maybe I could add it to the hintfile as OPTIONS="CXXFLAGS=-std=c++11", but I found that wouldn't work because the CXXFLAGS variable is overwritten by the $SLKCFLAGS in the SlackBuild.

So, after some digging, I found in the buildfunctions.sh section where the pragmas are specified and I looked at how the others are done and decided to add my own. Unfortunately, I'm not terribly experienced with sed and don't understand the commands that David wrote. So I had to go a bit simpler with my sed command, but after adding it, adjusting the hint file and then rerunning the SlackBuild, the package completed successfully. I'm not sure if this situation happens frequently enough for David to consider adding it to the program permanently, but here's the patch.

Code:
commit d7a5ff3b2def29c32d991be54d6b6bf8fda6bc45
Author: bassmadrigal <jebrhansen+SBo@gmail.com>
Date:   Fri Dec 16 19:51:50 2016 -0500

    Add c++11 override to pragma

diff --git a/libexec/functions.d/buildfunctions.sh b/libexec/functions.d/buildfunctions.sh
index bf54489..7fa5dc9 100755
--- a/libexec/functions.d/buildfunctions.sh
+++ b/libexec/functions.d/buildfunctions.sh
@@ -202,6 +202,11 @@ function build_item_packages
         sed -i -e "s;^\./configure ;LDFLAGS=\"-L/usr/lib$libdirsuffix\" &;" "$MYTMPIN/$itemfile"
       fi
       ;;
+    'c++11' )
+      # Used to force C++11 support (possibly only for QT programs)
+      log_info -a "Pragma: c++11"
+      sed -i 's/CXXFLAGS="$SLKCFLAGS" \\/CXXFLAGS="-std=c++11 $SLKCFLAGS" \\/g' "$MYTMPIN/$itemfile"
+      ;;
     'stubs-32' )
       if [ "$SYS_ARCH" = 'x86_64' ] && [ ! -e /usr/include/gnu/stubs-32.h ]; then
         log_info -a "Pragma: stubs-32"
David, if you're interested, I could figure out how to send you a pull request.

@atelszewski, it looks like the krusader source isn't available anymore. Have you changed your server around or is something broke? Unfortunately, I deleted my previously downloaded source during the qt5 build fiasco thinking it might've been spaced related (it wasn't).

Code:
ERROR: Download failed: Network failure.
  http://mirror.telszewski.net/source/krusader/krusader-git_20150309_13fa966.tar.xz
EDIT: After some more looking through various SlackBuilds (and reteaching myself some advanced sed options), I think the sed should probably be changed to the below. This would help to ensure we don't replace additional CXXFLAGS that were set by the package maintainer.

Code:
sed -i -e 's/^CXXFLAGS="/&-std=c++11 /' "$MYTMPIN/$itemfile"
In looking through, it seems there are other things that could be adjusted within the CXXFLAGS, so I'm not sure if it would be beneficial to add more options for someone to add to the CXXFLAGS. The grep I used to find this is below (run from within the root of the SlackBuilds repo). I don't know enough about CXXFLAGS to know which are important.

Code:
grep '^CXXFLAGS="' */*/*.SlackBuild | fgrep -v 'CXXFLAGS="$SLKCFLAGS"'

Last edited by bassmadrigal; 12-17-2016 at 05:38 PM.
 
  


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] Two questions / wishes related to slackrepo slalik Slackware 3 07-21-2015 05:18 AM
Howto undo updates or roll system back to initial installation? suguru SUSE / openSUSE 2 01-08-2006 11:31 PM
Howto? upgrade kernel on initial boot into Sarge haertig Debian 12 11-12-2005 11:58 PM
Initial questions after first Linux use Foxy Mandriva 11 07-04-2004 03:55 AM
Initial setup .. umd Linux From Scratch 9 04-05-2003 12:36 PM

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

All times are GMT -5. The time now is 11:34 AM.

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