Re: Bug#764567: ITP: obs-build -- Build DEB/RPM packages for various distributions inside a chroot
On 9 October 2014 10:42, Mike Gabriel <email@example.com> wrote:
> Hi Dimitri,
> On Do 09 Okt 2014 11:18:30 CEST, Dimitri John Ledkov wrote:
>> On 9 October 2014 08:43, Mike Gabriel <firstname.lastname@example.org>
>>> Hi Dimitri,
>>> On Do 09 Okt 2014 08:45:17 CEST, Dimitri John Ledkov wrote:
>>>> On 9 October 2014 05:21, Mike Gabriel <email@example.com>
>>>>> Package: wnpp
>>>>> Severity: wishlist
>>>>> Owner: Mike Gabriel <firstname.lastname@example.org>
>>>>> * 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
>>>>> 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:
>>>> 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:
> 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.
>> I fixed & submitted upstream a bug with createzypp repository script.
>> 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.
Yeah, I am aware of the crazy version numbering. So I based my version
numbers, on the version numbers that are published and used by
openSUSE itself in the openSUSE:Tools repository.
Which is where they package up daily git snapshot when a "release" happens.
So At the moment, I have exact same version as the upstream "releases"
are in the openSUSE:Tools repository. Why should version numbers
diverge from what's used in openSUSE and upstream?
Ich kann nur ein bistchen Deutsch sprechen.... I did request tags for
matching builds to be pushed into the repository, but it doesn't look
like github issues are being monitored:
> 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
> 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 .
I went by the license information used by OBS packagers in
openSUSE:Tools repository which states GPL-2+. More explicit licensing
info would be appreciated in the repository itself. Thanks for asking
and getting that changed.
Do i need to join irc and ping adrian to get this reviewed/merged
> Actually, some files  are licensed as GPL-3+, so your copyright file is
No, it got changed to "2 or 3", but no later. Given that some other
files are GPL-2-only, it seems like overall it's GPL-2-only.
> not up-to-date anymore for a latest Git snapshot (which is irrelevant for
> code older than today's snapshot, of course).