src2pkg-2.7 - create packages from any source code

Miscellaneous tools
Message
Author
amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#16 Post by amigo »

"enable non-experts" -first you can always install a conf file with whatever options you like for your users. I think non-experts are gonna be just as intimidated by being prompted *every* time to input something, when many times nothing is needed at all. When something *is* needed, the only way they are gonna know what to input is by asking for advice. In that case, it's just as easy to tell them how to use -e='--option1=1 --option2=2'
You can improve the chances of getting closer to perfect by using '-ACN'. What that does is look for a configurable list of options which are used nearly everywhere -like --mandir, --infodir and others. You can configure the list in the conf file -look for 'AUTO_CONFIG_OPTIONS' in the conf file and note that the list uses the option names without the '--' pre-prended -space-separated list of anything you like. The most useful ones are: mandir infodir sysconfdir localstatedir

Actually, I think "primary use case for src2pkg on puppy" should be for use by developers and contributors who want to create things that just work. Once a recipe is created, it can be used on any version or architecture so you avoid the mess of having to always painfully produce binary-packages which work on each version. I know you don't want to need recipes, but there is not a single 'real' distro which can do without them in some form or other. Even LFS uses script fragments recorded in a 'book' to produce the end result.
If normal non-hacking users are able to create even one workable package using src2pkg, then it has been a great help to them. at the very least it avoids creating any extremely damaging packages or damaging builds -even if they don't get a perfect package.

"all .a and .la files the the DEV package" This might actually explain some of the subtle breakages which are numerous. I'll grant you that the *.la files are almost never needed -but there are a few outstanding cases wher it is not true unless special care is taken further both up and down the dependency chain -libpng, libmng and libjpeg being the worst offenders. As I said, there may be packages which use static-file plugins and most packages with plugins do need the *.la files for *.so plugins since some are loaded by using ltdl from libtool. The next time I start a complete-system upgrade, I might try removing all *.la files the whole way through and see how far I get. In the meantime, I'll look at showing you how to get them all removed from the binary, but not the devel package. In the end, they are tiny compared to the real libs so they don't cost much. Remember, I have to offer defaults which work more times than they fail. Exceptions are a great case for a script.

Please continue the feedback of every sort.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#17 Post by amigo »

Okay Jemimah, here's your fix:

plugins-and-la-files-fix.diff:

Code: Select all

--- ./14A-last_minute_details.00	2012-02-16 21:52:23.000000000 +0000
+++ ./14A-last_minute_details	2012-02-16 21:52:41.000000000 +0000
@@ -662,7 +662,11 @@
 							THIS_DIR="$(dirname $FILE)"
 							mkdir -p "$PKG_BUILDS_DIR"/$DEVEL_PKG_NAME/$THIS_DIR
 							# copy, not move the *.la files, as they may be needed in the main package
-							cp -a "$PKG_DIR"/$FILE "$PKG_BUILDS_DIR"/$DEVEL_PKG_NAME/$THIS_DIR
+							if [[ $MOVE_LIBTOOL_FILES = "YES" ]] ; then
+								mv "$PKG_DIR"/$FILE "$PKG_BUILDS_DIR"/$DEVEL_PKG_NAME/$THIS_DIR
+							else
+								cp -a "$PKG_DIR"/$FILE "$PKG_BUILDS_DIR"/$DEVEL_PKG_NAME/$THIS_DIR
+							fi
 						done < "$SRC_DIR"/$NAME-libtool-files
 					fi
 					if [[ -s "$SRC_DIR"/$NAME-static-libs ]] ; then
--- ./09-fix_pkg_perms.00	2012-02-16 21:53:00.000000000 +0000
+++ ./09-fix_pkg_perms	2012-02-16 21:53:15.000000000 +0000
@@ -98,7 +98,7 @@
 	# this also lets us avoid using file so  much
 	find * -type f |while read FILE ; do
 	  case "$FILE" in
