SBo scripts not building on current (read 1st post, pls)

ponce · 12-21-2015, 04:57 PM

Quote:

Originally Posted by GreenFireFly

Hello Ponce,

I notice that in dolphin-emu i have to keep setting the controller device every time i
run it otherwise the controller does not work.

I have no idea, sorry, I don't use dophin-emu.

try reporting the thing in the dolphin-emu forum

https://forums.dolphin-emu.org/Forum-support

ReaperX7 · 12-24-2015, 09:31 PM

I've had to edit several .info files recently after the files were added into the core of Slackware like libvpx, orc, libvdpau, and several others who have duplicates now in Slackware since sbotools parses them, but can not yet account for files in /var/log/packages.

This might warrant looking into since several of the sbo packages now are obsoleted.

ponce · 12-25-2015, 03:13 AM

Hi ReaperX7, I think you are not using our repository at all because the scripts you name had been removed from there since ages, see the branches list (linked also above).

ReaperX7 · 12-25-2015, 04:26 PM

I'm on your repo. However, some of the .info scripts have leftover dependency listings. I found one compiling nvidia-legacy340-driver for example.

ponce · 12-25-2015, 04:33 PM

ah, sorry, now I have understood what you meant.

no, I haven't edited all the info file removing the things added to Slackware from REQUIRES: I plan to do this, as usual, just on SBo's repo before whenever we're going live after the new Slackware is out.

sorry if this confuses some automated tools but, as you hint, it's true also that they should consider what's already in /var/log/packages.

GreenFireFly · 12-30-2015, 11:28 PM

Hello Everyone,

I can't compile conky in slackware current. I get the following error.

checking for Audacious... configure: error: Package requirements (audacious >= 1.4.0 audclient dbus-glib-1 glib-2.0 gobject-2.0) were not met:

No package 'audclient' found

Audacious is installed.

willysr · 12-30-2015, 11:47 PM

please see this commit on ponce's personal repository

GreenFireFly · 12-31-2015, 02:18 AM

Hello Willysr,

Nevermind i thought libaudclient was included with audacious.

ponce · 12-31-2015, 02:32 AM

hi GreenFireFly,

before installing a script from SBo or this unofficial fork for current you should first install the mandatory dependencies listed in the *.info file provided with the script (the "REQUIRES" variable): what Willy was trying to say to you (and that it's written on that commit he linked) is that in this repository we added libaudclient between the mandatory dependencies in the conky.info file as it has been splitted from the audacious version we have in current but conky still tries to use it.
so build libaudclient first: if you are using this repository you should find it avalaible in the libraries directory.

EDIT: I've seen you edited your messages noting that you have understood the point.

jostber · 01-01-2016, 12:12 PM

Several scripts like etm, nts and w3m complains about not finding libpng14, since current is upgraded to libpng16.

55020 · 01-01-2016, 01:36 PM

Hi Jostber,

If (for example) wxPython was built on 14.1, then naturally it will be linked to libpng14. Therefore, you always need to rebuild and reinstall *all* the dependencies after upgrading to -current. In particular, for etm, nts and w3m, you need to rebuild wxPython and imlib2, and maybe also libgnomeprintui, libgnomeprint, libgnomecups, libgnomecanvas.

The whole lot builds ok here.

jostber · 01-01-2016, 01:55 PM

Quote:

Originally Posted by 55020

Hi Jostber,

If (for example) wxPython was built on 14.1, then naturally it will be linked to libpng14. Therefore, you always need to rebuild and reinstall *all* the dependencies after upgrading to -current. In particular, for etm, nts and w3m, you need to rebuild wxPython and imlib2, and maybe also libgnomeprintui, libgnomeprint, libgnomecups, libgnomecanvas.

The whole lot builds ok here.

OK, thanks, I will check that.

ReaperX7 · 01-01-2016, 05:10 PM

Ponce, check the following packages in the SBO tree (files now in the main tree that can be excluded in the .info files) and one has a buildtime error:

vdpauinfo > libvdpau
vdpau-video > libva, libvdpau (also refuses to build)
libvdpau-va-gl > libva, libvdpau

Error from vdpau-video:

Code:

vdpau_decode.c:1400:43: error: invalid use of void expression
                                           obj_context->vdp_bitstream_buffers);
                                           ^
make[2]: *** [vdpau_decode.lo] Error 1
Makefile:424: recipe for target 'vdpau_decode.lo' failed
make[2]: Leaving directory '/tmp/SBo/vdpau-video-0.6.10/src'
make[1]: *** [all] Error 2
Makefile:303: recipe for target 'all' failed
make[1]: Leaving directory '/tmp/SBo/vdpau-video-0.6.10/src'
Makefile:310: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

I'll post more as I find them.

rworkman · 01-01-2016, 05:34 PM

I don't know for sure, but I suspect that those are intentionally left as-is for now, because otherwise every version bump in the main SBo git tree would cause merge conflicts with the -current branch maintained by ponce. In other words, it would create a *lot* of extra work for very little gain right now.

55020 · 01-01-2016, 06:14 PM

Exactly, thanks Robby. I tried maintaining a private git branch to do the .info cleanups some months ago, but the constant rebase conflicts really are intolerable. Furthermore, there are some really complex renames to be done (e.g. Slackware's new fltk is the same as SBo's fltk13, so SBo's fltk is going to need a new name).

ReaperX7, really you had your answer in post #20 above -- your favoured sbotools handles this badly. slackrepo handles this properly 95 percent of the time ("No such dep in the git repo? Hey, if something with the right name is already installed, let's just go ahead and use that instead") and explicitly handles some of the complex package renames. I think sbopkg has some code to handle renames, and a related config file which might be helpful. Perhaps you could send suppy a patch so that sbotools can join the party, although really this is just a temporary situation, so whether such a patch is worthwhile is up to you.

As for vdpau-video, I have known about that for some time thanks. I think the same build failure also exists in 14.1 (in other words it's not specifically a -current problem), and with so many other packages to fix I've prioritised the low hanging fruit on -current. Perhaps you and the maintainer could come up with a solution?