Hi,
the latest osc package (0.7) in openSUSE:Tools has support for local
builds.
usage: 1. osc build <platform> <arch> <specfile> [--clean|--noinit]
2. BUILD_DIST=... osc build <specfile> [--clean|--noinit]
where BUILD_DIST equals <platform>-<arch>
When you call it for the first time, it will tell you how to add some
configuration to ~/.oscrc.
You may want to configure sudo with option NOPASSWD for /usr/bin/build
and set su-wrapper to 'sudo' in .oscrc.
Let me know how it works you.
Regards,
Peter
--
SUSE LINUX Products GmbH Thought is limitation.
Research & Development Free your mind.
Hello,
a miror question about / problem with the Release: number:
In the specfile, I have to set a release number:
Release: 42
(If I don't, rpm complains and the build fails.)
The build service edits this number when building the package and sets
it to 1.42 then 2.42 then 3.42 etc.
This makes the release number in the specfile quite useless because it's
only on the second position.
The behaviour can also cause problems when someone imports a package to
the build service.
Say I have released a manually built foobar-1.0-42 package, then move to
the build service and do some small changes without changing the
version number. The build service will compile a foobar-1.0-1.42
package which looks "older" to RPM :-(
Are there any plans to change the behaviour regarding the release
number?
Regards,
Christian Boltz
--
Was hat ein Revolver mit Windows 98 gemeinsam?
Solange sie nicht geladen sind, sind sie harmlos.
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice-unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice-help(a)opensuse.org
Dear buildserver maintainer(s),
could one of the opensuse buildserver maintainer(s) please remove the
following packages:
home:/rbos/SL-10.0_i586/i586/gramps-2.1.90-7.1.i586.rpm
home:/rbos/SL-10.0_i586/src/gramps-2.1.90-7.1.src.rpm
home:/rbos/SL-10.0_x86_64/src/gramps-2.1.90-7.1.src.rpm
home:/rbos/SL-10.0_x86_64/x86_64/gramps-2.1.90-7.1.x86_64.rpm
home:/rbos/SL-10.1_i586/i586/gramps-2.1.90-7.1.i586.rpm
home:/rbos/SL-10.1_i586/src/gramps-2.1.90-7.1.src.rpm
home:/rbos/SL-10.1_x86_64/src/gramps-2.1.90-7.1.src.rpm
home:/rbos/SL-10.1_x86_64/x86_64/gramps-2.1.90-7.1.x86_64.rpm
The got left behind after I renamed the package name in the specfile from
gramps to gramps-beta. At the moment gramps might get the gramps beta
version, which is something I tried to avoid....
After the removal of the above mentioned packages, the package database is of
course out of sync. Can this be synchronized, or should I start a kind of
dummy build?
Sorry for the additional work!
--
Richard Bos
Without a home the journey is endless
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice-unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice-help(a)opensuse.org
Adrian,
-
Norm Paxton
Software Engineer
npaxton(a)novell.com
(801) 861-5799
Novell, Inc.
Software for the Open Enterprise
http://www.novell.com/open
>>> Adrian Schröter <adrian(a)suse.de> 07/28/06 3:45 AM >>>
> CC'ing the list ...
> Am Friday 28 July 2006 01:15 schrieb Norm Paxton:
> > Adrian,
> >
> > From the opensuse-buildservice, while you were out:
> > Can you help me with this? (I'll be happy to provide more info, if
> > necessary)
> >
> > -Norm Paxton
> > ***************************************************************
> > normp: darix: appears that adrianS is out of office today (hasn't been
> > online for a while). Is there somebody else that could help us resolve
> > the package mapping question from yesterday about dbus on fedora?
> >
> > judas_iscariote: normp: what's the issue eh ? ;)
> >
> > normp: I have a project that requires hwinfo. On SuSE, no problem -
> > hwinfo is fine there. I have to include (build) hwinfo in my project,
> > for fedora. hwinfo has a Requires (but not BuldRequires) on dbus-1.
> > fedora defaults with dbus-0.
> >
> > normp: KDE/KDE4 has a dbus-1 package on fedora. I linked that project.
> >
> >
> > normp: At my project (omc-base, which requires hwinfo) build prep, it
> > installs dbus-1 (as expected) but immediately after, tries to install
> > dbus-0, causing conflicts.
> >
> > normp: Suggestion was that this is likely a package-mapping problems
> > with dbus on fedora.
> >
> > normp: If I add dbus-1 as a 'BuildRequires' on hwinfo, I get identical
> > problem building hwinfo, if that helps narrow it down?
>
> The problem is that some package within the BuildRequires requires dbus-0.
> This is nothing what can be fixed via mappings, it is a packaging issue of
> dbus-1 in first place.
>
> Either dbus-1 packages for Fedora needs to be able to coexist with dbus-0
> packages or it must be possible to setup a system with dbus-1 only.
>
> This is not an issue of the build service, it is a coding issue in first
> place. If dbus-1 is incompatible with dbus-0, but can't coexist it is problem
> within dbus in first place.
I am including (below, it is long) an IRC discussion from the #hal channel.
Perhaps it sheds more light on this.
The summary is this: "Stupid packaging problem"
Sounds like they accidentally (once upon a time) changed the package name
instead of the version #?
In any case, they say that dbus and dbus-1 are essentially they same.
Does this help in the argument for package mapping for fedora?
>
> bye
> adrian
>
> --
>
> Adrian Schroeter
> SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
> email: adrian(a)suse.de
**Discussion from freenode/#hal:
(10:07:23) normp: can anyone here answer questions on hal's dependency on dbus, or is that better sent to dbus mailing list?
(10:08:13) normp: specifically, dbus vs dbus-1
(10:11:30) kay: normp: there is only on dbus, wht do you mean?
(10:11:42) kay: only one dbus
(10:12:52) normp: kay: I have an rpm that depends on dbus-1 (dbus-1-v#, dbus-1-glib-v#, etc) and another that depends on dbus (dbus-v#, etc). They conflict - both trying to use the same conf file, etc.
(10:13:39) normp: more specifically, I'm trying to build hwinfo on fedora. hwinfo has dependency on dbus-1 and hal, but hal has dependency on dbus. Hence I get the dual but conflicting dependency.
(10:14:20) kay: normp: yeah, it's a silly packaging problem
(10:14:32) normp: can't find anything in google explaining difference between dbus and dbus-1, why the odd naming convention, etc.
(10:14:48) kay: it's distro specific, you should probably ask on the fedora lists to get that resolved
(10:14:50) normp: Am I OK putting hwinfo's dependency on dbus? Are they really the same?
(10:15:21) kay: dbus and dbus-1 are the same, yes. at least today, we have only dbus in one version
(10:15:28) normp: ok. Thanks.
(10:18:36) normp: kay: follow-on... hwinfo comes from suse, has the dependency on dbus-1. You mention 'silly packaging problem'. ShonyK: why should this be a bug?
(10:19:28) normp: dannyK: I don't know - I'm just trying to solve this dual/conflicting dependency problem.
(10:19:45) kay: normp: oh, mixing system rpm's across distros doesn't really work, yeah
(10:19:59) dannyK: normp: is this really a problem?
(10:20:16) dannyK: normp: this work perfect on SUSE ...
(10:20:25) dannyK: normp: I don't understand the problem
(10:22:32) normp: dannyK: Problem comes when I try to build my new open-source project for multiple platforms. I'm using the opensuse build-service. hwinfo has dependency on 'dbus-1' and 'hal'. Works fine on suse. But on fedora, hal has dependency on 'dbus' not 'dbus-1' and conflicts. Can't build. If there's truly one dbus, with a 'silly packaging problem', is the real answer to get them aligned on the 'real' version of dbus?
(10:23:36) normp: dannyK: if you have other suggestions and want to sidebar (since not directly related to hal, even though the original question is) I'd be happy to hear them :)
(10:26:59) dannyK: If you try to build with the opensuse buildservice with *one* specfile for all distros you need IMO to use ifdef's for different package names ... bug you should maybe ask this on the related opensuse ML ... btw. IMO (and IIRC) there is some kind of mapping in the buildservice to handle different package names for the same package. If this not work for dbus you should report this
(10:32:27) normp: dannyK: thanks. Yes, I have been working with some at the build service. This is, according to them, not a mapping issue, but rather an issue of specifically declared version dependencies. Will take this conversation back to them, see if it helps.
(10:35:12) normp: dannyK: fyi: here is their reply: 'The problem is that some package within the BuildRequires requires dbus-0. This is nothing what can be fixed via mappings, it is a packaging issue of dbus-1 in first place. Either dbus-1 packages for Fedora needs to be able to coexist with dbus-0 packages or it must be possible to setup a system with dbus-1 only. This is not an issue of the build service, it is a coding issue in first place. If dbus-1 is incompatible with dbus-0, but can't coexist it is problem within dbus in first place.'
(10:35:30) normp: the 'some package' referred to is hal
(10:37:05) dannyK: normp: on which distro exist dbus-0 ?
(10:37:16) mjg59: normp: hal doesn't use dbus-0
(10:38:48) dannyK: mjg59: on fedora, but on Mandriva (their package names are sometimes really strange)?
(10:38:58) normp: dannyK: from the build on fedora 5 with extras:
(10:38:58) normp: installing dbus-1-0.62-1.1
(10:38:58) normp: warning: user messagebus does not exist - using root
(10:38:58) normp: installing dbus-0.61-3
(10:38:58) normp: file /etc/dbus-1/system.conf from install of dbus-0.61-3 conflicts with file from package dbus-1-0.62-1.1
(10:38:58) normp: file /usr/bin/dbus-send from install of dbus-0.61-3 conflicts with file from package dbus-1-0.62-1.1
(10:38:58) normp: file /usr/share/man/man1/dbus-daemon.1.gz from install of dbus-0.61-3 conflicts with file from package dbus-1-0.62-1.1
(10:39:49) normp: not really 'dbus-0' but rather 'dbus' as compared to 'dbus-1' as required by hwinfo.
(10:40:02) dannyK: how does fedora name the package ? dbus or dbus-1 ?
(10:40:07) normp: dbus
(10:40:11) davidz: normp: on Fedora the package have always been 'dbus'
(10:40:14) davidz: the name that is
(10:40:25) davidz: of the rpm
(10:40:34) mjg59: Well, mandrive may be broken
(10:40:34) normp: therein is the problem - hwinfo requires dbus-1, and they can't coexist appaently
(10:40:58) mjg59: normp: They're the same package
(10:41:17) mjg59: Or, at least, they should be
(10:41:18) dannyK: then ifdef the buildrequires and use your own for fedora
(10:42:33) normp: you mean build my own hal or hwinfo. I'm a ways down the road of separate builds for the distros.
(10:42:36) dannyK: or try to use the Provides/Obsoletes flag from rpm
(10:42:59) davidz: normp: mixing rmp: Back to the primary question, which was the difference between dbus and dbus-1. Answered, I believe.
(10:43:09) davidz: normp: or assuming that packages are named the same
(10:43:15) mjg59: normp: There is no difference between dbus and dbus-1
(10:43:22) davidz: normp: you rather want the requires to be on .so's btw
(10:43:24) mjg59: normp: dbus-1 has the abi version encoded into the package name, dbus doesn't
(10:43:25) dannyK: nothing only different rpm names
(10:43:37) davidz: normp: e.g. libdbus-1.so.2 or libdbus-1.so.3
(10:43:44) davidz: normp: then e.g. rpm can figure out the package to install
(10:43:57) davidz: normp: and IIRC rpmbuild gets this right by itself
(10:44:18) davidz: again, I just don't see a point in trying to make one spec file works across different distributions
(10:44:27) davidz: it might work once but in general it's just too difficult
(10:44:48) davidz: it's sad but I think that's the way it is
(10:44:51) ***davidz goes to lunch
(10:45:04) normp: okay. thanks all.
(10:45:06) dannyK: davidz: this is maybe not so easy with the opensuse buildservice, where you can build for more than only one distribution
(10:45:42) davidz: dannyK: so the whole idea of the opensuse buildservice is to use the same spec file?
(10:45:46) normp: using %if (distro) all over the place...
(10:46:06) davidz: dannyK: might be good, I don't really know much about packaging... :-)
(10:46:14) dannyK: and the advantage of the buildservice is: only one spec and the package build on SUSE/Fedora4/5/mandriva ...
(10:46:27) davidz: ok
(10:46:32) dannyK: should build ;-)
(10:46:50) normp: davidz: really, quite nice. problem came with the dual/imcompatible dependencies of dbus and dbus-1
(10:47:09) dannyK: yes looks so
(10:48:13) dannyK: normp: use %if (distro) only for the package requirements and maybe Provides/Obsoletes
-Norm
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice-unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice-help(a)opensuse.org
Hi,
now that all issues concerning $subject seems to be consequently
ignored, I try one more time:
After providing a too early released 3.5.4, the whole repo got removed,
but without reverting to a decent backup version (e.g. 3.5.3). This is
very unfortunate, since I'm as silly as trusting your service in
providing some decent KDE version, which I do rsync stupidly
with --delete. Okay, that's definitely my fault, which I do regret!
Now I'm desperately fighting with designer crashing way too often, up to
the point where I decided to rebuild qt3-3.3.6-151.1 in order to get to
the debuginfo packages. But no hope, no src package available.
Adrian, while the build service concept is sound, and I understand, that
there's no warranty in any aspect, but KDE: is a big mess, which needs
urgent fixing. I'm sure, I'm not the only one, who relies on it.
Getting ignored with notifying issues doesn't raise confidence either.
Am I forced to revert to 9.3's original KDE version in order to get
back to a consistent system?
Frustrated,
Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice-unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice-help(a)opensuse.org
I've tried at least three possible methods to unsubscribe from this list,
which sadly is a bit above my head. Is there an admin who can look into it?
--
Cheers,
TonyB
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice-unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice-help(a)opensuse.org
Hi,
today i tried to link a package from another project to my project which
wasn't a problem. Then i checked out the new package with osc but i only
find a "_link"-file in the package dir.
So how can i add a patch for example or how can i modify the specfile?
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice-unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice-help(a)opensuse.org
Hi,
what is the strategy for a repository that is going to have (get) ackages?
Those new packages will replace the current stable packages, which is not
desired as the new ones are just beta.
Just wondering how others are coping with this.
--
Richard Bos
Without a home the journey is endless
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice-unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice-help(a)opensuse.org
Hello Buildservice users!
We had a little trouble with our signing program, thus many
packages and repositories did not get signed the last couple
of days. I hope everything is fixed now, please send us mail
if you detect something is still broken.
(I hope the old unsigned packages/repositories get updated with
newer versions fast...)
Sorry for the inconvenience,
Michael.
--
Michael Schroeder mls(a)suse.de
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice-unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice-help(a)opensuse.org
CC'ing the list ...
Am Friday 28 July 2006 01:15 schrieb Norm Paxton:
> Adrian,
>
> From the opensuse-buildservice, while you were out:
> Can you help me with this? (I'll be happy to provide more info, if
> necessary)
>
> -Norm Paxton
> ***************************************************************
> normp: darix: appears that adrianS is out of office today (hasn't been
> online for a while). Is there somebody else that could help us resolve
> the package mapping question from yesterday about dbus on fedora?
>
> judas_iscariote: normp: what's the issue eh ? ;)
>
> normp: I have a project that requires hwinfo. On SuSE, no problem -
> hwinfo is fine there. I have to include (build) hwinfo in my project,
> for fedora. hwinfo has a Requires (but not BuldRequires) on dbus-1.
> fedora defaults with dbus-0.
>
> normp: KDE/KDE4 has a dbus-1 package on fedora. I linked that project.
>
>
> normp: At my project (omc-base, which requires hwinfo) build prep, it
> installs dbus-1 (as expected) but immediately after, tries to install
> dbus-0, causing conflicts.
>
> normp: Suggestion was that this is likely a package-mapping problems
> with dbus on fedora.
>
> normp: If I add dbus-1 as a 'BuildRequires' on hwinfo, I get identical
> problem building hwinfo, if that helps narrow it down?
The problem is that some package within the BuildRequires requires dbus-0.
This is nothing what can be fixed via mappings, it is a packaging issue of
dbus-1 in first place.
Either dbus-1 packages for Fedora needs to be able to coexist with dbus-0
packages or it must be possible to setup a system with dbus-1 only.
This is not an issue of the build service, it is a coding issue in first
place. If dbus-1 is incompatible with dbus-0, but can't coexist it is problem
within dbus in first place.
bye
adrian
--
Adrian Schroeter
SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
email: adrian(a)suse.de
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice-unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice-help(a)opensuse.org