Hello
With the opensuse build service [obs] getting more usage every day
I wonder if this would make a diffence :-
1. Use solid state disks [ssd] to improve build times of package rpms
on, perhaps point the BuildRoot or _tmppath to the ssd's
Reason for asking.
Improve the packaging times during busy times on obs.
Cheers Glenn.
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Hello,
is usual, openeSUSE 10.3 runs out of maintenance and I will remove all repos
building against it in OBS.
openSUSE:10.3 project has been moved to DISCONTINUED: namespace as announced a
while ago.
bye
adrian
--
Adrian Schroeter
SUSE Linux Products GmbH
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
This question concerns both the OBS and packaging so I am sending to both
lists.
I am currently working on packaging the Swiss Ephemeris
http://www.astro.com/swisseph/
I am currently at the planning scheming and experimentation stage.
First I will do the library. But then there is the data. The data is about 60
files not all of which will be wanted by all people. There may be ways of
grouping but I am not sure. Perhaps one rpm per file. The Web page says:
> For this extended timespan the ephemeris requires 32 Mbytes of ephemeris
> files.
It would be a shame if this had to repeat for each distro. There may be other
projects with even more data.
This data is distro and architecture independent.
I understand that there should be different rpm per distro because different
distros link libraries differently and do other details differently.
There could be rpm version dependencies. Perhaps one distro can not understand
rpms from another distro as raw data.
My question is this is there a lowest common denominator rpm format that can
represent pure data (and a few text licensing files) and be understood by all
distros?
How would you get the build service to produce such rpms?
After you produced them how would you get the build service to serve them for
all rpm based distros?
Same question for debs and the debian based distros?
Unrelated question: a while back OBS debian binary repositories were debian
compatible but the source repositories were not. Is this still true?
--
Paul Elliott 1(512)837-1096
pelliott(a)BlackPatchPanel.com PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117
Hi All,
I am trying to install my program on Mandriva but can't seem to add
the OBS repository.
It seems that the command urpmi.addmedia doesn't work with the
normal RPM PM. Someone on IRC mentioned that I could specify a
different type for the repository in my OBS raw config to
automatically generate a urpmi compatible repo. What do I put as the
type for my Mandriva repo to make it urpmi compatible?
Thanks,
Nick
--
Nick Peterson
Programmer @ Siepel Lab
Cell: (480) 600-2544
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Hi all,
my project (kubeplayer) needs th ruby json gem installed, which is
available as rubygem-json in a foreign home repo, but not in the
official repos of opensuse. How can I import this package to my repo
to fullfil its dependency?
Json belongs to the std libs from ruby 1.9.x on. I was really
suprised, that a modern distro like opensuse still delivers ruby
1.8.x!
Kind regards,
Robert
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Greetings,
Is there any work being done for OpenVZ, LXC or other OS-level virtualization support for the build environment in OBS?
I am doing my Master's thesis on extending OBS to the cloud. Seeing that Amazon Web Services uses Xen for virtualization (and thus does not support Xen/KVM inside it), and that building without a sandboxed environment is not safe, OpenVZ and LXC would seem promising. There's also much talk about using these technologies in AWS, so I would see it possible.
Best Regards,
Ville Seppänen
Tieto Corporation
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
Hi,
as a part of our Google Summer of Code Project to cleanup osc [1] our
first task was to define a new commandline user interface for osc.
The current user interface is quite "inconsistent" (with regard to
the expected arguments for different commands) and has some other
"flaws".
Here are some examples to show some flaws of the current user
interface:
* inconsistent ui:
- osc results project package --repo repo --arch arch
- osc rebuild project package repo arch
- osc build repo arch
- osc ls project package repo arch -b
- osc ls project package -r repo -a arch -b
- osc undelete project package_1 ... package_N
- osc rdelete project package_1
* counterintuitive commands:
- osc abortbuild project package
- osc abortbuild project package repo arch
- osc abortbuild (in a package working copy)
- osc abortbuild --repo repo --arch arch (in a package working copy)
- osc abortbuild repo arch (in a package working copy)
=> treats "repo" "arch" as "project" "package"
* "duplicated" commands:
- diff, rdiff
- buildlog, remotebuildlog, localbuildlog
- delete, rdelete, rremove
Additionally we support lots of commands and the output of
"osc --help"is quite long. In order to tackle this problem we decided
to introduce "groups" with subcommands, for instance:
attribute list
attribute create...
attribute set...
...
As a result we get rid of "god commands" (commands which supported
lots of different options for different things (like osc meta)) and
the new commands are easier to use because they support less arguments
and/or options (note: this doesn't mean we lose functionality - the
functionality is just moved to another command/command group).
The attached files are just a _proposal_ for a new commandline user
interface.
Some additional explanations:
The biggest change with regard to our current user interface is the
introduction of an url-like syntax:
For example:
osc ls api://project/package
instead of
osc ls project package
In this case "api" means that the request is issued to the default
apiurl (in most cases https://api.opensuse.org) which can be
configured in the ~/.oscrc.
To issue the "list" request to a different obs instance one can use:
osc ls https://api.somehost/project/package
or
osc ls alias://project/package
"alias" is an alias for this apiurl which can be configured in the
~/.oscrc.
If you see this url-like syntax for the first time you might think
that it makes things much more complicated (and even more to type)
but it is advantageous:
- in most cases it is obvious if a command is a remote command or
local working copy command
- this way we get rid of ambiguities:
Suppose we support the following command ("<foo>" indicate that
"foo" is an optional argument):
binaries get api://project/package <repo/arch>
binaries get <repo/arch> (if $PWD is a package working copy
the project and package arguments will be read from it)
Possible invocations are:
osc binaries get api://foo/bar standard/i586 # get all binaries
for this repo and arch
osc binaries get api://foo/bar # get all binaries for all repos
and all arches
# now suppose $PWD is a package working copy:
osc binaries get standard/i586 # get all binaries for this repo
and arch (project and package are read from the working copy)
osc binaries get api://foo/bar # gets all binaries for all repos
and all arches (project is "foo" and package is "bar")
In the latter invocation we're still in a package working copy
but ignore it and use the project and package arguments which
were specified.
Note: in this case a special (like the url-like) syntax is required
otherwise osc is unable to distinguish between a project/package and
repo/arch argument.
Once again this is just a _proposal_ - feedback is very welcome!
Marcus
[1] http://www.google-melange.com/gsoc/project/google/gsoc2011/mhuewe/13001
The attached ui.html.gz file can be used to navigate easier through
the list of commands (I just gzip'ed it to make mlmmj happy). The
attached ui.txt file is just generated via "w3m -dump ui.html".