[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#764567: ITP: obs-build -- Build DEB/RPM packages for various distributions inside a chroot



Hi Dimitri,

On  Do 09 Okt 2014 11:18:30 CEST, Dimitri John Ledkov wrote:

On 9 October 2014 08:43, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:
Hi Dimitri,


On  Do 09 Okt 2014 08:45:17 CEST, Dimitri John Ledkov wrote:

Hey,

On 9 October 2014 05:21, Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
wrote:

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

* Package name    : obs-build
  Version         : Git snapshot (every commit is a release)
  Upstream Author : Michael Schroeder (https://github.com/mlschroe)
* URL             : https://github.com/openSUSE/obs-build
* License         : GPL
  Programming Lang: Perl
  Description     : Build DEB/RPM packages for various distributions
inside a chroot

 OBS Build creates chroots and builds DEB/RPM packages for various
 Linux distributions. In Debian, this package fills a gap: it allows one
to
 build packages for the openSUSE/SLES distributions on Debian system.
 .
 Its only task is to reliably populate a chroot and attempt to build
 a package in that chroot. It is used by the Open Build System provided
 by SUSE, but can also be use as a standalone tool.
 .
 Optionally, builds can take place in KVM or XEN instance.


I think we had a mid-air collision:
https://ftp-master.debian.org/new/obs-build_20140918-1.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762949

I'm happy to co-maintain this package.


Yeah. I saw Adams mail early this morning.

I have the package nearly ready... Do you have anything packaged, yet? Or
shall I just add you to Uploaders: (with what mail address)?

I plan to push the packaging Git to collab-maint (or have you already
provided a packaging repo there?)


It's in the new queue.

Ah... ok... (damn that I did not notice...).

I use a combination of git-dpm & dgit. Which although useful, has
quilt noise committed as patches. (Maybe I should use stand-alone
branch for dgit/quilt noise).

You should be able to fetch it with:
$ dgit clone obs-build

Or I've now pushed a "normal" git master branch thus it's
visiable/clonable with git itself as well:
http://anonscm.debian.org/cgit/dgit-repos/repos/obs-build.git/

Ok. Thanks. Just did some reading of the debian/ folder.

I also pushed my latest changes to collab-maint/obs-build.git so you can introspect them.

In terms of patches, I have:
Use obs-build namespace, similar to your patch.
http://anonscm.debian.org/cgit/dgit-repos/repos/obs-build.git/tree/debian/patches/0001-Use-obs-build-in-locations-and-executable-names-inst.patch

I fixed & submitted upstream a bug with createzypp repository script.
http://anonscm.debian.org/cgit/dgit-repos/repos/obs-build.git/tree/debian/patches/0002-Fix-Build-Zypp-parsecfg-expected-full-config-file-na.patch


I do not move project configurations to /etc, as I don't think that's
right. Released distribution configurations should be frozen, to have
reproducible builds locally.

Ok. That sounds reasonable.

Custom/non-upstream distro configs should either be patched/applied in
the Debian package, packaged separately and install into same config
location, or passed to obs-build via command-line option.
We really don't want people to modify build configuration files for
volatile distribution (e.g. Factory, Rawhide, Sid, etc) and then never
get upgraded when those change, due to how config-files are handled.

Ok. Agreeing on that.

Maybe it makes sense to patch obs to support multiple locations? E.g.
/etc/obs-build/configs and /usr/lib/obs-build/configs?

That surely is an option.

What concerns me most about your upload is the version number.

I understand that there are tags on the openSUSE/obs-build.git. I used them as well till yesterday. However, I had an intensive chat with one of the upstream authors (Michael Schroeder, from SUSE) yesterday. Unfortunately in German, so copy+pasting makes no sense here.

About the tags on the Git he said: those tags are actually obs-server tags (not obs-build). The obs-server devs tagged obs-build with obs-server versions, so that they know what obs-build version / Git commit hash was used with what obs-server version.

About obs-build, he said: every commit is a release. So basically, we should use the version date. With upstream I came to the conclustion that the best version number would be 0~git<date>.<build-on-that-day>.<commit-hash>-<debrevision>.

So, the question is, if you are open do re-upload obs-build. If so, we should merge our packaging efforts (I think) and get several other things going (e.g. the initvm.c tool, tests, etc.).

Also, I could not really find that all files are licensed GPL-2+. I just asked upstream to do that today [1].

Actually, some files [2] are licensed as GPL-3+, so your copyright file is not up-to-date anymore for a latest Git snapshot (which is irrelevant for code older than today's snapshot, of course).

Mike

[1] https://github.com/openSUSE/obs-build/commit/fbb353690da2e4eeca0661e0e8f5f1141bee41ce [2] https://github.com/openSUSE/obs-build/commit/dcfcf896cd913c8f2c067ef97ce5176a5358e5d0

--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

Attachment: pgphBuoya_Ri7.pgp
Description: Digitale PGP-Signatur


Reply to: