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

55020 · 01-03-2016, 11:03 AM

Wow ReaperX7, it looks like Robby granted your wish -- there is now an official SlackBuilds.org 'current-wip' branch, Robby has worked on it for two days solid with just a couple of short breaks

and one of the first things he did was to tidy up the .info files and READMEs ... it's looking good!

For avoidance of doubt, Robby's announcement on the Slackbuilds-users mailing list said: "This should not be read as an indicator that release is coming Real Soon Now" (you can read the whole message here)

ReaperX7 · 01-03-2016, 06:21 PM

I never implied a wish. However, good practices have the tendency to lead to better results. SBo is no exception.

Drakeo · 01-03-2016, 06:53 PM

Quote:

Originally Posted by ponce

freshplayer from there works fine here.

EDIT: I just checked and it seems freshplayerplugin had a new release yesterday: I'll have a look and if it's ok I'll update it in the repository.

I do not come in here to argue . But when I test something it is on a fresh full install. and then I go read the developers notes and how ppapi changed and thats why 1.3 is broken and why 1.4 is being used. I am glad 1.3 works with your version of flash ok. But read what and why the developers changed ok. Glad it works for you. I think I will stick to what they guy pushing the blob has to say.
Happy.

ReaperX7 · 01-04-2016, 03:09 AM

Don't blame the packager, blame the nutballs at Google who changed how PPAPI works.

Alien Bob · 01-04-2016, 10:15 AM

Quote:

Originally Posted by ReaperX7

Don't blame the packager, blame the nutballs at Google who changed how PPAPI works.

Nutballs?
Please explain yourself.
Software APIs change all the time, and a program which creates a shim between two incompatible APIs needs to adapt to that. No more than this API change is what happened, and I fail to see how Google is to blame for it.

ReaperX7 · 01-04-2016, 09:28 PM

Quote:

Originally Posted by Alien Bob

Nutballs?
Please explain yourself.
Software APIs change all the time, and a program which creates a shim between two incompatible APIs needs to adapt to that. No more than this API change is what happened, and I fail to see how Google is to blame for it.

I'll put it in terms even you can understand... "If it ain't broke, don't fix it."

Alien Bob · 01-05-2016, 02:29 AM

Quote:

Originally Posted by ReaperX7

I'll put it in terms even you can understand... "If it ain't broke, don't fix it."

Thanks that you agreed to come down to my kindergarten spot but anyway. I call bullshit.

This is not about fixing things, because nothing was broken.
This is about software development and the natural progression in API/ABI scope. Ever wondered why Pat sometimes recompiles packages with a "Shared library .so-version bump" message? That is because ABI's change. It has nothing to do with nutballs or "If it ain't broke, don't fix it", but has everything to do with adding new functionality.

vaenby · 01-05-2016, 02:38 AM

Hello everyone. I tried installing virtualbox-kernel using ponce's slackbuild and it failed.

Quote:

*** Building 'vboxpci' module ***
make[1]: Entering directory '/tmp/SBo/virtualbox-kernel-4.3.24/vboxpci'
make KBUILD_VERBOSE= SUBDIRS=/tmp/SBo/virtualbox-kernel-4.3.24/vboxpci SRCROOT=/tmp/SBo/virtualbox-kernel-4.3.24/vboxpci CONFIG_MODULE_SIG= -C /lib/modules/4.1.15/build modules
make[2]: Entering directory '/usr/src/linux-4.1.15'
CC [M] /tmp/SBo/virtualbox-kernel-4.3.24/vboxpci/linux/VBoxPci-linux.o
/tmp/SBo/virtualbox-kernel-4.3.24/vboxpci/linux/VBoxPci-linux.c: In function 'vboxPciOsDevRegisterIrqHandler':
/tmp/SBo/virtualbox-kernel-4.3.24/vboxpci/linux/VBoxPci-linux.c:889:22: error: 'IRQF_DISABLED' undeclared (first use in this function)
IRQF_DISABLED, /* keep irqs disabled when calling the action handler */
^
/tmp/SBo/virtualbox-kernel-4.3.24/vboxpci/linux/VBoxPci-linux.c:889:22: note: each undeclared identifier is reported only once for each function it appears in
scripts/Makefile.build:258: recipe for target '/tmp/SBo/virtualbox-kernel-4.3.24/vboxpci/linux/VBoxPci-linux.o' failed
make[3]: *** [/tmp/SBo/virtualbox-kernel-4.3.24/vboxpci/linux/VBoxPci-linux.o] Error 1
Makefile:1384: recipe for target '_module_/tmp/SBo/virtualbox-kernel-4.3.24/vboxpci' failed
make[2]: *** [_module_/tmp/SBo/virtualbox-kernel-4.3.24/vboxpci] Error 2
make[2]: Leaving directory '/usr/src/linux-4.1.15'
Makefile:204: recipe for target 'vboxpci' failed
make[1]: *** [vboxpci] Error 2
make[1]: Leaving directory '/tmp/SBo/virtualbox-kernel-4.3.24/vboxpci'
cp: cannot stat 'vboxpci/vboxpci.ko': No such file or directory

install: cannot stat 'vboxpci.ko': No such file or directory

Any idea how to fix it? Thanks.

ponce · 01-05-2016, 03:01 AM

Hi vaenby, we haven't touched the virtualbox-* scripts from what's in SBo.
BTW, this seems fixed in newer virtualbox versions: you can try pinging the SlackBuild's maintainer in the eventuality that maybe he got a new set of build scripts for you to test.

vaenby · 01-05-2016, 03:21 AM

Quote:

Originally Posted by ponce

Hi vaenby, we haven't touched the virtualbox-* scripts from what's in SBo.
BTW, this seems fixed in newer virtualbox versions: you can try pinging the SlackBuild's maintainer in the eventuality that maybe he got a new set of build scripts for you to test.

Hi ponce. I successfully build virtualbox-kernel by applying the patch in that link. Thanks.

sycamorex · 01-15-2016, 05:59 PM

Thanks a lot. I have been waiting with adapting my Slackbuild to 14.2 until it's out but you've already done it

Drakeo · 01-21-2016, 12:37 PM

I have to say this just because it builds like the maintainer wants. and it even get into the main stream. The problem is breakage and that leads us to what the others distro's do. Some way to keep this so when you up grade to your git it it doesn't ruin 2 years of development in slackware 14.1 when using slackware 14.1. That's what I have to say that program I use for work and on my helpers systems. And because a maintainer says oh I want it to build on my computer in 14.1 lets break 2 years of development because. we need to run everything in /usr/lib or usr/lib64.
This is my rant till we and I mean me as trying to help. from my point of viewe slackbuilds is pretty broken for slackware 14.1.
Now Ponce before you freak out. I understand there is no way you can test it all. but some things a blind man can see.
so when you click commit remember all my work on qt went to !@#$^& and 2 years down the drain and the loss of way to much time.
never ever depend on Slackbuilds again.

Mon Nov 4 17:08:47 UTC 2013
Slackware 14.1 x86_64 stable is released!
that is what we build against except for security patches.
Sat Oct 31 01:34:24 UTC 2015
audio/qjackctl: Updated for version 0.4.1.
requires qt5
you do not use slackware I guess to work on qt projects.
but I bet it worked on your maintainer computer right it built.
tell you what I run Eric plasma 5 and am working on so many problems with running the qt4 and the new frameworks. It's not like qt3 where it was pulled into the project. Nothing like that.
I guess I will ask Pat to change how ld.so.conf works in slackware. and have it point to per program.
lets work on 14.1 because 14.2 is going to have the same proble.
How about a read me from the maintainer that says this install in usr/lib and when a qt program your working on calls for a qtlib with ldconf.It may break slackware.

Alien Bob · 01-21-2016, 02:29 PM

Drakeo, your point made zero sense to me.

ethoms · 01-27-2016, 08:19 PM

As a maintainer of a small handful of SB's I will wait until the first RC and then test mine out from the github (current) version. Mine are mostly leaf-node (or close to) SB's.

I have no doubt that those involved in this tricky operation know exactly what they are doing. But I do wonder why we couldn't just fork the 14.1 SlackBuilds and continue adding and refining the 14.1 SlackBuilds. After all, many systems will run 14.1 for a while to come yet. Then perhaps a big notice on the submit page encouraging maintainers to test against the github fork (current -> 14.2) in preparation for the release.

It begs the question; should we allow the upload form to take SB's from the current release and the last release (leap frogging). This gives users of the previous Slackware version more time whilst fully supported before they move to next release. However, it means more work for the maintainers, if they choose to maintain the previous release with up-to-date SB's. Once the transitional period is entered, as it has done recently, the previous release (in this case 14.0) would freeze. The current release (in this case 14.1) would continue to accept uploads. And the next release, (in this case 14.2) would start accepting uploads to improve on, and/or fix the SB's that were forked from the current release (14.1) at the start of the transistional period. I do realize that referring to "current release" is confusing when we use "current" to mean "next release in development".

I've just realised that this release cadence is almost unique within Linux to Slackware. I can't think of any other distro that has stable releases, yet has a rolling repository atop. Perhaps one of the (many) OpenSUSE genomes has similar dynamics. FreeBSD ports stay rolling throughout the various releases. They do a remarkably good job of that too. In ports there is no focus on a base release version at all, it just rolls constantly. I wonder how they pull that of. The continual build testing by Poudriere server farms must help a lot. I suppose having dependency resolution helps also. Their libc ABI compatability is good, it never breaks within major versions. But that shouldn't be an issue for Slackware, since all SB's build on top of fixed release (ABI). And since the Slackware base is large, and since all SB's build from source, only the API compatability between the various SB's should be an issue. As must be the case with ports.

