[opensuse] nahh there's no runaway crazy dependencies problem...
nahh there's no runaway crazy dependencies problem... fax2:~ # zypper in pdftk Loading repository data... Reading installed packages... Resolving package dependencies... The following NEW packages are going to be installed: PackageKit-gstreamer-plugin aspell aspell-en bundle-lang-gnome-en bundle-lang-gnome-extras-en fuse gconf-polkit gconf2 gd gdk-pixbuf-query-loaders gnome-icon-theme gnome-icon-theme-extras gnome-icon-theme-symbolic gnome-keyring gnome-keyring-pam gstreamer-0_10 gstreamer-0_10-plugins-base gtk2-branding-openSUSE gtk2-data gtk2-engine-murrine gtk2-immodule-amharic gtk2-immodule-inuktitut gtk2-immodule-thai gtk2-immodule-vietnamese gtk2-metatheme-sonar gtk2-tools gvfs gvfs-backend-afc gvfs-backends gvfs-fuse hunspell hunspell-tools libIDL-2-0 libXi6 libasound2 libatasmart4 libatk-1_0-0 libavahi-client3 libavahi-common3 libavahi-glib1 libbluetooth3 libcairo2 libcdda_interface0 libcdda_paranoia0 libcdio12 libcdio_cdda0 libcdio_paranoia0 libenca0 libenchant1 libexif12 libfuse2 libgcj45 libgcj45-jar libgcr0 libgdk_pixbuf-2_0-0 libgdu0 libgeoclue0 libgnome-keyring0 libgp11-0 libgp11-modules libgphoto2 libgstapp-0_10-0 libgstinterfaces-0_10-0 libgstreamer-0_10-0 libgtk-2_0-0 libgvfscommon0 libjasper1 liblockdev1 libogg0 libopenobex1 liborc-0_4-0 libpackagekit-glib2-14 libpango-1_0-0 libpixman-1-0 libproxy1-config-gnome libproxy1-pacrunner-webkit librcc0 librcd0 libsmbclient0 libsoup-2_4-1 libsqlite3-0 libtheora0 libvisual libvorbis0 libvorbisenc2 libwbclient0 libwebkitgtk-1_0-0 libxslt lockdev metatheme-sonar-common obex-data-server orbit2 pango-tools pdftk rcc-runtime sg3_utils sonar-icon-theme udisks xorg-x11-libXfixes xorg-x11-libXp xorg-x11-libXprintUtil xorg-x11-libXrender xorg-x11-libXv xorg-x11-libfontenc xorg-x11-libs xorg-x11-libxkbfile The following recommended packages were automatically selected: bundle-lang-gnome-en gnome-keyring gnome-keyring-pam gtk2-branding-openSUSE gtk2-data gtk2-immodule-amharic gtk2-immodule-inuktitut gtk2-immodule-thai gtk2-immodule-vietnamese gvfs gvfs-backend-afc gvfs-backends gvfs-fuse libgcj45-jar libgp11-modules obex-data-server sonar-icon-theme 106 new packages to install. Overall download size: 55.2 MiB. After the operation, additional 187.5 MiB will be used. Continue? [y/n/?] (y): -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday 20 January 2012 06:04:58 Brian K. White wrote:
nahh there's no runaway crazy dependencies problem...
fax2:~ # zypper in pdftk
none of the packages in that list are requirements of pdftk. e.g. I don't currently have PackageKit-gstreamer-plugin installed, and installing pdftk won't pull it in either. "zypper info --requires pdftk" doesn't show anything particularly weird. It looks more like you have a pattern installed which is very incomplete, and zypper is trying to fulfil the pattern's requirements. Maybe "zypper in -R pdftk" will ignore the other packages. Possibly --no- recommends Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 1/20/2012 9:40 AM, Anders Johansson wrote:
On Friday 20 January 2012 06:04:58 Brian K. White wrote:
nahh there's no runaway crazy dependencies problem...
fax2:~ # zypper in pdftk
none of the packages in that list are requirements of pdftk. e.g. I don't currently have PackageKit-gstreamer-plugin installed, and installing pdftk won't pull it in either. "zypper info --requires pdftk" doesn't show anything particularly weird.
It looks more like you have a pattern installed which is very incomplete, and zypper is trying to fulfil the pattern's requirements.
Maybe "zypper in -R pdftk" will ignore the other packages. Possibly --no- recommends
Anders
I had the minimal text-only pattern installed plus the base c/c++ and kernel devel patterns (needed to build a proprietary dialogic t1 card driver & daemon). The install was perfectly normal and performed fresh a day ago, of 11.4. Not aborted, not manually overridden to remove anything, no error during or after. It wasn't incomplete, just intentionally minimal, using the installers supplied pattern. Of course pdftk doesn't require all that stuff. I don't think it even has any gui functions. But it's written in java and built with gcj and it's obviously a case of one thing requires another things requires another thing. I'll give the no-recommends options a try on the next box. You may have something there. My spec file only has various buildrequires and autoreqprov, no explicit requires or recommends. I think it only ends up requiring libgcj ... Yep, just basic system libs and libgcj is the only special requirement: ---- fax2:~ # zypper info --requires pdftk Loading repository data... Reading installed packages... Information for package pdftk: Repository: @System Name: pdftk Version: 1.44-180.1 Arch: x86_64 Vendor: obs://build.opensuse.org/home:aljex Installed: Yes Status: up-to-date Installed Size: 3.0 MiB Summary: PDF Tool Kit Description: Pdftk is a simple tool for doing everyday things with PDF documents. Keep one in the top drawer of your desktop and use it to: - Merge PDF Documents - Split PDF Pages into a New Document - Decrypt Input as Necessary (Password Required) - Encrypt Output as Desired - Fill PDF Forms with FDF Data and/or Flatten Forms - Apply a Background Watermark - Report on PDF Metrics, including Metadata and Bookmarks - Update PDF Metadata - Attach Files to PDF Pages or the PDF Document - Unpack PDF Attachments - Burst a PDF Document into Single Pages - Uncompress and Re-Compress Page Streams - Repair Corrupted PDF (Where Possible) Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.4)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) libstdc++.so.6()(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libstdc++.so.6(GLIBCXX_3.4)(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) libstdc++.so.6(GLIBCXX_3.4.9)(64bit) libstdc++.so.6(GLIBCXX_3.4.11)(64bit) libgcj.so.11()(64bit) rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadIsLzma) <= 4.4.6-1 ---- Ah but libgcj45 requires a lot: ---- fax2:~ # zypper info --requires libgcj45 Loading repository data... Reading installed packages... Information for package libgcj45: Repository: @System Name: libgcj45 Version: 4.5.1_20101208-9.4 Arch: x86_64 Vendor: openSUSE Installed: Yes Status: up-to-date Installed Size: 54.4 MiB Summary: Java Runtime Library for gcc Description: This library is needed if you want to use the GNU Java compiler, gcj. Source code for this package is in gcc. Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) libm.so.6()(64bit) libm.so.6(GLIBC_2.2.5)(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libdl.so.2()(64bit) libdl.so.2(GLIBC_2.2.5)(64bit) libglib-2.0.so.0()(64bit) libz.so.1()(64bit) libgobject-2.0.so.0()(64bit) librt.so.1()(64bit) librt.so.1(GLIBC_2.2.5)(64bit) libpthread.so.0(GLIBC_2.3.2)(64bit) libgio-2.0.so.0()(64bit) libgmodule-2.0.so.0()(64bit) libgthread-2.0.so.0()(64bit) ld-linux-x86-64.so.2()(64bit) ld-linux-x86-64.so.2(GLIBC_2.3)(64bit) libgtk-x11-2.0.so.0()(64bit) libfontconfig.so.1()(64bit) libgmp.so.10()(64bit) libfreetype.so.6()(64bit) libpango-1.0.so.0()(64bit) libcairo.so.2()(64bit) libgdk_pixbuf-2.0.so.0()(64bit) libpng14.so.14()(64bit) libgdk-x11-2.0.so.0()(64bit) libpangocairo-1.0.so.0()(64bit) libXrender.so.1()(64bit) libpangoft2-1.0.so.0()(64bit) libICE.so.6()(64bit) libatk-1.0.so.0()(64bit) libSM.so.6()(64bit) libXrandr.so.2()(64bit) libgcc_s.so.1(GCC_3.3)(64bit) libgcc_s.so.1(GCC_3.3.1)(64bit) libgcc_s.so.1(GCC_4.2.0)(64bit) libgcj.so.11()(64bit) libXtst.so.6()(64bit) libgtkpeer.so()(64bit) rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadIsLzma) <= 4.4.6-1 rpmlib(VersionedDependencies) <= 3.0.3-1 /bin/sh /bin/sh fax2:~ # ---- And some of those spider out even further: fax2:~ # zypper info --requires libgtk-2_0-0 Loading repository data... Reading installed packages... Information for package libgtk-2_0-0: Repository: @System Name: libgtk-2_0-0 Version: 2.22.1-13.15.1 Arch: x86_64 Vendor: openSUSE Installed: Yes Status: up-to-date Installed Size: 7.9 MiB Summary: The GTK+ toolkit library (version 2) Description: GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off projects to complete application suites. Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.4)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.3)(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) libm.so.6()(64bit) libm.so.6(GLIBC_2.2.5)(64bit) libglib-2.0.so.0()(64bit) libgobject-2.0.so.0()(64bit) libX11.so.6()(64bit) libgio-2.0.so.0()(64bit) libgmodule-2.0.so.0()(64bit) libgtk-x11-2.0.so.0()(64bit) libXext.so.6()(64bit) libfontconfig.so.1()(64bit) libpango-1.0.so.0()(64bit) libcairo.so.2()(64bit) libgdk_pixbuf-2.0.so.0()(64bit) hicolor-icon-theme libc.so.6(GLIBC_2.3.3)(64bit) libgdk-x11-2.0.so.0()(64bit) libpangocairo-1.0.so.0()(64bit) libXrender.so.1()(64bit) libpangoft2-1.0.so.0()(64bit) libatk-1.0.so.0()(64bit) libcups.so.2()(64bit) libXfixes.so.3()(64bit) libXrandr.so.2()(64bit) libgailutil.so.18()(64bit) libXcomposite.so.1()(64bit) libXcursor.so.1()(64bit) libXdamage.so.1()(64bit) libXi.so.6()(64bit) libXinerama.so.1()(64bit) rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadIsLzma) <= 4.4.6-1 rpmlib(VersionedDependencies) <= 3.0.3-1 /bin/sh /sbin/ldconfig gtk2-tools fax2:~ # and so on... I'm not really claiming this is a suse problem. It's been a linux problem for years. Some developers have everything under the sun installed, and use functions from anywhere indiscriminately, and you end up with what should be dinky little programs that require 300 megs of gnome stuff all because they used something dumb like a base64 function that happened to come from some gnome library. This is a non-specific general rant. Do not take it as a call for any specific action. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Brian K. White wrote:
I'm not really claiming this is a suse problem. It's been a linux problem for years. Some developers have everything under the sun installed, and use functions from anywhere indiscriminately, and you end up with what should be dinky little programs that require 300 megs of gnome stuff all because they used something dumb like a base64 function that happened to come from some gnome library.
This is a non-specific general rant. Do not take it as a call for any specific action.
The only way to solve the problem, I think, is to explicitly test for it. I mean, it would be nice if developers would think about dependencies, which I'm sure some or even most do, but even good developers make mistakes. I wonder if it is possible to use some sort of smoke test rig to test for this condition. I guess the problem is that you would need some sort of facility for each package to say what it didn't expect :( But maybe it would be possible to automatically install each package on a minimal system and return the actual dependency list to the maintainer for checking. In this case, it looks like libgcj45 has an unreasonably large dependency list. But I haven't messed with Java for years, so I don't have a clue whether it's easy to fix. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, 2012-01-20 at 16:09 +0000, Dave Howorth wrote:
Brian K. White wrote:
I'm not really claiming this is a suse problem. It's been a linux problem for years. Some developers have everything under the sun installed, and use functions from anywhere indiscriminately, and you end up with what should be dinky little programs that require 300 megs of gnome stuff all because they used something dumb like a base64 function that happened to come from some gnome library.
This is a non-specific general rant. Do not take it as a call for any specific action.
The only way to solve the problem, I think, is to explicitly test for it. I mean, it would be nice if developers would think about dependencies, which I'm sure some or even most do, but even good developers make mistakes.
I wonder if it is possible to use some sort of smoke test rig to test for this condition. I guess the problem is that you would need some sort of facility for each package to say what it didn't expect :( But maybe it would be possible to automatically install each package on a minimal system and return the actual dependency list to the maintainer for checking.
In this case, it looks like libgcj45 has an unreasonably large dependency list. But I haven't messed with Java for years, so I don't have a clue whether it's easy to fix. Reminds me of installing Skype in 12.1. It pulled the ENTIRE Gnome desktop as a dependency when I installed using the package kit pickup from the browser. Installed fine using YaST.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Fri, 20 Jan 2012, Dave Howorth wrote:
In this case, it looks like libgcj45 has an unreasonably large dependency list. But I haven't messed with Java for years, so I don't have a clue whether it's easy to fix.
Nope, the deps are ok as they are. Why? Yes, libgcj needs little: $ ldd /usr/lib64/libgcj.so.11.0.0 linux-vdso.so.1 => (0x00007fff3d9ff000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fbb4e5f0000) librt.so.1 => /lib64/librt.so.1 (0x00007fbb4e3e6000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fbb4e1e2000) libz.so.1 => /lib64/libz.so.1 (0x00007fbb4dfca000) libc.so.6 => /lib64/libc.so.6 (0x00007fbb4dc5c000) /lib64/ld-linux-x86-64.so.2 (0x00007fbb519f7000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fbb4da46000) Buuuuut, that package also includes /usr/lib64/gcj-4.5-11/libjawt.so for the java-AWT-GUI, and _THAT_ lib depends on the gtk/x11 stuff. So, I'd say it's a packaging problem, the GUI stuff should be packaged seperately as e.g. libgcj-gui45 or something. HTH, -dnh, too tired to file a bug / feature request -- Coffee not found: user halted -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/21/2012 08:24 AM, David Haller wrote:
Nope, the deps are ok as they are. Why? Yes, libgcj needs little:
$ ldd /usr/lib64/libgcj.so.11.0.0 linux-vdso.so.1 => (0x00007fff3d9ff000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fbb4e5f0000) librt.so.1 => /lib64/librt.so.1 (0x00007fbb4e3e6000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fbb4e1e2000) libz.so.1 => /lib64/libz.so.1 (0x00007fbb4dfca000) libc.so.6 => /lib64/libc.so.6 (0x00007fbb4dc5c000) /lib64/ld-linux-x86-64.so.2 (0x00007fbb519f7000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fbb4da46000)
Buuuuut, that package also includes /usr/lib64/gcj-4.5-11/libjawt.so for the java-AWT-GUI, and_THAT_ lib depends on the gtk/x11 stuff.
So, I'd say it's a packaging problem, the GUI stuff should be packaged seperately as e.g. libgcj-gui45 or something.
HTH,
bkw, dnh, You have hit on a very longstanding complaint and are correct pdftk has no gui at all. What should be a tiny build and tiny app has always been hindered by the garbage collector dependency. Not only is the gui requirement from gcj nuts, but gcj generally lags terribly behind upstream gcc versions so even building pdftk can be a pain on 'current' systems due to the gcc/gcc-gcj version mismatches. Easily handleable, but a royal PITA. pdftk is an incredibly useful tool. Perhaps the developer could find a way to eliminate the GUI requirement so that I could be packaged/installed on systems that have no GUI desktop installed. I'll forward this to the developer listed in the man page. I'll let you know if I get a reply. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin said the following on 01/23/2012 10:59 AM:
You have hit on a very longstanding complaint and are correct pdftk has no gui at all.
Oh? http://www.paehl.de/pdf/gui_pdftk.html http://suslic-2012.narod.ru/PDFTkGUI.html There's also http://pdftk4all.sourceforge.net/ http://angusj.com/pdftkb/#pdftkbuilder but you may not care to use those :-) -- Just because something doesn't do what you planned it to do doesn't mean it's useless. Thomas A. Edison -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/23/2012 10:14 AM, Anton Aylward wrote:
David C. Rankin said the following on 01/23/2012 10:59 AM:
You have hit on a very longstanding complaint and are correct pdftk has no gui at all.
Oh? http://www.paehl.de/pdf/gui_pdftk.html http://suslic-2012.narod.ru/PDFTkGUI.html
There's also http://pdftk4all.sourceforge.net/ http://angusj.com/pdftkb/#pdftkbuilder but you may not care to use those :-)
Thanks Anton, The issue I see is those that just want pdftk and don't want a gui shouldn't have to install 200MB of gui just to get pdftk. The pdftk tool is very useful in fax backends, etc. in compiling documents from various sources into a finished pdf. (i.e. compiling the output of multiple postscripts via pstopdf into a single pdf for fax or storage, etc..) The pdftk_guis are fine if you want to do it manually, but for basic processing by script, the gui should be required at all. By itself, pdftk is quite an amazing backend tool. (see pdftk --help) Why it (a command line tool) should be saddled with the requirement of pulling in a large number of gui related files just doesn't make much sense. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 1/23/2012 11:14 AM, Anton Aylward wrote:
David C. Rankin said the following on 01/23/2012 10:59 AM:
You have hit on a very longstanding complaint and are correct pdftk has no gui at all.
Oh? http://www.paehl.de/pdf/gui_pdftk.html http://suslic-2012.narod.ru/PDFTkGUI.html
There's also http://pdftk4all.sourceforge.net/ http://angusj.com/pdftkb/#pdftkbuilder but you may not care to use those :-)
The existence of these front ends has absolutely no bearing on this discussion, which is about how a command line tool ends up pulling in a lot of gui packages as indirect dependencies while the tool itself does not use them. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Mon, 23 Jan 2012, David C. Rankin wrote:
On 01/21/2012 08:24 AM, David Haller wrote:
Nope, the deps are ok as they are. Why? Yes, libgcj needs little:
$ ldd /usr/lib64/libgcj.so.11.0.0 linux-vdso.so.1 => (0x00007fff3d9ff000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fbb4e5f0000) librt.so.1 => /lib64/librt.so.1 (0x00007fbb4e3e6000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fbb4e1e2000) libz.so.1 => /lib64/libz.so.1 (0x00007fbb4dfca000) libc.so.6 => /lib64/libc.so.6 (0x00007fbb4dc5c000) /lib64/ld-linux-x86-64.so.2 (0x00007fbb519f7000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fbb4da46000)
Buuuuut, that package also includes /usr/lib64/gcj-4.5-11/libjawt.so for the java-AWT-GUI, and_THAT_ lib depends on the gtk/x11 stuff.
So, I'd say it's a packaging problem, the GUI stuff should be packaged seperately as e.g. libgcj-gui45 or something. [..] You have hit on a very longstanding complaint and are correct pdftk has no gui at all. What should be a tiny build and tiny app has always been hindered by the garbage collector dependency.
GCJ is not a garbage collector. ==== info gcj ==== This manual describes how to use `gcj', the GNU compiler for the Java programming language. ==== It's the GCC Java Compiler.
Not only is the gui requirement from gcj nuts, [..] pdftk is an incredibly useful tool. Perhaps the developer could find a way to eliminate the GUI requirement so that I could be packaged/installed on systems that have no GUI desktop installed.
You misunderstand. Not pdftk requires the GUI. Java does. Java includes a GUI, i.e. AWT. There's nothing the pdftk-upstream can do about the opensuse libgcj-package including the libjawt. WE, that is the opensuse gcj packagers need to split out the awt lib into a seperate package, so that non-gui java programs do not pull in gtk/glib/gnome/X stuff. So, file a bug: https://bugzilla.novell.com/enter_bug.cgi?classification=7340&product=openSUSE.org&component=3rd%20party%20software&assigned_to=rguenther@suse.com&short_desc=devel:gcc/libgcj45:%20Bug That's the devel-project packaging GCC/libgcj. The fix should be straightforward, as libgcj already consists of quite a few subpackages. Ask, that at least libjawt.so and libgtkpeer.so (also depends on the GTK+ stack) should be packaged seperately from the rest. That'd leave above mentioned for libgcj itself plus libgmp for libjavamath.so (it's ok, I think, to keep that lib, i.e. require that for the libgcj package). Oh, actually, you could do it yourself, too. But maybe a little steep if you've not read specfiles before. But to go to the project and look at the specfile: https://build.opensuse.org/package/view_file?file=libgcj45.spec&package=libgcj45&project=devel%3Agcc&rev=8f158fa5198b24244e5468924ac4c488 concentrate on %package, %description and %files sections and think about what would need to be changed. -dnh -- A monk. A punk. A chick. In a kick-ass flick. -- Bulletproof Monk -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/23/2012 12:03 PM, David Haller wrote:
You misunderstand. Not pdftk requires the GUI.
I did (must be Monday :)
So, file a bug:
<snip>
Got it, thanks dnh. I took a stab at the report: https://bugzilla.novell.com/show_bug.cgi?id=742935 I'm hazy on the exact details, so please feel free to add where needed. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Mon, 23 Jan 2012, David C. Rankin wrote:
On 01/23/2012 12:03 PM, David Haller wrote:
You misunderstand. Not pdftk requires the GUI.
I did (must be Monday :)
<sings>Tell me why I don't like Mooondaaaays ...
So, file a bug:
<snip>
Got it, thanks dnh. I took a stab at the report:
Very good subject! :)
I'm hazy on the exact details, so please feel free to add where needed.
You got it. I clarified it a little bit (but they'd have got that anyway). -dnh -- Me? No, why me? She's much more interesting. An enigma wrapped up in a riddle with a tail in the middle. -- Harper about Trance Gemini -- Andromeda 1x14 - Harper 2.0 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 1/23/2012 3:16 PM, David Haller wrote:
Hello,
On Mon, 23 Jan 2012, David C. Rankin wrote:
On 01/23/2012 12:03 PM, David Haller wrote:
You misunderstand. Not pdftk requires the GUI.
I did (must be Monday :)
<sings>Tell me why I don't like Mooondaaaays ...
So, file a bug:
<snip>
Got it, thanks dnh. I took a stab at the report:
Very good subject! :)
I'm hazy on the exact details, so please feel free to add where needed.
You got it. I clarified it a little bit (but they'd have got that anyway).
-dnh
Thanks. I should probably do this myself since I revamped the pdftk package in the first place (it was removed from Factory around 11.2, so I started packaging it myself, replaced the entire .spec and added my own patch to allow it to build on a wide range of suse versions and gcj versions, which the upstream author says he's including in the next version, then someone took that and put it back into Factory) But I don't have time to branc, modify, and submit-request the changes back to the devel project at the moment. Or maybe I do at home maybe one of these days... Always too much to do. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David Haller wrote:
On Mon, 23 Jan 2012, David C. Rankin wrote:
Got it, thanks dnh. I took a stab at the report:
Very good subject! :)
I'm hazy on the exact details, so please feel free to add where needed.
You got it. I clarified it a little bit (but they'd have got that anyway).
I'm a bit confused about the proposed fix: Richard Guenther "Another question is whether anyone really needs anything besides the core libgcj now that openJDK is the prefered Java stack. I can split libjawt and libgtkpeer to a different sub-package, but as they are loaded dynamically at runtime no rpm dependencies will be ever autogenerated, so all packages requiring them will have to explicitly add a requirement. I doubt that is what we want (silently breaking apps using AWT). "What's the state of Java in openSUSE? Can we simply drop AWT support from GCC libgcj (and thus also reduce the build dependencies of it?)." Michal Vyskocil "I would say yes - however this has to be checked first." Am I right in thinking that the proposed fix is to remove AWT altogether? How does that meet or exceed the criterion of not "silently breaking apps using AWT"? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Jan 25, 2012 at 10:44:41AM +0000, Dave Howorth wrote:
David Haller wrote:
On Mon, 23 Jan 2012, David C. Rankin wrote:
Got it, thanks dnh. I took a stab at the report:
Very good subject! :)
I'm hazy on the exact details, so please feel free to add where needed.
You got it. I clarified it a little bit (but they'd have got that anyway).
I'm a bit confused about the proposed fix:
I'm more confused by replies to bugzilla reports on this list. You'll not get the attention of those who commented inside bugzilla. Consider to add your suggestions, comments and questions there, please. Thanks, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
participants (8)
-
Anders Johansson -
Anton Aylward -
Brian K. White -
Dave Howorth -
David C. Rankin -
David Haller -
Lars Müller -
Roger Luedecke