Re: rpm problem
On Fri, Jul 25, 2014 at 6:39 AM, Nico Kadel-Garcia wrote: > On Thu, Jul 24, 2014 at 3:00 PM, ToddAndMargo wrote: >> On 07/23/2014 09:05 AM, Mark Stodola wrote: >>> On 07/23/2014 10:43 AM, ToddAndMargo wrote: I am having trouble installing the PDF Studio RPM. https://www.dropbox.com/s/slgrnolcsktaezz/PDFStudio_v9_0_2_linux.rpm # cat /etc/redhat-release Scientific Linux release 6.5 (Carbon) # uname -r 2.6.32-431.20.3.el6.x86_64 # rpm -ivh PDFStudio_v9_0_2_linux.rpm Preparing... ### [100%] 1:PDFStudio ### [100%] error: unpacking of archive failed on file .pdfstudio9/: cpio: Archive file not in header Any way to fix this? > > By using s cluebat on the package author. It's not a good package. > It's misnamed, it drops everything in a relative directory, and there > is no license. This is not a safe thing to install anywhere. $ find .pdfstudio9 -iname "*license*" .pdfstudio9/lib/barcode4j_license.txt .pdfstudio9/lib/swt/eclipse common public license.txt .pdfstudio9/lib/dj/gnu lesser general public license.txt .pdfstudio9/lib/bc_license.txt .pdfstudio9/lib/miglayout_license.txt .pdfstudio9/lib/js-14_license.txt .pdfstudio9/jre/LICENSE .pdfstudio9/jre/THIRDPARTYLICENSEREADME.txt I wonder which one, if any, the rpm author thinks applies. >>> I would first check the integrity of the file. >>> I downloaded it here (not installed it, as I don't have SL6.5). >>> It unpacked fine though using "rpm2cpio filename.rpm | cpio -idmv" >>> I have the following checksum on it: >>> >>> MD5: f39d0ef9c4fd74cbfcbffa37f0ee18f2 PDFStudio_v9_0_2_linux.rpm >>> SHA1: 2e69d1b564cfebcac5cba9244bd04f64cedc959f PDFStudio_v9_0_2_linux.rpm >>> >>> It has an odd directory structure, it seems to put everything in >>> /pdfstudio9. > > No, it puts it all in 'pdfstudio9'. Like I said, the author of the RPM > needs a cluebat applied. It's unpacked into ".pdfstudio" not "pdfstudio" when I run "rpm2cpio PDFStudio_v9_0_2_linux.rpm | cpio -idm". Is this meant to be installed by a user in a home directory, like a browser extension? > I'd suggest "mkdir /opt", then run 'rpm2cpio" there to get the > directory contents. But I'd sooner stick my hand in a blender than > trust this thing, gods alone know what they put in the RPM > pre-scripts. and post-scripts. You can install it with "rpm -noscripts --notriggers ..." to avoid any bad or malicious scripts. I'm not too sure about the blender thing but I wouldn't install this rpm as is.
Re: rpm problem
On Fri, Jul 25, 2014 at 7:27 AM, Tom H wrote: > On Fri, Jul 25, 2014 at 6:39 AM, Nico Kadel-Garcia wrote: >> On Thu, Jul 24, 2014 at 3:00 PM, ToddAndMargo wrote: >>> On 07/23/2014 09:05 AM, Mark Stodola wrote: On 07/23/2014 10:43 AM, ToddAndMargo wrote: > > > I am having trouble installing the PDF Studio RPM. > > https://www.dropbox.com/s/slgrnolcsktaezz/PDFStudio_v9_0_2_linux.rpm > > # cat /etc/redhat-release > Scientific Linux release 6.5 (Carbon) > > # uname -r > 2.6.32-431.20.3.el6.x86_64 > > # rpm -ivh PDFStudio_v9_0_2_linux.rpm > Preparing... ### [100%] > 1:PDFStudio ### [100%] > error: unpacking of archive failed on file .pdfstudio9/: > cpio: Archive file not in header > > Any way to fix this? >> >> By using s cluebat on the package author. It's not a good package. >> It's misnamed, it drops everything in a relative directory, and there >> is no license. This is not a safe thing to install anywhere. Sorry, wasn't clear. It's not in the RPM spec file, which is pretty important these days. > $ find .pdfstudio9 -iname "*license*" > .pdfstudio9/lib/barcode4j_license.txt > .pdfstudio9/lib/swt/eclipse common public license.txt > .pdfstudio9/lib/dj/gnu lesser general public license.txt > .pdfstudio9/lib/bc_license.txt > .pdfstudio9/lib/miglayout_license.txt > .pdfstudio9/lib/js-14_license.txt > .pdfstudio9/jre/LICENSE > .pdfstudio9/jre/THIRDPARTYLICENSEREADME.txt > > I wonder which one, if any, the rpm author thinks applies. I would first check the integrity of the file. I downloaded it here (not installed it, as I don't have SL6.5). It unpacked fine though using "rpm2cpio filename.rpm | cpio -idmv" I have the following checksum on it: MD5: f39d0ef9c4fd74cbfcbffa37f0ee18f2 PDFStudio_v9_0_2_linux.rpm SHA1: 2e69d1b564cfebcac5cba9244bd04f64cedc959f PDFStudio_v9_0_2_linux.rpm It has an odd directory structure, it seems to put everything in /pdfstudio9. >> >> No, it puts it all in 'pdfstudio9'. Like I said, the author of the RPM >> needs a cluebat applied. > > It's unpacked into ".pdfstudio" not "pdfstudio" when I run "rpm2cpio > PDFStudio_v9_0_2_linux.rpm | cpio -idm". "rpm -qlp" reports as going in "pdfstudio", not even "/pdfstudio". I suspect that rpm and rpmbuild are unhappy about the use of unqualified filenames. > Is this meant to be installed by a user in a home directory, like a > browser extension? > > >> I'd suggest "mkdir /opt", then run 'rpm2cpio" there to get the >> directory contents. But I'd sooner stick my hand in a blender than >> trust this thing, gods alone know what they put in the RPM >> pre-scripts. and post-scripts. > > You can install it with "rpm -noscripts --notriggers ..." to avoid any > bad or malicious scripts. Well, yes. But those are only examples of the issues. Dropping in an "/etc/logrotate.d" file that moves aside /lib/libc.so, for example, would be similarly bad and might not show up for *weeks* if you weren't careful. > I'm not too sure about the blender thing but I wouldn't install this rpm as > is. I may overstate, very slightly.
Re: rpm problem
On Fri, Jul 25, 2014 at 7:39 AM, Nico Kadel-Garcia wrote:
> On Fri, Jul 25, 2014 at 7:27 AM, Tom H wrote:
>> On Fri, Jul 25, 2014 at 6:39 AM, Nico Kadel-Garcia wrote:
>>> On Thu, Jul 24, 2014 at 3:00 PM, ToddAndMargo wrote:
On 07/23/2014 09:05 AM, Mark Stodola wrote:
> On 07/23/2014 10:43 AM, ToddAndMargo wrote:
>
> I would first check the integrity of the file.
> I downloaded it here (not installed it, as I don't have SL6.5).
> It unpacked fine though using "rpm2cpio filename.rpm | cpio -idmv"
> I have the following checksum on it:
>
> It has an odd directory structure, it seems to put everything in
> /pdfstudio9.
>>>
>>> No, it puts it all in 'pdfstudio9'. Like I said, the author of the RPM
>>> needs a cluebat applied.
>>
>> It's unpacked into ".pdfstudio" not "pdfstudio" when I run "rpm2cpio
>> PDFStudio_v9_0_2_linux.rpm | cpio -idm".
>
> "rpm -qlp" reports as going in "pdfstudio", not even "/pdfstudio". I
> suspect that rpm and rpmbuild are unhappy about the use of unqualified
> filenames.
True (about "rpm -qlp ..."). I don't understand why rpm2cpio unpackes
into ".pdfstufio". Maybe it's trying "./pdfstudio" and fails because
there's relative path in the build. The postinstall script is:
$ rpm -qp --scripts PDFStudio_v9_0_2_linux.rpm
postinstall scriptlet:
if [ "$RPM_INSTALL_PREFIX0" = "" ]
then
RPM_INSTALL_PREFIX0="pdfstudio9"
fi
I4J_INSTALL_LOCATION="$RPM_INSTALL_PREFIX0"
cd "$I4J_INSTALL_LOCATION"
ln -sf "$I4J_INSTALL_LOCATION/pdfstudio9" /usr/local/bin/
/bin/echo -e "#!/usr/bin/env xdg-open
[Desktop Entry]
Type=Application
Name=PDF Studio 9
Exec=/bin/sh \"$I4J_INSTALL_LOCATION/pdfstudio9\"
Icon=$I4J_INSTALL_LOCATION/.install4j/pdfstudio9.png
" >> "$I4J_INSTALL_LOCATION/pdfstudio9.desktop"
chmod +x "$I4J_INSTALL_LOCATION/pdfstudio9.desktop"
ln -sf "$I4J_INSTALL_LOCATION/updater" /usr/local/bin/
ln -sf "$I4J_INSTALL_LOCATION/pdfstudiosu" /usr/local/bin/
if [ -f "$I4J_INSTALL_LOCATION/jre/lib/rt.jar.pack" ]; then
old_pwd200=`pwd`
cd "$I4J_INSTALL_LOCATION/jre"
echo "Preparing JRE ..."
jar_files="lib/rt.jar lib/jfxrt.jar lib/charsets.jar lib/plugin.jar
lib/deploy.jar lib/ext/localedata.jar lib/jsse.jar"
for jar_file in $jar_files
do
if [ -f "${jar_file}.pack" ]; then
bin/unpack200 -r ${jar_file}.pack $jar_file
if [ $? -ne 0 ]; then
echo "Error unpacking jar files. Aborting."
exit 1
fi
fi
done
bin/java -Xshare:dump >/dev/null 2>&1
cd "$old_pwd200"
fi
preuninstall scriptlet:
if [ "$RPM_INSTALL_PREFIX0" = "" ]
then
RPM_INSTALL_PREFIX0="pdfstudio9"
fi
I4J_INSTALL_LOCATION="$RPM_INSTALL_PREFIX0"
cd "$I4J_INSTALL_LOCATION"
if [ "$1" = "0" ] ; then
rm "/usr/local/bin/pdfstudio9" 2>/dev/null
rm "$I4J_INSTALL_LOCATION/pdfstudio9.desktop"
rm "/usr/local/bin/updater" 2>/dev/null
rm "/usr/local/bin/pdfstudiosu" 2>/dev/null
rm -Rf "$I4J_INSTALL_LOCATION/jre/lib"
fi
There's no SrPM because it doesn't seem to be OSS.
If you install from the upstream site, you have two options a 63M
shell script with embedded executable(s) and a 63M deb file.