In any case; having packaged for Debian, Slackware and FreeBSD, Slackware is by far the easiest and most joy to package for. I think a big part of that is the relaxed approach, giving freedom and lack of restraints to the packager. Keeping it simple where it needs to be. The other big reason is that we only target two architectures (i486 and x86_64) and one release. Which contradicts my suggestion above. Just thinking out loud :-). I also think the way we submit, review and push new and updated SB's is really nice. My only complaint would be that the time taken for the approved queue to get synced to the production repo is a bit too long (infrequent). If they are approved, what's the hold up.

brobr · 01-30-2016, 03:28 PM

Hi, after getting the recent 'bluez/pulse'-upgrade installed I needed to recompile packages like inkscape (which went ok) but pypoppler-0.12.1 (needed for pdfshuffler) did not compile. It threw this error:

Code:

&& /usr/bin/python /usr/share/pygobject/2.0/codegen/codegen.py \
	--override poppler.override \
	--register /usr/share/pygtk/2.0/defs/gdk-types.defs \
	--register /usr/share/pygtk/2.0/defs/pango-types.defs \
	--register /usr/share/pygtk/2.0/defs/gtk-types.defs \
	--prefix py_poppler poppler.defs) > gen-poppler.c \
	&& cp gen-poppler.c poppler.c \
	&& rm -f gen-poppler.c
Warning: of-object argument unsupported
(define-function poppler_page_add_annot
  (c-name "poppler_page_add_annot")
  (return-type "none")
  (parameters
    '("PopplerAnnot*" "annot")
    '("GList*" "list")
  )
)

Could not write method PopplerAnnotMarkup.get_date: No ArgType for GDate*
Could not write method PopplerPage.get_text_layout: No ArgType for PopplerRectangle**
Could not write method PopplerAttachment.save_to_callback: No ArgType for PopplerAttachmentSaveFunc
Warning: generating old-style constructor for:poppler_font_info_new
Could not write function date_parse: No ArgType for time_t*
Could not write function error_quark: No ArgType for GQuark
Could not write function poppler_page_add_annot: No ArgType for GList*
Warning: Constructor for PopplerFontInfo needs to be updated to new API
         See http://live.gnome.org/PyGTK_2fWhatsNew28#update-constructors
***INFO*** The coverage of global functions is 57.14 (4/7)
***INFO*** The coverage of methods is 97.17 (103/106)
***INFO*** There are no declared virtual proxies.
***INFO*** There are no declared virtual accessors.
***INFO*** There are no declared interface proxies.
/bin/sh ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I/usr/include/python2.7   -pthread -I/usr/include/pygtk-2.0 -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/poppler/glib -I/usr/include/poppler -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libdrm -I/usr/include/libpng16  -I/usr/include/pycairo -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libdrm -I/usr/include/libpng16   -O2 -fPIC -Wall -std=c9x -fno-strict-aliasing -MT poppler_la-poppler.lo -MD -MP -MF .deps/poppler_la-poppler.Tpo -c -o poppler_la-poppler.lo `test -f 'poppler.c' || echo './'`poppler.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I/usr/include/python2.7 -pthread -I/usr/include/pygtk-2.0 -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/poppler/glib -I/usr/include/poppler -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libdrm -I/usr/include/libpng16 -I/usr/include/pycairo -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libdrm -I/usr/include/libpng16 -O2 -fPIC -Wall -std=c9x -fno-strict-aliasing -MT poppler_la-poppler.lo -MD -MP -MF .deps/poppler_la-poppler.Tpo -c poppler.c  -fPIC -DPIC -o .libs/poppler_la-poppler.o
poppler.c: In function 'py_poppler_add_constants':
poppler.c:4613:53: error: 'POPPLER_TYPE_ORIENTATION' undeclared (first use in this function)
   pyg_enum_add(module, "Orientation", strip_prefix, POPPLER_TYPE_ORIENTATION);
                                                     ^
poppler.c:4613:53: note: each undeclared identifier is reported only once for each function it appears in
Makefile:553: recipe for target 'poppler_la-poppler.lo' failed
make[2]: *** [poppler_la-poppler.lo] Error 1
make[2]: Leaving directory '/home/sbo_64/tmp/sbopkg.8bCeDE/pypoppler-0.12.1'
Makefile:575: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/sbo_64/tmp/sbopkg.8bCeDE/pypoppler-0.12.1'
Makefile:424: recipe for target 'all' failed
make: *** [all] Error 2
Cleaning up...

Does anyone have a suggestion how to solve this?

Cheers,

Rob