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:
pgp5d9SxIbx9p.pgp
Description: Digitale PGP-Signatur