[opensuse-buildservice] newby questions
hi, 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 b) adding the same distribution twice by accident gives an sql error. maybe you want to add code to does that check of handle the mistake more graceful. c) ubuntu edgy might be nice, so packages for the development distribution can be created too. (ok, more of a feature request :) 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. 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. 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? 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? 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 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). h) are there any plans to add the metadata e.g. for debian package pools? (dist/ directory, "Package" files etc.)? thanks for your help! Regards, Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Wed, 20 Sep 2006, 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
Are you talking about adding build targets? Originally all targets were shown, but with the growing number of project that list is geeting really complicated for users to work with.
b) adding the same distribution twice by accident gives an sql error. maybe you want to add code to does that check of handle the mistake more graceful.
=> please file a bug report -> http://bugs.openSUSE.org/ (product: openSUSE.org, component: Build Service something ;))
c) ubuntu edgy might be nice, so packages for the development distribution can be created too. (ok, more of a feature request :)
=> Adrian, mls?
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?
Right -- propose one, get the "approval" and create it yourself :)
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).
Mh, I guess that falls into some gray area -- Jürgen?
h) are there any plans to add the metadata e.g. for debian package pools? (dist/ directory, "Package" files etc.)?
AFAIK we are already creating apt metadata (Packages / Packages.gz files). Regards Christoph
Christoph Thiel wrote:
a) on the web page - why no add all for adding all distributions? would simplify it for most users
Are you talking about adding build targets? Originally all targets were shown, but with the growing number of project that list is geeting really complicated for users to work with.
sorry, yes, I meant build targets. I wonder why distributions are manually picked, not picked per project, and architecture is not picked either. well "all" works fine for me, and a single button to get "all" would have saved me a few clicks. but since it is only a thing I need to setup once as far as I know, it is ok. only a minor notice, this looks strange. or maybe change it into a page with checkboxes, so I can change it easily and submit with a single click? java script could then be used for macros like "select all" and "deselect all".
b) adding the same distribution twice by accident gives an sql error. maybe you want to add code to does that check of handle the mistake more graceful.
=> please file a bug report -> http://bugs.openSUSE.org/ (product: openSUSE.org, component: Build Service something ;))
ok, done.
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?
Right -- propose one, get the "approval" and create it yourself :)
ok, thanks.
h) are there any plans to add the metadata e.g. for debian package pools? (dist/ directory, "Package" files etc.)?
AFAIK we are already creating apt metadata (Packages / Packages.gz files).
ah, great. thanks a lot! Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
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? darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (3)
-
Andreas Jellinghaus -
Christoph Thiel -
Marcus Rueckert