All,
More than once I have submitted something to factory that didn't have all the requires and buildrequires pieces already there.
Is there a simple test I can run on the package to verify that before I submit a new package?
In this specific case, I want to submit security -- log2timeline. I've been slowly submitting all the pre-reqs and I think I finally have everything in factory.
Thanks Greg
On 21 December 2011 20:12, Greg Freemyer greg.freemyer@gmail.com wrote:
Is there a simple test I can run on the package to verify that before I submit a new package?
osc build --alternative-project=openSUSE:Factory ...
On Wed, Dec 21, 2011 at 4:15 PM, Cristian Morales Vega cmorve69@yahoo.es wrote:
osc build --alternative-project=openSUSE:Factory ...
That will only check the buildrequires.
I tendo to do that, but changing (temporarily) the buildrequires to include all requires to make sure they're there.
Hello,
Am Mittwoch, 21. Dezember 2011 schrieb Greg Freemyer:
More than once I have submitted something to factory that didn't have all the requires and buildrequires pieces already there.
Is there a simple test I can run on the package to verify that before I submit a new package?
In this specific case, I want to submit security -- log2timeline.
Create a simple spec with BuildRequires: log2timeline
If you want to be really sure, create a new (sub)project where you a) osc linkpac $project log2timeline b) create a test package with just BuildRequires: log2timeline
If someone knows if/how this can be done in an automated way [1], please speak up ;-)
Regards,
Christian Boltz
[1] I'm not talking about a script that creates a project, linkpac's the package and auto-generates another package with the BuildRequires ;-)
On Wed, Dec 21, 2011 at 3:49 PM, Claudio Freire klaussfreire@gmail.com wrote:
On Wed, Dec 21, 2011 at 4:15 PM, Cristian Morales Vega cmorve69@yahoo.es wrote:
osc build --alternative-project=openSUSE:Factory ...
That will only check the buildrequires.
I tendo to do that, but changing (temporarily) the buildrequires to include all requires to make sure they're there.
I really like your suggestion very much.
Maybe a osc build sub-command could be created that tells osc to install all requires packages in the chroot env as well as buildrequires for an automated test without that manual specfile editing.
Or if --alternative-project has no other reason for being, maybe it could just always install requires packages in the chroot env. in addition to buildrequires.
Thanks Greg
On Wed, Dec 21, 2011 at 5:20 PM, Christian Boltz opensuse@cboltz.de wrote:
Hello,
Am Mittwoch, 21. Dezember 2011 schrieb Greg Freemyer:
More than once I have submitted something to factory that didn't have all the requires and buildrequires pieces already there.
Is there a simple test I can run on the package to verify that before I submit a new package?
In this specific case, I want to submit security -- log2timeline.
Create a simple spec with BuildRequires: log2timeline
If you want to be really sure, create a new (sub)project where you a) osc linkpac $project log2timeline b) create a test package with just BuildRequires: log2timeline
If someone knows if/how this can be done in an automated way [1], please speak up ;-)
Christian,
Interesting idea, but overly complex I suspect.
Greg
On Wed, Dec 21, 2011 at 8:26 PM, Greg Freemyer greg.freemyer@gmail.com wrote:
Maybe a osc build sub-command could be created that tells osc to install all requires packages in the chroot env as well as buildrequires for an automated test without that manual specfile editing.
I'd say just checking they're there and are "installable", without actually installing would be nice.
On Wednesday 21 December 2011, Christian Boltz wrote:
Hello,
Am Mittwoch, 21. Dezember 2011 schrieb Greg Freemyer:
More than once I have submitted something to factory that didn't have all the requires and buildrequires pieces already there.
Is there a simple test I can run on the package to verify that before I submit a new package?
In this specific case, I want to submit security -- log2timeline.
Create a simple spec with BuildRequires: log2timeline
If you want to be really sure, create a new (sub)project where you a) osc linkpac $project log2timeline b) create a test package with just BuildRequires: log2timeline
If someone knows if/how this can be done in an automated way [1], please speak up ;-)
Would be nice if this could be done without creating a new (temporary) project on server. Probably this should be _searched_ on OBS server.
Something like this:
osc search --capability CAPABILITY - list all projects and/or packages providing CAPABILITY
osc search --deps [--requires | --build-requires] spec-file - list all projects and/or packages providing deps of given spec file
Options: --pwd list only build enabled projects of current checkout -n, --not invert search
OBS is able to parse and higlight missing deps quickly when a package build fails. Maybe this method could be used to implement such search functionality.
cu, Rudi
Hello,
On Wed, 21 Dec 2011, Claudio Freire wrote:
On Wed, Dec 21, 2011 at 8:26 PM, Greg Freemyer greg.freemyer@gmail.com wrote:
Maybe a osc build sub-command could be created that tells osc to install all requires packages in the chroot env as well as buildrequires for an automated test without that manual specfile editing.
I'd say just checking they're there and are "installable", without actually installing would be nice.
Seconded. Although: usually[1] all "Requires:" are required by "BuildRequires:" anyway, not the other way round (e.g. you don't need gcc to install the libfoo package).
Speaking of requires: I think rpmlint needs a new check: a package SHOULD NOT ever require its -lang package. If it does, the purpose of a -lang package is counteracted and the -lang stuff could just as well be packaged in the main package. WHY in @DIETY's name split out something you'll require anyway and that won't be used by anything else? Hello? It's not a shared lib for fsck's sake, it's translations. Recommends, Suggest, fine, if you must. But Require? *gah*
I dislike to install tons of languages I have no idea about just because I might need the german translation.
What would be really cool were if we could create a lang-repo and do something like this:
* have (all) packages, esp. well translated and much needed ones like glibc) split out -lang packages (well, if there's only C (=en) plus 1 or 2 more, I'd be lenient). Splitting out a -lang package is not much work for a packager and is often done already.
* The repo accepts the submitted -lang packages, takes them apart, splits them after languages automatically creating foo-lang-<LANG> rpms, possibly merging some stuff (e.g. en_* into en, even if there are seperate en_US / en_GB .. .mo files). That system should not get into variants/dialects etc.
* There could be lang-bundle-rpm made out of those (like bundle-lang-kde-en) for interdependent stuff, e.g. you need libkde, kde-base and stuff for _any_ kde app, so, bundle those -lang packages, but keep e.g. k3b-lang-de and kaffeine-lang-fr seperate (and both depend on bundle-lang-kde-de/-fr respectively)
That way, the user should be able to configure and get a set of languages (e.g. C, en, de, fr, but not es, zh, ...) that would be installed.
Scripting that should not be to hard, parsing the package-names will be the hardest I guess if the script has no "other" knowledge.
- take foo-lang-<version> - install / rpm2cpio (to %{buildroot}/) (--nodeps --force, we're only repackaging and massaging deps if applicable ;) - cd %{buildroot}/usr/share/locale - foreach dir in */LC_MESSAGES; do lang="${dir%/*}" # create a foo-lang-${lang}.spec (on the fly? Must try if rpmbuild # will use stdin ;) but a tmpfs will suffice, and create a # file-list with %{_datadir}/locale/${lang}/LC_MESSAGES/foo*, a # "Requires: foo\n Provides: foo-lang-${lang}", probably massage # "Requires: foobase-lang" into "Requires: foobase-lang-${lang}", # and package up ${lang}/LC_MESSAGES as foo-lang-${lang}.rpm done - off with foo-lang-*.rpm to the servers ;)
I think a simple 'rpmbuild' there will suffice, as there's nothing fancy, just a repackaging. If it suffices to use librpm or cpan's *RPM* modules can do that repackaging and inserting/adjusting deps, that'd suffice. Ouh: the RPM4 perl module looks promising at first glance, but seems not to have been developed since 2007. *sigh* Maybe another.
Anyway, a simple repackaging .spec using just a rpmbuild (not an OBS/osc instance) should be no problem. And guessing from how long it takes just to setup a build-instance in OBS for the simplest rpm, I think a single OBS-instance-equivalent kept running could probably handle the -lang packages from the other instances ... Maybe (as it's just repackaging), it could even run on some ppc64 obs-servers that must be quite depressed and have worn down their thumbs quite a lot from twiddling them, chronically having nothing to do ...
Caveats: a lot more packages on the servers, maybe one should/could even split up repos by lang (cf. devel:languages:perl:CPAN-*) ...
Motivation:
# du -hs /usr/share/locale/ 249M /usr/share/locale/ # find /usr/share/locale/ | wc -l 6375 # find /usr/share/locale/{en*,de*,all*,curr*} | wc -l 529 (+1 for locale.alias). # find /usr/share/locale/{en*,de*,all*,curr*} -printf '%s\n' | \ awk '{s+=$1;}END{printf("%.1f\n", s/1024);}' 14108.5 # find /usr/share/locale/ -printf '%s\n' | \ awk '{s+=$1;}END{printf("%.1f\n", s/1024);}' 237078.9
That's quite a bit of files and diskspace. Esp. compared to what I actually want. And I do already have e.g.:
bundle-lang-gnome-extras-en kdebase4-openSUSE-lang gimp-lang konqueror-plugins-lang bundle-lang-gnome-en bundle-lang-common-en bundle-lang-kde-en
as "taboo" and "broken" packages that require those ... The crass misproportion of wanted and unwanted and the br<censored> idea of making foo require foo-lang is what gets to me.
Well, maybe a brain fart, maybe not ...
-dnh, using "taboo" and breaking packages regularly also because of that. I install lang packages only if I need the german GUI to help others (i.e. to be able to start the App with LANG=de, to e.g. tell them go to "Hilfe" -> "Über ..." instead of "Help" -> "About" (well, not for that but for something e.g. deep in the Prefs-dialogues of seamonkey)). Or if the C-Locale of that package is not english (or german, which it should not be but I wouldn't care in that case).
*getting in his asbestos suit, just in case*
[1] can't think of a counter example right now, hm, maybe some icon/theme package?
PS: in this mail, xemacs surprised me a couple of times by DWIM (e.g. when reformatting the comment stuff in the above "foreach" block), but, yes, in other modes / use cases, it doesn't. Just a pleasant surprise this time ;)
Hello,
On Dec 22 02:53 David Haller wrote (excerpt):
... usually[1] all "Requires:" are required by "BuildRequires:"
No.
"Requires" and "BuildRequires" are independent of each other.
In other words: "Requires" and "BuildRequires" define two sets of packages where the intersecting set is usually non-empty but usually none is a superset of the other.
[1] can't think of a counter example right now
Think about a package which requires executables (also scripts) or whatever other files which are provided by another package.
Most of my packages have "Requires" which are not in "BuildRequires".
Kind Regards Johannes Meixner
Am Donnerstag, 22. Dezember 2011, 09:32:58 schrieb Johannes Meixner:
Hello,
On Dec 22 02:53 David Haller wrote (excerpt):
... usually[1] all "Requires:" are required by "BuildRequires:"
No.
"Requires" and "BuildRequires" are independent of each other.
In other words: "Requires" and "BuildRequires" define two sets of packages where the intersecting set is usually non-empty but usually none is a superset of the other.
This is only true for the direct package dependencies. But indirect requires are of course pulled.
Eg. Package A BuildRequires B which Requires C
C is of course installed when package A is built.
On 2011-12-21 23:20:17 +0100, Christian Boltz wrote:
Hello,
Am Mittwoch, 21. Dezember 2011 schrieb Greg Freemyer:
More than once I have submitted something to factory that didn't have all the requires and buildrequires pieces already there.
Is there a simple test I can run on the package to verify that before I submit a new package?
In this specific case, I want to submit security -- log2timeline.
Create a simple spec with BuildRequires: log2timeline
If you want to be really sure, create a new (sub)project where you a) osc linkpac $project log2timeline b) create a test package with just BuildRequires: log2timeline
If someone knows if/how this can be done in an automated way [1], please speak up ;-)
What about: curl -u username -X POST \ -d "$(echo -e 'Name: x\nBuildRequires: your_package(s)')" \ https://api.opensuse.org/build/openSUSE:Factory/standard/x86_64/_repository/...
If your_package(s) or one of its/their Requires don't exist you'll get an unresolvable error.
Marcus
On Wed, Dec 21, 2011 at 11:20 PM, Christian Boltz opensuse@cboltz.de wrote:
Hello,
Am Mittwoch, 21. Dezember 2011 schrieb Greg Freemyer:
More than once I have submitted something to factory that didn't have all the requires and buildrequires pieces already there.
Is there a simple test I can run on the package to verify that before I submit a new package?
In this specific case, I want to submit security -- log2timeline.
Create a simple spec with BuildRequires: log2timeline
If you want to be really sure, create a new (sub)project where you a) osc linkpac $project log2timeline b) create a test package with just BuildRequires: log2timeline
If someone knows if/how this can be done in an automated way [1], please speak up ;-)
Regards,
Christian Boltz
[1] I'm not talking about a script that creates a project, linkpac's the package and auto-generates another package with the BuildRequires ;-)
What if, as a last step, OBS tried to install the rpms once they are built? Then it can fail if the rpms won't install for whatever reason.
-Todd
Am Donnerstag, 22. Dezember 2011, 13:39:32 schrieb todd rme:
On Wed, Dec 21, 2011 at 11:20 PM, Christian Boltz opensuse@cboltz.de
wrote:
Hello,
Am Mittwoch, 21. Dezember 2011 schrieb Greg Freemyer:
More than once I have submitted something to factory that didn't have all the requires and buildrequires pieces already there.
Is there a simple test I can run on the package to verify that before I submit a new package?
In this specific case, I want to submit security -- log2timeline.
Create a simple spec with BuildRequires: log2timeline
If you want to be really sure, create a new (sub)project where you a) osc linkpac $project log2timeline b) create a test package with just BuildRequires: log2timeline
If someone knows if/how this can be done in an automated way [1], please speak up ;-)
Regards,
Christian Boltz
[1] I'm not talking about a script that creates a project, linkpac's the package and auto-generates another package with the BuildRequires ;-)
What if, as a last step, OBS tried to install the rpms once they are built? Then it can fail if the rpms won't install for whatever reason.
Actually we do that as last step, but with --nodeps.
The reason for --nodeps is to reduce the build depencies and therefore also cycles which would increase build time a lot.
On Thu, Dec 22, 2011 at 02:00:54PM +0100, Adrian Schröter wrote:
Actually we do that as last step, but with --nodeps.
The reason for --nodeps is to reduce the build depencies and therefore also cycles which would increase build time a lot.
(For clarification, this is done as "post build check". Such checks are plugins, for openSUSE they are defined in the post-build-checks package.)
Cheers, Michael.
Hello,
Am Donnerstag, 22. Dezember 2011 schrieb Marcus Hüwe:
On 2011-12-21 23:20:17 +0100, Christian Boltz wrote:
Create a simple spec with BuildRequires: log2timeline
If you want to be really sure, create a new (sub)project where you a) osc linkpac $project log2timeline b) create a test package with just BuildRequires: log2timeline
If someone knows if/how this can be done in an automated way [1], please speak up ;-)
What about: curl -u username -X POST \ -d "$(echo -e 'Name: x\nBuildRequires: your_package(s)')" \
https://api.opensuse.org/build/openSUSE:Factory/standard/x86_64/_repository/...
Nice solution, but...
If your_package(s) or one of its/their Requires don't exist you'll get an unresolvable error.
... unfortunately exactly this is the problem. If someone wants to check the dependencies before submitting a new package to factory, the package does not yet exist there. This results in <error>unresolvable: nothing provides your_package</error>
In other words: It must be possible to add (only) your_package from $develproject to the dependency check somehow...
Basically we need something like BuildRequires: your_package from_repo: $develproject (Yes, I know that this isn't valid spec file syntax, but you should get the point.)
BTW: How is this check done for SRs to Factory? I'd guess there's nobody who does it manually, right? ;-)
Regards,
Christian Boltz
On Thu, Dec 22, 2011 at 2:00 PM, Adrian Schröter adrian@suse.de wrote:
Am Donnerstag, 22. Dezember 2011, 13:39:32 schrieb todd rme:
On Wed, Dec 21, 2011 at 11:20 PM, Christian Boltz opensuse@cboltz.de
wrote:
Hello,
Am Mittwoch, 21. Dezember 2011 schrieb Greg Freemyer:
More than once I have submitted something to factory that didn't have all the requires and buildrequires pieces already there.
Is there a simple test I can run on the package to verify that before I submit a new package?
In this specific case, I want to submit security -- log2timeline.
Create a simple spec with BuildRequires: log2timeline
If you want to be really sure, create a new (sub)project where you a) osc linkpac $project log2timeline b) create a test package with just BuildRequires: log2timeline
If someone knows if/how this can be done in an automated way [1], please speak up ;-)
Regards,
Christian Boltz
[1] I'm not talking about a script that creates a project, linkpac's the package and auto-generates another package with the BuildRequires ;-)
What if, as a last step, OBS tried to install the rpms once they are built? Then it can fail if the rpms won't install for whatever reason.
Actually we do that as last step, but with --nodeps.
The reason for --nodeps is to reduce the build depencies and therefore also cycles which would increase build time a lot.
Would it be slower than any of the other approaches that are being suggested? It would probably also be easier to implement, right?
-Todd
Hello,
On Thu, 22 Dec 2011, Johannes Meixner wrote:
On Dec 22 02:53 David Haller wrote (excerpt):
... usually[1] all "Requires:" are required by "BuildRequires:"
No.
No.
"Requires" and "BuildRequires" are independent of each other.
Yes.
In other words: "Requires" and "BuildRequires" define two sets of packages where the intersecting set is usually non-empty but usually none is a superset of the other.
I know quite well.
[1] can't think of a counter example right now
Think about a package which requires executables (also scripts) or whatever other files which are provided by another package.
For example?
I've packaged _a lot_ of packages (a couple of hundred, most for my ex-SUSE 6.2 over 10 years (ISTR >>500 RPMs of packages by me installed), from small to quite a bunch like most of gnome). Usually, there's _very_ little you need to explicitly have in Requires that is not picked up automatically by "AutoReqProv" or via a require of the corresponding -devel packages (which you need to have in BuildRequires). And most if not all (well it should be all) configure-scripts (and alike) will check for those executables to be available for build, and so they'll get pulled into the Build and usually picked up as a Require for the Package.
Basically I know only 2 cases:
a) BuildRequires: libfoo-devel ### => autoReq: libfoo.so.* b) BuildRequires: foo\nRequires: foo
I do not recall a
c) Requires: bar
where bar is not automatically (indirectly pulled into the "Build" and picked up as a Req). So, in my experience at least for the majority of packages BuildRequires *is* a superset of (implicit) automatic Requires and (often redundant) explicit Requires.
Name me an example, where there's a needed explicit "Requires" that's not also needed for the build of the package. It may well be, that rpm does not automatically add the "Requires", so you'd have to write it in you specfile, but one _not needed for build_ would be a new one to me.
I can't think of such an example, but I guess there are those, esp. in the area you're muckin' about. I've not printed a page from any of my boxen since about 2005 and the last one was still from Win95[1] ;)
Most of my packages have "Requires" which are not in "BuildRequires".
Exactly my point. You don't need to specify the implicit Requires that the BuildRequires automatically pull in.
I *am* curious though for an example which needs an explicit "Requires" which is _not_ also "pulled" into the build, so, if you could name an example ...
Some foo-ppd-<ver>.rpm would be lame. You just need to repackage some files from tarball to rpm and add Requires like cups. No building or testing involved. That ("just repackaging") would be those exceptions I meant. That's "garnishing the tarball with requires" ;)
-dnh
PS: I'll pay you a beer or two somehow if you come up with something I deem a "valid" example (actually: for what you've been doing on the suse-linux/opensuse-de MLs for years ;)
PPS: I'll be off the PC for a few days and don't expect an answer soonish (depending on when I read you again elsewhere ;)
[1] I never got my printers work from Linux beyond a testpage and then my need for printing just went away. In the last 5 years I think I printed about 10 pages for myself, maybe 5 pages RMAs/Labels, 4 pages domain KK stuff, and the one odd other page I think. And of course, the ink in my respective "Tintenrotzer" was _always_ dried solid. So, I printed at my mum's, at my neighbours, at a PC shop (I payed them).
On Fri, Dec 23, 2011 at 9:59 PM, David Haller dnh@opensuse.org wrote:
For example?
I've packaged _a lot_ of packages (a couple of hundred, most for my ex-SUSE 6.2 over 10 years (ISTR >>500 RPMs of packages by me installed), from small to quite a bunch like most of gnome). Usually, there's _very_ little you need to explicitly have in Requires that is not picked up automatically by "AutoReqProv" or via a require of the corresponding -devel packages (which you need to have in BuildRequires). And most if not all (well it should be all) configure-scripts (and alike) will check for those executables to be available for build, and so they'll get pulled into the Build and usually picked up as a Require for the Package.
Then you've never packaged python apps. You don't need any -devel stuff on python, you only need python itself to generate bytecode.
It's also the case when there's any service you connect to by IPC, like dbus, X.org, etc...
And no, libX is *not* X.org
On Saturday, December 24, 2011 12:14:56 AM Claudio Freire wrote:
On Fri, Dec 23, 2011 at 9:59 PM, David Haller dnh@opensuse.org wrote:
For example?
I've packaged _a lot_ of packages (a couple of hundred, most for my ex-SUSE 6.2 over 10 years (ISTR >>500 RPMs of packages by me installed), from small to quite a bunch like most of gnome). Usually, there's _very_ little you need to explicitly have in Requires that is not picked up automatically by "AutoReqProv" or via a require of the corresponding -devel packages (which you need to have in BuildRequires). And most if not all (well it should be all) configure-scripts (and alike) will check for those executables to be available for build, and so they'll get pulled into the Build and usually picked up as a Require for the Package.
Then you've never packaged python apps. You don't need any -devel stuff on python, you only need python itself to generate bytecode.
It's also the case when there's any service you connect to by IPC, like dbus, X.org, etc...
And no, libX is *not* X.org
Some applications and libraries will also load libraries at runtime via libdl, instead of linktime. I ran into a situation the other day, in fact, where an application written in C with GTK libs had SVG icons. The application would not actually run without librsvg installed, and AutoReqProv didn't pick up the dependency, since it wasn't specified to the linker and thus not in the output of ldd. I had to add an explicit Requires tag for it.
Languages like Python, Perl, and Ruby will, of course, load their libraries at runtime, but automatically detecting them is problematic. There is a script in rpm that picks up Perl dependencies pretty well, but such a thing would be difficult for Python, since it supports conditional imports, and you often see stuff like this:
try: import somelib except ImportError: import someotherlib as somelib
It's impossible to tell which one should be required for an environment without some curated list of library names and Python versions. ElementTree is a prime example of this. It was brought into the Python standard lib in 2.5 and renamed to xml.etree.
So AutoReqProv is not perfect, and it never will be. We need to be mindful of this, too. It's easy to miss one if you only test a package on a "kitchen sink" desktop install. I would not have found that librsvg dependency if I had tested the application on my desktop.
Hello,
On Sat, 24 Dec 2011, James Oakley wrote:
On Saturday, December 24, 2011 12:14:56 AM Claudio Freire wrote:
On Fri, Dec 23, 2011 at 9:59 PM, David Haller dnh@opensuse.org wrote:
For example?
I've packaged _a lot_ of packages (a couple of hundred, most for my ex-SUSE 6.2 over 10 years (ISTR >>500 RPMs of packages by me installed), from small to quite a bunch like most of gnome). Usually, there's _very_ little you need to explicitly have in Requires that is not picked up automatically by "AutoReqProv" or via a require of the corresponding -devel packages (which you need to have in BuildRequires). And most if not all (well it should be all) configure-scripts (and alike) will check for those executables to be available for build, and so they'll get pulled into the Build and usually picked up as a Require for the Package.
Then you've never packaged python apps.
Ahh. I did, e.g. various extensions, but not one like below, they were generally using a lib normally (linking a python extension to the lib). And so you obviously need that lib (-devel) in BuildRequires.
You don't need any -devel stuff on python, you only need python itself to generate bytecode.
It's also the case when there's any service you connect to by IPC, like dbus, X.org, etc...
And no, libX is *not* X.org
Some applications and libraries will also load libraries at runtime via libdl, instead of linktime. I ran into a situation the other day, in fact, where an application written in C with GTK libs had SVG icons. The application would not actually run without librsvg installed, and AutoReqProv didn't pick up the dependency, since it wasn't specified to the linker and thus not in the output of ldd. I had to add an explicit Requires tag for it.
Ah, yes.
So AutoReqProv is not perfect, and it never will be. We need to be mindful of this, too. It's easy to miss one if you only test a package on a "kitchen sink" desktop install. I would not have found that librsvg dependency if I had tested the application on my desktop.
Ack.
Thanks to you both for the examples.
-dnh
Hello,
On Dec 24 01:59 David Haller wrote (excerpt):
Think about a package which requires executables (also scripts) or whatever other files which are provided by another package.
For example?
...
Most of my packages have "Requires" which are not in "BuildRequires".
Would you mind to have a look at some of my packages?
E.g. cups, hplip, gutenprint, OpenPrintingPPDs: -------------------------------------------------------------------------- $ osc cat Printing cups cups.spec | grep Requires ... Requires: ghostscript_any, ghostscript-fonts-std ... Requires: /usr/bin/pdftops -------------------------------------------------------------------------- $ osc cat Printing hplip hplip.spec | grep Requires ... Requires: ghostscript-library -------------------------------------------------------------------------- $ osc cat Printing gutenprint gutenprint.spec | grep Requires Requires: cups >= 1.2.2 -------------------------------------------------------------------------- $ osc cat Printing OpenPrintingPPDs OpenPrintingPPDs.spec | grep Requires -------------------------------------------------------------------------- Requires: foomatic-filters >= %{version} Requires: ghostscript-library Requires: hplip-hpijs --------------------------------------------------------------------------
Kind Regards Johannes Meixner
-
Adrian Schröter -
Christian Boltz -
Claudio Freire -
Cristian Morales Vega -
David Haller -
Greg Freemyer -
James Oakley -
Johannes Meixner -
Marcus Hüwe -
Michael Schroeder -
Rüdiger Meier -
todd rme