-		*/plugins/*|*/plugin/*) true ;; # no dependable way to check for any other plugins
+		# */plugins/*|*/plugin/*) true ;; # no dependable way to check for any other plugins
 		*.la) echo "$FILE" >> $SRC_DIR/$NAME-libtool-files ;;
 		# *.h|*.hh|*.inc) echo "$FILE" >> "$SRC_DIR"/$NAME-header-files ;;
 		# some packages like 'kbd' include *.inc files which are not header files
You'll need to copy that to /usr/libexec/src2pkg, cd in there and run:
patch -p1 < plugins-and-la-files-fix.diff
(or apply the changes manually).
Then, you also need to add this to the bottom of your conf file:

Code: Select all

# MOVE_LIBTOOL_FILES
# If you want to preserve libtool *.la files, but not have copies
# left in a split binary package, then uncomment this
[[ $MOVE_LIBTOOL_FILES ]] || MOVE_LIBTOOL_FILES="YES"
Pretty simple fix, but may need more complex handling if it causes any problems. From the ChangeLog:
Version-2.8 16 February 2012
- (14-last_minute_details) In segregate_sub_pkg_links, Fix an incorrect
path when checking validity of links before moving/copying link to devel package.
- (09-fix_pkg_perms) Stop ignoring files under plugin/plugins directories. libtool
files there were not being listed, so they were not getting chmod 644'ed correctly.
Plus, any static libs there were also being skipped when later splitting packages.
- (14-last_minute_details) Add an option to allow *moving* libtool *.la files into
the devel package instead of leaving copies of them in the main package. This change
and the above one, come from a discussion with Jemimah about plugins and the
possible necessity of *.la files in run-time packages. I'm still not convinced that
*.la files are never needed for loading *.so plugins -or even for some regular
*.so libraries. This option allows *all* *.la files to be moved out of the main package,
so should tell us, with time, whether there really are cases where the *.la files
should sometimes accompany *.so objects. If so, then we need a still-more
complex routine based on real-life cases to figure that out.
I'm posting the quick-fix for you here because src2pkg-2.8 will probably not be out for quite awhile -I only rush out a re-release for bonafide urgent bugs. Most of my users will never see these problems because they don't use package-splitting, so I am glad that we talked about it and, hopefully, found a solution for the problem.

majorfoo
Posts: 448
Joined: Mon 07 Mar 2011, 22:27
Location: Wish I knew

#18 Post by majorfoo »

Made changes to line 135 and tried again.
Compiled Xscreensaver-515.tar.gz. Installed the pet and most of the screensavers (approx 185 out of 200) work .

Tried again using abiword-2.9.2.tar.gz and received the following errors.

I am quite new at this and need to understand what I need to get a completed product
Attachments
src2pkg errors.png
(177.64 KiB) Downloaded 938 times

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#19 Post by amigo »

I can't see enough of the error utput there to be able to tell what happened. Re-run the same command but add '-VV' to the options. Then you should be able to scroll back up to see more error output. This happened not because of some fault of src2pkg, but because something essential (to abiword) is not installed on your system. You may need to look at the log file mentioned in the output -it will be in the toplevel of where the sources have been un-package and are being configured. Sometimes this type of error can be overcome by adding configure arguments which disable the need for the thing it is not finding.

If I get time later, I'll try compiling abiword here so I can more easily help you. If/when I succeed, then I'll pass the 'recipe' to you, if one is needed.

2byte
Posts: 353
Joined: Mon 09 Oct 2006, 18:10

#20 Post by 2byte »

amigo

I just used src2pkg to package and install the xz utilities. For a test, I did a plain configure (no args) /make/install and tried to use it. That was a big fail as some of the libraries were not in the right place. Then I did a clean build with a backup pupsave using src2pkg and installed the pet. Everything works perfectly. It was very impressive when the pet install created all of the needed symlinks without any input from me. I was also pleased to find copies of the pinstall.sh and xz.desc in the /usr/doc dir after installation. Nice touch.

One thing that would be good for us would be a means to specify a short text for the package description at build time. My package has 'No summary text for xz’ in the pet.specs. I looked for a way to do this and also looked in the generated xz.src2pkg.auto file but couldn’t find anything.

EDIT: Found it. /etc/src2pkg/src2pkg.conf, QUERY_FOR_PKG_DESC=YES

EDIT2: No, that only shows up in the *.desc file, not in pet.specs.


amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#21 Post by amigo »

I'll try to have a look in the next couple of days to see about getting QUERY_FOR_PKG_DESC results in the specs file. It would be great if someone put together an extension which would run an interactive routine just before creating the specs file -actually a few scraps of BK's routine for doing this would work fine -I don't remember where that is now -somewhere in dir2pet I guess.

Anyway, I would hope that someone here would come up with a simple extension which solves the incomplete specs problem. After all Puppy is you guys' *thing*. It only makes sense to have src2pkg make the most of what you have to work with.

You want magic? You have to see what src2pkg does when creating *.tpkg packages -lots of juicy package meta-data. Even dependencies for shell scripts get listed -actually they gets listed as 'suggests' since they are not hard dependencies. Here's an example from the free-standing utility for listing them:

Code: Select all

 bash-3.1$ tpkg-script-reqs /usr/bin/wmaker.inst
coreutils
sed
Want to see the list of commands themselves instead of the packages they are part of?

Code: Select all

bash-3.1$ tpkg-script-reqs-raw /usr/bin/wmaker.inst
cat
chmod
cp
mkdir
mv
rm
sed
Sometime over the next couple of days I'm gonna post some examples here of all the possible info provided by my dependency system. It's really insane... no wait, that's not the right word.

Glad you were rewarded with a nice, working package. src2pkg knows *lots* of tricks for making things compile when a plain old './configure && make && make DESTDIR=somewhere install' does not work. And that's just the first third of what it takes to make a good package.

User avatar
Tman
Posts: 808
Joined: Sat 22 Jan 2011, 21:39
Location: Toronto

#22 Post by Tman »

I installed src2pkg-2.7 according the instructions on the first post, but when I tried your example I got the following error. Please note that I am a noob compiler. I have both the devx and the kernel sources loaded. Second pic uses the -VV option. Any suggestions?
Attachments
src2pkg-error.jpg
(72.21 KiB) Downloaded 810 times
src2pkg-error2.jpg
(69.87 KiB) Downloaded 788 times

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#23 Post by jemimah »

amigo wrote:I'll try to have a look in the next couple of days to see about getting QUERY_FOR_PKG_DESC results in the specs file. It would be great if someone put together an extension which would run an interactive routine just before creating the specs file -actually a few scraps of BK's routine for doing this would work fine -I don't remember where that is now -somewhere in dir2pet I guess.

Anyway, I would hope that someone here would come up with a simple extension which solves the incomplete specs problem. After all Puppy is you guys' *thing*. It only makes sense to have src2pkg make the most of what you have to work with.
This is on my todo list actually. Need a couple of weeks before I get to it though.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#24 Post by sunburnt »

I`m interested in using source Debian packages and media packages.
Debian seems to have the most complete repository and best organized.

I made a Debian downloader, one GtkDialog gui and a BaCon exec. gui also.
Making it handle dependencies was the stumbling point I couldn`t get past.
It shows package groups and the group`s package list, and the package info.

It would be nice to hook it up with src2pkg for a complete build utility.
Source to .pet, .sfs, .sq4 packages.
Attachments
DebianPackageTool_SmallSize.png
(30.89 KiB) Downloaded 773 times

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#25 Post by amigo »

Tman, thanks for reporting that. Looks like the sources need to be patched to fix that. I've been meaning to fix the docs to use another example anyway, because 'di' doesn't really show off the usage of src2pkg with the most normal sources -those that use autoconf (the normal './configure && make && make install' routine)

Please try any other example of a small program which compiles quickly and installs just a few files. You could look around the other sections of my site for any number of examples. Or, simply go ahead and build and package whatever you were thinking about building -I'm guessing that had an idea to package some specific software.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#26 Post by amigo »

jemimah, it would be great if you write such an extension. Since you are running a puppy-derived distro every day it will be easier. You can find an example extension (for vector linux) here:
http://distro.ibiblio.org/amigolinux/do ... xtensions/

Or just create the directory ~/.src2pkg/extensions and place a file in ther named 01-16.post or 01-16.pre with anything simple like an 'echo hello from $FUNCNAME'. the run a small build with src2pkg to see that you are seeing that message.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#27 Post by amigo »

sunburnt, I often use debian sources -particularly for the patches they might include. Actually the main 'debianize' patch is useful of itself because they contain the official debian files with a description of the package, the license, etc. By using the src2pkg '-A' option, it will read this info from those files and automatically generate a nicel-formatted description file yor your package. Afterwards, you can throw the the original debianize patch away. Before you do though, have a look and see if it contains anything useful for your package. You can even have src2pkg pick up the configure options used in the debian/rules file for your build by using the '-ACF' option. Also, you can do the same with rpm sources (usually *.src.rpm). src2pkg can do the same as above with '-A' and '-ACF' to pull useful info from the *.spec file. Very, very handy -I hate manually writing description files.

You can use the 'extensions' feature I mentioned above to do thsoe things like creating sfs's etc from the results of the package build. I'm soon gonna include an extension for just that -big_bass is itching for such a thing and worked on it some already. It really is very simple to do so that it works for every package you create. However, if you plan on building sfs's which contain content from more than one build, you will be better off using an independent script. Still there, the best thing to do is simply unpack already-created packages into the area where you want to create the sfs, then do whatever else you need to there -you should run the install script after installng each package, though, so everything gets properly created -links and stuff.

BTW, you can also use a single build to create more than one type of package. After finishing the initial build (a pet, for example), run something like this:
src2pkg (original options) --resume=fake_install -TXZ
and you should get a slackware *.txz package or whichever type you have specified: -TXZ, -PET1, -PET2, -DEB, -RPM, -TAZ or -TPKG

Read about and experiment with the 'extensions' feature and you'll save lots of work when wanting to carry out extra operations at any point during the build. It's designed especially for just the sort of thing you are thinking of.

User avatar
Tman
Posts: 808
Joined: Sat 22 Jan 2011, 21:39
Location: Toronto

#28 Post by Tman »

Thanks for replying, amigo.
I tried compiling Jwm just because it doesn't really need any dependencies or patches and src2pkg worked. Great stuff, thank you.
amigo wrote:It would be great if someone put together an extension which would run an interactive routine just before creating the specs file -actually a few scraps of BK's routine for doing this would work fine -I don't remember where that is now -somewhere in dir2pet I guess.

Anyway, I would hope that someone here would come up with a simple extension which solves the incomplete specs problem. After all Puppy is you guys' *thing*. It only makes sense to have src2pkg make the most of what you have to work with.
if you're talking about the routine in the pic below, that would be in usr/bin/petspec
Attachments
petspec.jpg
(58.69 KiB) Downloaded 762 times

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#29 Post by amigo »

Can you post the full content of the petspec file? Be sure to use the 'code' tags in the posting.

User avatar
Tman
Posts: 808
Joined: Sat 22 Jan 2011, 21:39
Location: Toronto

#30 Post by Tman »

here you go, amigo.

Code: Select all


#!/bin/sh
#optional params passed in:
#"${NAMEONLY}" "${PUPCATEGORY}" "${PUPOFFICIALDEPS}" "${PUPMENUDESCR}" "$BASEPKG" "$SIZEK" "$PUPPATH" "$ARCHDEPENDENT" "$DEFREPO"
#w476 bug fixes, to work properly with dir2pet.
#w482 set default name of repo to 'official'.
#v425 category does not necessarily have anything to do with menu.
#100201 added PUPPATH, ARCHDEPENDENT, DEFREPO, improve setting of distro name & version.
#100303 small bugfix.
#100320 prevent crash if $5 only has name, no version number.
#100508 bugfix empty field.

#old ex: "abiword-2.6.3" "abiword 2.6.3: wordprocessor" ONOFF "Document +fribidi,+gtk+,+goffice,+wv,+enchant 7556K" 
#new: pkgname|nameonly|version|pkgrelease|category|size|path|fullfilename|dependencies|description|
#ex: abiword-1.2.4|abiword|1.2.4|5|Document|999K|slackware/ab|abiword-1.2.4-5-i486.tgz|+aiksausus,+gtk2|a nice wordprocessor|
#optionally on the end: compileddistro|compiledrelease|repo| (fields 11,12,13)
#ex: slackware|12.2|official|
#this is not normally needed, as the name of the file holding the database info, for ex
#'Packages-slackware-12.2-official' identifies this extra information.

. /etc/DISTRO_SPECS
. /root/.packages/DISTRO_PKGS_SPECS
. /root/.packages/DISTRO_PET_REPOS

mkdir -p /var/local/petspec #100201

DEF_nameonly="abiword"
DEF_version="1.2.3-1"
DEF_category="BuildingBlock"
DEF_size_val="UNKNOWN"
#DEF_path="pet_packages-4"
DEF_fullfilename="abiword-1.2.3-1.pet"
DEF_dependencies="+aiksaurus,+gtk2"
DEF_description="A powerful wordprocessor"
DEF_compileddistro="$DISTRO_BINARY_COMPAT"
DEF_compiledrelease="$DISTRO_COMPAT_VERSION"
#DEF_repo="official"
DEF_kernel="`uname -r`"
DEF_pkgname="${DEF_nameonly}-${DEF_version}"


if [ $5 ];then
 DEF_nameonly="$1"
 [ "$2" != "EMPTY" ] && DEF_category="$2"
 [ "$3" != "EMPTY" ] && DEF_dependencies="$3"
 [ "$3" = "EMPTY" ] && DEF_dependencies=""
 [ "$4" != "EMPTY" ] && DEF_description="$4"
 [ "$4" = "EMPTY" ] && DEF_description="no description provided"
 DEF_pkgname="$5"
 xPATTERN="s%${DEF_nameonly}%%"
 DEF_version="`echo -n "$DEF_pkgname" | sed -e "$xPATTERN" -e 's%^\\-%%'`"
 [ "$DEF_version" = "" ] && DEF_version="UNKNOWN" #100320
 [ $5 ] && DEF_size_val="$6"
 DEF_fullfilename="${5}.pet"
fi

#100201 subdirectory of package on repo...
DEF_path=""
[ ! $7 ] && [ -f /var/local/petspec/DEF_path ] && DEF_path="`cat /var/local/petspec/DEF_path`"
[ $7 ] && [ "$7" != "EMPTY" ] && DEF_path="${7}"

#100201 determine if pkg is only scripts...
ARCHDEPENDENT='yes'
[ $8 ] && ARCHDEPENDENT="${8}"
if [ "$ARCHDEPENDENT" != "yes" -a "$ARCHDEPENDENT" != "no" ];then
 DEF_compileddistro="`echo -n "$ARCHDEPENDENT" | cut -f 1 -d '|'`"
 DEF_compiledrelease="`echo -n "$ARCHDEPENDENT" | cut -f 2 -d '|'`"
fi
if [ "$ARCHDEPENDENT" = "no" ];then
 DEF_compileddistro="DISTRO INDEPENDENT"
 DEF_compiledrelease="DISTRO INDEPENDENT"
fi
[ "$DEF_compiledrelease" = "" ] && DEF_compiledrelease="$DISTRO_COMPAT_VERSION" #100508

#100201 id of repository...
DEF_repo=""
[ ! $9 ] && [ -f /var/local/petspec/DEF_repo ] && DEF_repo="`cat /var/local/petspec/DEF_repo`"
[ $9 ] && [ "$9" != "EMPTY" ] && DEF_repo="${9}"

#sort category items...
ITEMSCAT="<item>${DEF_category}</item>"
for ONECAT in 'NO CATEGORY' Desktop System Setup Utility Filesystem Graphic Document Calculate Personal Network Internet Multimedia Fun Help BuildingBlock Develop
do
 [ "$ONECAT" = "$DEF_category" ] && continue
 ITEMSCAT="${ITEMSCAT}<item>${ONECAT}</item>"
done

#sort compileddistro items...
ITEMSCOMP="<item>${DEF_compileddistro}</item>"
for ONECHOICE in 'DISTRO INDEPENDENT' arch debian puppy slackware t2 ubuntu
do
 [ "$ONECHOICE" = "${DEF_compileddistro}" ] && continue
 ITEMSCOMP="${ITEMSCOMP}<item>${ONECHOICE}</item>"
done

DEPENDENCIES=""
if [ "$DEF_dependencies" != "" ];then
 DEPENDENCIES="<default>${DEF_dependencies}</default>"
fi

export MAIN_DIALOG="
<window title=\"Package database-entry creator\" icon-name=\"gtk-index\">
 <vbox>
 
  <text use-markup=\"true\"><label>\"<b>The fields marked with '*' are required, the rest fill in as much as possible or if uncertain leave blank.</b>\"</label></text>
  
  <hbox>
   <text><label>\"    \"</label></text><text><label>*Name-only:</label></text>
   <entry>
    <default>${DEF_nameonly}</default><variable>DB_nameonly</variable>
   </entry>
  </hbox>
  <hbox>
   <text><label>\"                  \"</label></text><text><label>*Version:</label></text>
   <entry>
    <default>${DEF_version}</default><variable>DB_version</variable>
   </entry>
  </hbox>

  <hbox>
    <text>
      <label>*Category:</label>
    </text>
	<combobox>
      <variable>DB_category</variable>
	  ${ITEMSCAT}
    </combobox>
  </hbox>
  <hbox>
   <text><label>\"                  \"</label></text><text><label>Size of installed package:</label></text>
   <entry>
    <default>${DEF_size_val}</default><variable>DB_size_val</variable>
   </entry>
   <text><label>KB</label></text>
  </hbox>

  <hbox>
   <text><label>Folder path within repository:</label></text>
   <entry>
    <default>\"${DEF_path}\"</default><variable>DB_path</variable>
   </entry>
  </hbox>
  <hbox>
   <text><label>*Full package name:</label></text>
   <entry>
    <default>${DEF_fullfilename}</default><variable>DB_fullfilename</variable>
   </entry>
  </hbox>
  <hbox>
   <text><label>Dependencies:</label></text>
   <entry>
    ${DEPENDENCIES}<variable>DB_dependencies</variable>
   </entry>
  </hbox>
  <hbox>
   <text><label>Description:</label></text>
   <entry>
    <default>${DEF_description}</default><variable>DB_description</variable>
   </entry>
  </hbox>

  <frame Extra optional>
  <hbox>
    <text>
      <label>Compiled in compatible-distro:</label>
    </text>
	<combobox>
      <variable>DB_compileddistro</variable>
	  ${ITEMSCOMP}
    </combobox>
  </hbox>
  <hbox>
   <text><label>\"    \"</label></text><text><label>Compatible-distro version:</label></text>
   <entry>
    <default>${DEF_compiledrelease}</default><variable>DB_compiledrelease</variable>
   </entry>
  </hbox>
  <hbox>
   <text><label>\"    \"</label></text><text><label>Single unique name of repository:</label></text>
   <entry>
    <default>\"${DEF_repo}\"</default><variable>DB_repo</variable>
   </entry>
  </hbox>
  </frame>

   <hbox>
    <button>
     <label>Help</label>
     <action>defaulthtmlviewer http://puppylinux.com/woof/pkg-db-format.htm & </action>
    </button>
    <button>
     <label>Generate package database entry</label>
     <action type=\"exit\">GENERATE_DB</action>
    </button>
    <button cancel></button>
   </hbox>
 </vbox>
</window>
"

RETVALS="`gtkdialog3 --program=MAIN_DIALOG`"
#ex:
#DB_category="BuildingBlock"
#DB_compileddistro="ubuntu"
#DB_compiledrelease="jaunty"
#DB_dependencies="+aiksaurus,+gtk2"
#DB_description="A powerful wordprocessor"
#DB_fullfilename="abiword-1.2.3-1.pet"
#DB_path="pet_packages-5"
#DB_pkgname="abiword"
#DB_repo="5"
#DB_size_val="UNKNOWN"
#DB_version="1.2.3-1"
#EXIT="GENERATE_DB"

eval "$RETVALS"

[ "$EXIT" != "GENERATE_DB" ] && exit 1

echo -n "$DB_path" > /var/local/petspec/DEF_path #100201
echo -n "$DB_repo" > /var/local/petspec/DEF_repo #100201

DB_size="$DB_size_val"'K'
[ "$DB_size_val" = "UNKNOWN" ] && DB_size=""
[ "$DB_category" = "NO CATEGORY" ] && DB_category=""
[ "$DB_compileddistro" = "DISTRO INDEPENDENT" ] && DB_compileddistro=""
[ "$DB_compiledrelease" = "DISTRO INDEPENDENT" ] && DB_compiledrelease="" #100303
DB_version="`echo -n "$DB_version" | sed -e 's% %%g'`" #100320 precaution, get rid of any spaces.
if [ "$DB_version" = "" -o "$DB_version" = "UNKNOWN" ];then #100320
 DB_pkgname="$DB_nameonly"
 DB_version=""
else
 DB_pkgname="${DB_nameonly}-${DB_version}"
fi

DB_ENTRY="${DB_pkgname}|${DB_nameonly}|${DB_version}|${DB_pkgrelease}|${DB_category}|${DB_size}|${DB_path}|${DB_fullfilename}|${DB_dependencies}|${DB_description}|${DB_compileddistro}|${DB_compiledrelease}|${DB_repo}|"
echo
echo "$DB_ENTRY"
echo "This is the package database entry:

$DB_ENTRY" > /tmp/petspec_db_entry

nohup defaulttextviewer /tmp/petspec_db_entry 2>/dev/null &

exit 0

###END###

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#31 Post by amigo »

Yes, thank you. I'll see about morphing that into a puppy-specific extension for src2pkg and then everyone can be happy with more complete *.specs files.

User avatar
Keef
Posts: 987
Joined: Thu 20 Dec 2007, 22:12
Location: Staffordshire

#32 Post by Keef »

I've just tried to install the pet on Akita (beta 7), but it fails when trying to compile libsentry. Tried running make on libsentry (in the src2pkg-helpers dir), and got the following result:

Code: Select all

# make
cc -Wall -U_FORTIFY_SOURCE -D_GNU_SOURCE -DLIBDIR=\"/usr/local/lib\" -DPIC -fPIC -D_REENTRANT -DVERSION=\"0.7.0\" -c libsentry.c
libsentry.c:3090: error: conflicting types for 'scandir'
/usr/include/dirent.h:254: error: previous declaration of 'scandir' was here
libsentry.c:3743: error: conflicting types for 'scandir64'
/usr/include/dirent.h:275: error: previous declaration of 'scandir64' was here
make: *** [libsentry.o] Error 1

It has worked ok for me on Fire Hydrant Lite 301 RetroV3, and SolidPup (Wary 511).

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#33 Post by amigo »

Ay, Ay, Ay, that old problem -it's a glibc thing, where it is declared differently in different versions.
What version of gcc do you have ( output from running: gcc -dumpversion)?
What version of glibc do you have (output from running: /lib/libc.so.6)?

User avatar
Keef
Posts: 987
Joined: Thu 20 Dec 2007, 22:12
Location: Staffordshire

#34 Post by Keef »

Amigo,

Here are the gory details:

gcc version is 4.2.2

Code: Select all

# /lib/libc.so.6
GNU C Library stable release version 2.10.1, by Roland McGrath et al.
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.3.4.
Compiled on a Linux >>2.6.32.16<< system on 2010-09-13.
Available extensions:
        crypt add-on version 2.1 by Michael Glad and others
        Native POSIX Threads Library by Ulrich Drepper et al
        Support for some architectures added on, not maintained in glibc core.
        BIND-8.2.3-T5B
EDIT I've had a PM from scottman about this, with a possible solution. Will update when I've tried it.

User avatar
Tman
Posts: 808
Joined: Sat 22 Jan 2011, 21:39
Location: Toronto

#35 Post by Tman »

Hi Amigo,

When src2pkg creates a pet from a source on my hard-drive, the pet contains the proper tree structure to files and folders but it contains a secondary tree where all of the files are duplicated inside of a folder named initrd. I was wondering if there is a way to avoid this?
Last edited by Tman on Tue 28 Feb 2012, 17:07, edited 1 time in total.

Post Reply