HOWTO: Initial Setup of slackrepo (plus some questions)
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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
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
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.
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).
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.
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.
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
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.
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.
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
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.
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 ).
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.
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.
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:
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).
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
but what you're using it for is primarily to make packages, which is a bit more interesting and important 
