Mailinglist Archive: opensuse-buildservice (252 mails)

< Previous Next >
Re: [opensuse-buildservice] newby questions
  • From: Marcus Rueckert <mrueckert@xxxxxxx>
  • Date: Thu, 21 Sep 2006 00:08:22 +0200
  • Message-id: <20060920220822.GT30353@xxxxxxx>
On 2006-09-20 21:46:03 +0200, Andreas Jellinghaus wrote:
> as a real newby I have lots of questions, maybe you can answer some of
> these?
> a) on the web page - why no add all for adding all distributions? would
> simplify it for most users

this would be stupid. as any other project repository can be a build target.

it might be useful to add a button "common base distros" which might add
all suse distros + mandriva + fedora + debian + ubuntu.
maybe more fine grained like:
'add all suse distros'
'add all debian based distros'
'add all fedora distros'

something along that line.

> d) is there a code name based selection system for building packages?
> e.g. it would be nice if I could upload *.diff.gz.sarge
> *.diff.gz.dapper *.diff.gz.etch and *.diff.gz.edgy with slightly
> different content for debian sarge/etch and ubuntu dapper and edgy.
> same again for rpm based distributions - while it might be a nice
> long term project to look in depth what distributions does what changes
> and why and how to merge them, as short term project it might be much
> nicer to edit the spec files, upload a new version of a package and
> get rebuilds without much work.

i am still not sure whether this is a good idea or not. atm i would say
... not a good idea. as the build service is not meant for that
branching packages into distributions. i will think a bit more about it.
stay tuned. :) (disclaimer my oppinion is not authoritive.)

> e) versioning updates: is there any automatic in place that will update
> the versions e.g. in spec files and debian changelog files? if I upload
> mysoft 0.a.b+1, would I need to edit all spec files and diff.gz to
> manualy enter the new version or does some automatic this for me?
> same with revisions, if dsc files or something is changed.

oscupstream might be used for that. in general the idea is to have a
upstream integration. so you can just trigger a version update and it
will grab the new tarball or even a checkout from a SCM and update
everything. this is pretty easy for rpm spec files. but for debian this
gets a bit trouble some. the package changelog is normal part of the
patch that adds the debian/ subdir. so it would be a -> unpack -> apply
patch -> fix changelog -> rediff -> cleanup cycle needed. but we will
see what comes out of the changelog integration feature here.

to be discussed.

> f) debian builds: debian has this habbit of renaming
> mypackage-0.a.b.tar.gz to mypackage_0.a.b.orig.tar.gz. do I need to
> upload the same file under both names, or will you take care of this
> with a symlink or rename for debian builds?

yes. you need to upload both tarballs.

> g) If I want to jointly develop packages with a group of people, we need
> a non home: repository, right? and I need to ask here for approval
> before creating one?

you can add those users to your home project too. the home project is a
project like any other in that regard.

> h) if I guesses correctly at g) I'd like to have either "smartcard:"
> or "opensc-project:" or "opensc:" for opensc, openct, libp11,
> engine_pkcs11, pam-p11, pam_pkcs11, gtkcard, pcsc-lite, libccid,
> opensc-java and friends

security:smartcards would be my idea. so we can put other smartcard
related projects there too.

> i) opensuse buildservice is restricted to open source software as far
> as I know. what about java addons, are they ok? specifically, if java
> forces the author to sign them and to keep the signature key private?
> at opensc-project we have a new project "opensc-java" which is a java
> crypto service (with smart cards via opensc as backend), and we needed
> to go through all the hassle of signing it etc. so while the source code
> is open source, it won't work with java unless signed. so our "build"
> process would be more like uploading the binaries and only moving files
> into place (or building from source, but the result wouldn't work at
> all, as we need to keep the signing key private).

as it is a good old habit of java to ship all kind of jar files
intree. you could just ship the jar file as source and than just package
it into opensc-java. as it should basically work everywhere right? or
does the java part have JNI stuff?


openSUSE - SUSE Linux is my linux
openSUSE is good for you
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >