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.