Debian Bug report logs - #772823
ITP: kimchi -- HTML5 based management tool for KVM.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Frederic Bonnard <frediz@linux.vnet.ibm.com>

To: submit@bugs.debian.org

Subject: ITP: kimchi -- HTML5 based management tool for KVM.

Date: Thu, 11 Dec 2014 14:29:16 +0100

Package: wnpp
Severity: wishlist

Description: Kimchi is an HTML5 based management tool for KVM. It is designed
to make it as easy as possible to get started with KVM and create your first
guest.
Kimchi runs as a daemon on the hypervisor host. It manages KVM guests through
libvirt. The management interface is accessed over the web using a browser that
supports HTML5.

License: LGPL-3.0+ and Apache-2.0
Copyright: 2013-2014 International Business Machines Corporation and others.
URL: https://github.com/kimchi-project/kimchi

Message #10 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Frederic Bonnard <frediz@linux.vnet.ibm.com>

To: 772823@bugs.debian.org

Subject: Packaging proposal

Date: Thu, 11 Dec 2014 15:29:07 +0100

[Message part 1 (text/plain, inline)]

Here is at first draft for kimchi packaging.

Fred

[kimchi_1.3.0.orig.tar.gz (application/gzip, attachment)]

[kimchi_1.3.0-1.debian.tar.xz (application/x-xz, attachment)]

[kimchi_1.3.0-1.dsc (text/plain, attachment)]

Message #15 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Julien Goodwin <jgoodwin@studio442.com.au>

To: 772823@bugs.debian.org, Frederic Bonnard <frediz@linux.vnet.ibm.com>

Subject: Re: ITP: kimchi -- HTML5 baseITP: kimchi -- HTML5 based management tool for KVM.d management tool for KVM.

Date: Wed, 14 Jan 2015 17:15:34 +1300

[Message part 1 (text/plain, inline)]

Gave the proposed packages a try.

Couple of things:

1. It appears this package is missing a dependency on libvirt-bin

2. Please make use of nginx proxy optional (and drop dependency down to
recommends), I'm aware this will require changes to kimchi to add an option.

3. Websocksify listens on IPv4 only, this will be unreliable for people
who have both v4 & v6 in DNS, and break for any v6 only users.

[signature.asc (application/pgp-signature, attachment)]

Message #20 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Julien Goodwin <jgoodwin@studio442.com.au>

To: 772823@bugs.debian.org, Frederic Bonnard <frediz@linux.vnet.ibm.com>

Subject: Re: ITP: kimchi -- HTML5 baseITP: kimchi -- HTML5 based management tool for KVM.d management tool for KVM.

Date: Sat, 17 Jan 2015 15:04:33 +1300

[Message part 1 (text/plain, inline)]

I filed an upstream bug (#570) to make nginx optional as I mentioned in
my last mail.

Missing a short description for the package, the first line of the long
description is getting used.

I hit the gettext issue mentioned in:
http://lists.ovirt.org/pipermail/kimchi-devel/2014-November/008801.html

However, this appears to be fixed at head.

I don't see a pam service being created for kimchi, nor an obvious way
to restrict who has rights to login. (Upstream bug #571 filed)

A sensible default would probably be members of the libvirt group.

/robots.txt is missing.  (Patch sent)

A new upstream version (1.4) has been released, so would like to see a
package update.

[signature.asc (application/pgp-signature, attachment)]

Message #27 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Frederic Bonnard <frediz@linux.vnet.ibm.com>

To: Julien Goodwin <jgoodwin@studio442.com.au>

Cc: 772823@bugs.debian.org

Subject: Re: ITP: kimchi -- HTML5 baseITP: kimchi -- HTML5 based management tool for KVM.d management tool for KVM.

Date: Mon, 19 Jan 2015 11:49:13 +0100

Thank you Julien for looking at this and already filing bugs upstream.
I've uploaded a new package for 1.4.0 with a batch of small fixes (issues from
you, misc I found and from lintian) :
http://mentors.debian.net/package/kimchi

About what you pointed out that has no bug opened yet, I forwarded that to
a kimchi dev (maybe I should have done that publicly on the mailing list).
Here is what I gathered here and forwarded :
---
[X] "1. It appears this package is missing a dependency on libvirt-bin" : updated in
    the updated package 1.4.0 that I did
[ ] "2. Please make use of nginx proxy optional (and drop dependency down to
    recommends), I'm aware this will require changes to kimchi to add an option" : bug #570 reported upstream
[ ] "3. Websocksify listens on IPv4 only, this will be unreliable for people
    who have both v4 & v6 in DNS, and break for any v6 only users" : no bug so far : I checked
    kimchi for configuration options but that seems to be changed deeper. Should I
    file a bug for this one ?
[X] "4. Missing a short description for the package, the first line of the long
    description is getting used." : updated in my 1.4.0 packaging
[X] "5. I hit the gettext issue mentioned in:
    http://lists.ovirt.org/pipermail/kimchi-devel/2014-November/008801.html
    However, this appears to be fixed at head." : OK
[ ] "6. I don't see a pam service being created for kimchi, nor an obvious way
    to restrict who has rights to login. (Upstream bug #571 filed)
    A sensible default would probably be members of the libvirt group."
    I need to look into that. Actually in our lab we avoided use of kimchi because we
    felt it was not well suited at the moment for fine grained access rights.
    If I'm right, a user that can login to the machine (pam) as access to kimchi and
    also access to firmware updating tabs. Did we miss something on that ?
    What's your opinion on Julien's point ?
[X] "8. /robots.txt is missing.  (Patch sent)"
[X] "9. A new upstream version (1.4) has been released, so would like to see a
    package update."
---

About kimchi login rights, atm, authentication relies on system login with
pam, meaning that any user on the system has access to kimchi. I'm going to
look into that on the packaging side while waiting for kimchi devs opinion.

Fred.

On Sat, 17 Jan 2015 15:04:33 +1300, Julien Goodwin <jgoodwin@studio442.com.au> wrote:
> I filed an upstream bug (#570) to make nginx optional as I mentioned in
> my last mail.
> 
> Missing a short description for the package, the first line of the long
> description is getting used.
> 
> I hit the gettext issue mentioned in:
> http://lists.ovirt.org/pipermail/kimchi-devel/2014-November/008801.html
> 
> However, this appears to be fixed at head.
> 
> I don't see a pam service being created for kimchi, nor an obvious way
> to restrict who has rights to login. (Upstream bug #571 filed)
> 
> A sensible default would probably be members of the libvirt group.
> 
> /robots.txt is missing.  (Patch sent)
> 
> A new upstream version (1.4) has been released, so would like to see a
> package update.
> 
> 

Message #32 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Julien Goodwin <jgoodwin@studio442.com.au>

To: Frederic Bonnard <frediz@linux.vnet.ibm.com>

Cc: 772823@bugs.debian.org

Subject: Re: ITP: kimchi -- HTML5 baseITP: kimchi -- HTML5 based management tool for KVM.d management tool for KVM.

Date: Thu, 22 Jan 2015 12:32:27 +1100

[Message part 1 (text/plain, inline)]

On 19/01/15 21:49, Frederic Bonnard wrote:
> Thank you Julien for looking at this and already filing bugs upstream.
> I've uploaded a new package for 1.4.0 with a batch of small fixes (issues from
> you, misc I found and from lintian) :
> http://mentors.debian.net/package/kimchi

That's a nice set of improvements. My only new issues are:

1. For some reason kimchid didn't start on boot, systemd decided not to
load it. This may well be a problem on my machine, not a generic one,
but perhaps worth testing.

2. The dependency on qemu-system is fairly broad, unless kimchi actually
supports foreign architecture VMs then depending on the local version
per-arch would be nice.

...
> [ ] "3. Websocksify listens on IPv4 only, this will be unreliable for people
>     who have both v4 & v6 in DNS, and break for any v6 only users" : no bug so far : I checked
>     kimchi for configuration options but that seems to be changed deeper. Should I
>     file a bug for this one ?

With 1.4 websockify is now an external dependency so it's now a bug in
it (although fixed upstream, but there's not been a release, I've filed
debian bug #??? for this).

> [ ] "6. I don't see a pam service being created for kimchi, nor an obvious way
>     to restrict who has rights to login. (Upstream bug #571 filed)
>     A sensible default would probably be members of the libvirt group."
>     I need to look into that. Actually in our lab we avoided use of kimchi because we
>     felt it was not well suited at the moment for fine grained access rights.
>     If I'm right, a user that can login to the machine (pam) as access to kimchi and
>     also access to firmware updating tabs. Did we miss something on that ?
>     What's your opinion on Julien's point ?

Per debian convention kimchi should get its own service, even if not
generically. My plan is to allow the use of external auth which solves
my case.

> [X] "8. /robots.txt is missing.  (Patch sent)"
This is now merged for the next release.

[signature.asc (application/pgp-signature, attachment)]

Message #37 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Frederic Bonnard <frediz@linux.vnet.ibm.com>

To: Julien Goodwin <jgoodwin@studio442.com.au>

Cc: 772823@bugs.debian.org

Subject: Re: ITP: kimchi -- HTML5 baseITP: kimchi -- HTML5 based management tool for KVM.d management tool for KVM.

Date: Thu, 22 Jan 2015 10:52:40 +0100

I updated the package with some of your points :

> 1. For some reason kimchid didn't start on boot, systemd decided not to
> load it. This may well be a problem on my machine, not a generic one,
> but perhaps worth testing.

Got the same :)
I added --with systemd so that postinstall script does the job. Looks good now.

> 2. The dependency on qemu-system is fairly broad, unless kimchi actually
> supports foreign architecture VMs then depending on the local version
> per-arch would be nice.

I changed this, now we should drag only the current arch qemu-system.

> ...
> > [ ] "3. Websocksify listens on IPv4 only, this will be unreliable for people
> >     who have both v4 & v6 in DNS, and break for any v6 only users" : no bug so far : I checked
> >     kimchi for configuration options but that seems to be changed deeper. Should I
> >     file a bug for this one ?
> 
> With 1.4 websockify is now an external dependency so it's now a bug in
> it (although fixed upstream, but there's not been a release, I've filed
> debian bug #??? for this).

For the record here : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775963

Message #42 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Frederic Bonnard <frediz@linux.vnet.ibm.com>

To: Julien Goodwin <jgoodwin@studio442.com.au>

Cc: 772823@bugs.debian.org

Subject: Re: ITP: kimchi -- HTML5 baseITP: kimchi -- HTML5 based management tool for KVM.d management tool for KVM.

Date: Tue, 10 Feb 2015 12:05:36 +0100

Hi Julien,
In the latest packaging draft, I fixed a few lintians. For some of which
I opened upstream ; for reference :
- I wrote a manpage which I submitted upstream : https://github.com/kimchi-project/kimchi/issues/587
- we would need non minified javascript : https://github.com/kimchi-project/kimchi/issues/588 but
  overriden for now.

Also I added a pam service for kimchi, so that only root and libvirt users can
login to kimchi. It seems to work as I wanted, but I'm not a pam export so if
anybody can review that :)

F.

Message #47 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Julien Goodwin <jgoodwin@studio442.com.au>

To: 772823@bugs.debian.org, frediz@linux.vnet.ibm.com

Subject: Re: ITP: kimchi -- HTML5 baseITP: kimchi -- HTML5 based management tool for KVM.d management tool for KVM.

Date: Sun, 22 Mar 2015 23:37:44 +1100

[Message part 1 (text/plain, inline)]

One more missing dep that slipped through, "novnc" is missing from the
package deps.

[signature.asc (application/pgp-signature, attachment)]

Message #52 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Frederic Bonnard <frediz@linux.vnet.ibm.com>

To: Julien Goodwin <jgoodwin@studio442.com.au>

Cc: 772823@bugs.debian.org

Subject: Re: ITP: kimchi -- HTML5 baseITP: kimchi -- HTML5 based management tool for KVM.d management tool for KVM.

Date: Wed, 25 Mar 2015 11:01:19 +0100

Hi Julien,
thanks for this one. I added it to the lastest packaging I pushed on
mentors.debian.net .
I also added a patch that I sent for review on @kimchi-devel which should make
possible to use http://server/kimchi with a sub-site configuration file in
nginx based on commentis of Robie Basak to comply better with :
http://webapps-common.alioth.debian.org/draft/html/ch-httpd.html

F.


On Sun, 22 Mar 2015 23:37:44 +1100, Julien Goodwin <jgoodwin@studio442.com.au> wrote:
> One more missing dep that slipped through, "novnc" is missing from the
> package deps.
> 

Message #57 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Julien Goodwin <jgoodwin@studio442.com.au>

To: Frederic Bonnard <frediz@linux.vnet.ibm.com>

Cc: 772823@bugs.debian.org

Subject: Re: ITP: kimchi -- HTML5 baseITP: kimchi -- HTML5 based management tool for KVM.d management tool for KVM.

Date: Thu, 26 Mar 2015 00:35:09 +1100

[Message part 1 (text/plain, inline)]

On 25/03/15 21:01, Frederic Bonnard wrote:
> Hi Julien,
> thanks for this one. I added it to the lastest packaging I pushed on
> mentors.debian.net .
> I also added a patch that I sent for review on @kimchi-devel which should make
> possible to use http://server/kimchi with a sub-site configuration file in
> nginx based on commentis of Robie Basak to comply better with :
> http://webapps-common.alioth.debian.org/draft/html/ch-httpd.html

Yep, been seeing those come through.

> On Sun, 22 Mar 2015 23:37:44 +1100, Julien Goodwin <jgoodwin@studio442.com.au> wrote:
>> One more missing dep that slipped through, "novnc" is missing from the
>> package deps.
>>
> 

[signature.asc (application/pgp-signature, attachment)]

Message #62 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Frederic Bonnard <frediz@linux.vnet.ibm.com>

To: 772823@bugs.debian.org

Subject: Re: Bug#772823: Info received (ITP: kimchi -- HTML5 baseITP: kimchi -- HTML5 based management tool for KVM.d management tool for KVM.)

Date: Thu, 7 May 2015 17:09:25 +0200

I updated a bit the packaging to latest version 1.4.1 packaged, removed the patch for
ppc64el. Kept the others though 1 got applied upstream (fix-relative-base-url)
but it's not in 1.4.1 tarball.
I fixed 2 small lintians and add 1 configuration file example for nginx and
some instructions in the README.Debian.
It's on mentors.

Fred

Message #67 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Frederic Bonnard <frediz@linux.vnet.ibm.com>

To: 772823@bugs.debian.org

Subject: Re: Bug#772823: Info received (ITP: kimchi -- HTML5 baseITP: kimchi -- HTML5 based management tool for KVM.d management tool for KVM.)

Date: Mon, 29 Jun 2015 17:14:12 +0200

Packaging updated to kimchi 1.5.0.
More lintian clean up.
Installation should now setup nginx properly to have kimchi directly working
on https://host/kimchi/
Available on mentors.net

F.

Message #72 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Robie Basak <robie.basak@ubuntu.com>

To: 772823@bugs.debian.org

Cc: Frederic Bonnard <frediz@linux.vnet.ibm.com>

Subject: Review of 1.5.0-1 from mentors.debian.net

Date: Tue, 18 Aug 2015 19:07:54 +0100

[Message part 1 (text/plain, inline)]

Hi,

I've reviewed 1.5.0-1 from mentors.debian.net. Note that I am a DM and
not a DD so cannot upload this directly to Debian. My review was with my
Ubuntu core dev hat as I can upload to Ubuntu directly and would like to
do this by Ubuntu's feature freeze on Thursday, hopefully with a
concurrent request for sponsorship for a Debian upload.

I've only looked at the source and binary packages wrt. interactions
with other packages and potential upgrade path issues. I've not actually
tested the package - I assume it works.

Review notes (blockers):

Blocker for upload as there might be upgrade path issues later
otherwise: ln -sf /usr/share/doc/kimchi/examples/kimchi.sub.nginx
/etc/nginx/sites-available/kimchi (from postinst) will break policy
https://www.debian.org/doc/debian-policy/ch-docs.html#s12.3 "Packages
must not require the existence of any files in /usr/share/doc/ in order
to function" and also the user expectation that a file in /etc can just
be modified and normally conffile handling will occur. I suggest that
you just install (duplicate the example in
/usr/share/doc/kimchi/examples if you wish) to /etc as a regular
conffile (so putting it in kimchi.install will do) instead.

With just this fixed I will be happy to upload the package to Ubuntu and
recommend to a DD that it is suitable for Debian (though it will still
need the DD to review).


Review notes (minor):

The remaining issues I don't think need to be blockers for upload. These
are just observations as I went through; I haven't thought about them in
detail and for some of them the resolution may be that no action is
required:

package-contains-broken-symlink might be worth a lintian override as the
symlink gets resolved when dependencies are fulfilled so is a false
positive.

I don't think the pedantic lintian warnings are an issue - if upstream
don't sign releases then you can't verify them and you're already
dealing with minified JS by minifying in the build and/or depending on
the jquery package as appropriate. It might be worth writing a note for
the Debian ftpmaster and/or Ubuntu archive admin explaining it though,
perhaps in README.source?

The postinst and postrm restart kimchid and nginx daemons. Does this
intefere with dh_installinit #DEBHELPER# snippets at all? I see in the
binary deb after build that it looks like it'll cause kimchi to be
restarted twice on future upgrade, for example. I'm not sure how this
could be improved though due to the need to restart nginx from kimchi's
postinst. Maybe systemd might have some capability in this area?

override_dh_auto_test is used to skip tests. It would be nice to be able
to run any upstream tests at package build time, and/or have dep8 tests
that can run upstream tests, but I appreciate that this may be difficult
due to virt requirements.

Upstream currently generate custom DH parameters at build time. This
will not help with uniqueness in binary distributions like Debian and
Ubuntu and also break reproducible builds. Instead this could be done at
install time in the postinst, though that might result in entropy
issues, or we could ship well-known parameters instead, or by some kind
of user choice between the two. But I am advised by a colleague in
Ubuntu security team that this isn't an immediate security issue as-is.

I see debian/kimchid.init but this doesn't appear in the built binary.
Should this be fixed or removed? Shipping just a systemd unit file
is fine for Ubuntu; AIUI in Debian it's friendly to maintain it for
users who choose a different init system.

Maybe remove /usr/share/kimchi/doc/kimchid.8 as it is shipped in
/usr/share/man/man8/kimchid.8.gz?

Should /usr/lib/python2.7/dist-packages/kimchi/API.json be in
/usr/share/kimchi instead? I'm not really sure about this one. It does
seem unusual to have it where it is though.

[signature.asc (application/pgp-signature, inline)]

Message #77 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Gianfranco Costamagna <costamagnagianfranco@yahoo.it>

To: "Thierry Fauck ( thierry @ linux.vnet.ibm.com )" <thierry@linux.vnet.ibm.com>, "debian-mentors@lists.debian.org" <debian-mentors@lists.debian.org>

Cc: "brenohl@br.ibm.com" <brenohl@br.ibm.com>, "frederic@fr.ibm.com" <frederic@fr.ibm.com>, "772823@bugs.debian.org" <772823@bugs.debian.org>

Subject: Re: Looking for a mentor for a couple of projects

Date: Wed, 19 Aug 2015 17:59:50 +0000 (UTC)

Kimiki review:

please fix all the above (message #72 of bug 772823)



d/changelog: no need to put your name into []
when you are the only one who worked on the package (and the signature
is your)

d/rules: as said skipping tests is usually bad, please enable them if possible

d/copyright: "multiple-licenses" looks bad to me.

Is something like "you can choose your favourite one?"

so please say something like LGPL-3 or MIT or XFree86

I don't think the same file can be licensed under the tree licenses without breaking
the law. (but IANAL)



tests/* seems to be under LGPL-2.1+
(and also something under plugins and somewhere else, looking by a grep of the License keyword

e.g.
./plugins/sample/i18n.py:# version 2.1 of the License, or (at your option) any later version.
./plugins/sample/ui/Makefile.am:# version 2.1 of the License, or (at your option) any later version.
./plugins/sample/ui/config/Makefile.am:# version 2.1 of the License, or (at your option) any later version.
./plugins/sample/ui/pages/Makefile.am:# version 2.1 of the License, or (at your option) any later version.
./plugins/sample/ui/js/Makefile.am:# version 2.1 of the License, or (at your option) any later version.
./plugins/sample/__init__.py:# version 2.1 of the License, or (at your option) any later version.


also grepping by copyright makes some result appear not listed in copyright file.


please check if the license is really LGPL-3 and not LGPL-3+

patches needs a Description: field (and they are not dep-3)


the other stuff looks good, please ping when you have done the above,
and I'll do some testing on a built package.

(btw would be nice to have a setup.py and install_requires, do let
python:Depends pick up the python dependencies automagically)

cheers,

Gianfranco

Il Mercoledì 19 Agosto 2015 17:37, "Thierry Fauck ( thierry @ linux.vnet.ibm.com )" <thierry@linux.vnet.ibm.com> ha scritto:



Dear mentors, We are looking for a sponsor for a couple of packages submited by Frederic Bonnard     kimchi (bug #772823) sphde  (bug # 787491)
see: https://mentors.debian.net/packages/uploader/frediz%40linux.vnet.ibm.com 
Feel free to contact me at the conf or Frederic by mail.

Thanks



-- 
THF - Thierry Fauck (thierry@linux.vnet.ibm.com)
Debian Contributor

Message #82 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Frederic Bonnard <frediz@linux.vnet.ibm.com>

To: Robie Basak <robie.basak@ubuntu.com>

Cc: 772823@bugs.debian.org

Subject: Re: Review of 1.5.0-1 from mentors.debian.net

Date: Fri, 28 Aug 2015 13:35:05 +0200

Hi,

I tried to improve things, and for the ones that needs more time or that are
more nice-to-haves, I've put a notice in the README.source as advised by Robie.

> Blocker for upload as there might be upgrade path issues later
> otherwise: ln -sf /usr/share/doc/kimchi/examples/kimchi.sub.nginx
> /etc/nginx/sites-available/kimchi (from postinst) will break policy
> https://www.debian.org/doc/debian-policy/ch-docs.html#s12.3 "Packages
> must not require the existence of any files in /usr/share/doc/ in order
> to function" and also the user expectation that a file in /etc can just
> be modified and normally conffile handling will occur. I suggest that
> you just install (duplicate the example in
> /usr/share/doc/kimchi/examples if you wish) to /etc as a regular
> conffile (so putting it in kimchi.install will do) instead.

I moved the copy of kimchi.sub.nginx to debian/rules.
I kept this in kimchi.postinst though :
ln -sf /etc/nginx/sites-available/kimchi /etc/nginx/sites-enabled/kimchi

> With just this fixed I will be happy to upload the package to Ubuntu and
> recommend to a DD that it is suitable for Debian (though it will still
> need the DD to review).
>
> package-contains-broken-symlink might be worth a lintian override as the
> symlink gets resolved when dependencies are fulfilled so is a false
> positive.

done

> I don't think the pedantic lintian warnings are an issue - if upstream
> don't sign releases then you can't verify them and you're already
> dealing with minified JS by minifying in the build and/or depending on
> the jquery package as appropriate. It might be worth writing a note for
> the Debian ftpmaster and/or Ubuntu archive admin explaining it though,
> perhaps in README.source?

done

> The postinst and postrm restart kimchid and nginx daemons. Does this
> intefere with dh_installinit #DEBHELPER# snippets at all? I see in the
> binary deb after build that it looks like it'll cause kimchi to be
> restarted twice on future upgrade, for example. I'm not sure how this
> could be improved though due to the need to restart nginx from kimchi's
> postinst. Maybe systemd might have some capability in this area?

This needs more investigation on my side or maybe other reviewers here can have
more knowledge on this. The point is :
- kimchi generate certificate at first run
- nginx needs to be restarted to take those into account
Added to README.source
Maybe with systemd we can do something smarter but the support of sysV init
scripts in debian won't help on solving the problem in a global manner.

> override_dh_auto_test is used to skip tests. It would be nice to be able
> to run any upstream tests at package build time, and/or have dep8 tests
> that can run upstream tests, but I appreciate that this may be difficult
> due to virt requirements.

This can not be simply done indeed as the tests create VMs. I've added this to the
README.source and will check with upstream, what can be done.

> Upstream currently generate custom DH parameters at build time. This
> will not help with uniqueness in binary distributions like Debian and
> Ubuntu and also break reproducible builds. Instead this could be done at
> install time in the postinst, though that might result in entropy
> issues, or we could ship well-known parameters instead, or by some kind
> of user choice between the two. But I am advised by a colleague in
> Ubuntu security team that this isn't an immediate security issue as-is.

ok ; added this to README.source

> I see debian/kimchid.init but this doesn't appear in the built binary.
> Should this be fixed or removed? Shipping just a systemd unit file
> is fine for Ubuntu; AIUI in Debian it's friendly to maintain it for
> users who choose a different init system.

I renamed kimchid.init to kimchi.init so that it's taken into account.
I renamed the service file so that it matches "kimchi.service" else lintian
complains for having the init file and service file with diffferent package name.

> Maybe remove /usr/share/kimchi/doc/kimchid.8 as it is shipped in
> /usr/share/man/man8/kimchid.8.gz?

Added rm in d/rules

> Should /usr/lib/python2.7/dist-packages/kimchi/API.json be in
> /usr/share/kimchi instead? I'm not really sure about this one. It does
> seem unusual to have it where it is though.

As you told me after checking, it's ok there ; including here your discussion with Barry :
rbasak : barry: could you please advise if installing eg.
./usr/lib/python2.7/dist-packages/kimchi/plugins/ginger/API.json is acceptable
or if that should be in /usr/share/kimchi instead? It looks unusual to me so
I thought I'd check. This is review for a new package.
10:06 rbasak : barry(I'd normally expect to see only .py files in
/usr/lib/python2.7/dist-packages)
10:07 Barryr : basak: tl;dr: it's fine.  many python libraries do include data files in
their directory structure, and that works well with pkg_resources.  they can
use that api to find the data files easily.  it does seem odd that those data
files don't go in /usr/share but it's normal.  moving them is more trouble than
it's worth.  upstream we've talked about ways to put such data files elsewhere
but in a way that they're still easily found by they
13:27 Barry : rbasak: normal apis, but so far that hasn't gone anywhere.

Message #87 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Frederic Bonnard <frederic@fr.ibm.com>

To: Gianfranco Costamagna <costamagnagianfranco@yahoo.it>

Cc: "Thierry Fauck ( thierry @ linux.vnet.ibm.com )" <thierry@linux.vnet.ibm.com>, "debian-mentors@lists.debian.org" <debian-mentors@lists.debian.org>, "brenohl@br.ibm.com" <brenohl@br.ibm.com>, "772823@bugs.debian.org" <772823@bugs.debian.org>

Subject: Re: Looking for a mentor for a couple of projects

Date: Fri, 28 Aug 2015 18:29:49 +0200

Hi Gianfranco, and thank you for coming here to make a contribution :)
I'v not uploaded a new version with the modifications yet, but I have a few
questions below.

> please fix all the above (message #72 of bug 772823)

I did all that was doable in a reasonable time. As said before, for what need more
time and/or help from upstream, I've kept track of it in README.source

> d/changelog: no need to put your name into []
> when you are the only one who worked on the package (and the signature
> is your)

done, thanks

> d/rules: as said skipping tests is usually bad, please enable them if possible

Yes, we'll try to do something with upstream, but I couldn't do that in
a trivial way. As explained tests create VMs.
This is tracked in README.source though.

> d/copyright: "multiple-licenses" looks bad to me.
> 
> Is something like "you can choose your favourite one?"
> 
> so please say something like LGPL-3 or MIT or XFree86
> 
> I don't think the same file can be licensed under the tree licenses without breaking
> the law. (but IANAL)

Actually I based the licensing of that file on that same file :
http://sources.debian.net/src/spice-html5/0.1.4-1/debian/copyright/?hl=13#L13
I can ask the maintainer there if he knows more.

> tests/* seems to be under LGPL-2.1+
> (and also something under plugins and somewhere else, looking by a grep of the License keyword
> 
> e.g.
> ./plugins/sample/i18n.py:# version 2.1 of the License, or (at your option) any later version.
> ./plugins/sample/ui/Makefile.am:# version 2.1 of the License, or (at your option) any later version.
> ./plugins/sample/ui/config/Makefile.am:# version 2.1 of the License, or (at your option) any later version.
> ./plugins/sample/ui/pages/Makefile.am:# version 2.1 of the License, or (at your option) any later version.
> ./plugins/sample/ui/js/Makefile.am:# version 2.1 of the License, or (at your option) any later version.
> ./plugins/sample/__init__.py:# version 2.1 of the License, or (at your option) any later version.

I guess upstream didn't update the files. I'll sent a mail to them to ask.

> also grepping by copyright makes some result appear not listed in copyright file.

did you mean : ?

./m4/*.m4:dnl Copyright (C) 1996-2003, 2009-2010 Free Software Foundation,
./po/Makefile.in.in:# Copyright (C) 1995-1997, 2000-2007, 2009-2010 by Ulrich Drepper <drepper@gnu.ai.mit.edu>
./plugins/sample/po/Makefile.in.in:# Copyright (C) 1995-1997, 2000-2007, 2009-2010 by Ulrich Drepper <drepper@gnu.ai.mit.edu>
./config.rpath:#   Copyright 1996-2010 Free Software Foundation, Inc.
./INSTALL:Copyright (C) 1994-1996, 1999-2002, 2004-2011 Free Software Foundation,
./INSTALL:are permitted in any medium without royalty provided the copyright
./build-aux/config.rpath:#   Copyright 1996-2010 Free Software Foundation, Inc.
./build-aux/pkg-version:# Copyright 2008-2012 Red Hat, Inc.

not sure how to deal with those : they specify a copyright but no license
except things like "unlimited permission to copy and/or distribute it, with or
without modifications, as long as this notice is preserved."
So, does this means that they will fall under the license of the project
(LGPL-3) or are those small notices considered as a license by itself?

> please check if the license is really LGPL-3 and not LGPL-3+

COPYING specifies LGPL-3 ; do you mean people generally use LGPL-3+ and that
upstream may have done a typo ? I'll ask.

> patches needs a Description: field (and they are not dep-3)

will do

> the other stuff looks good, please ping when you have done the above,
> and I'll do some testing on a built package.
> 
> (btw would be nice to have a setup.py and install_requires, do let
> python:Depends pick up the python dependencies automagically)

Indeed! good suggestion given the number of python deps pulled and it seems to
change quite often.
I will ask for this too.

Fred

Message #92 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Gianfranco Costamagna <costamagnagianfranco@yahoo.it>

To: Frederic Bonnard <frederic@fr.ibm.com>

Cc: "Thierry Fauck ( thierry @ linux.vnet.ibm.com )" <thierry@linux.vnet.ibm.com>, "brenohl@br.ibm.com" <brenohl@br.ibm.com>, "772823@bugs.debian.org" <772823@bugs.debian.org>

Subject: Re: Looking for a mentor for a couple of projects

Date: Fri, 28 Aug 2015 16:53:14 +0000 (UTC)

Hi,




>
>
>I did all that was doable in a reasonable time. As said before, for what need more
>time and/or help from upstream, I've kept track of it in README.source


ok

>done, thanks


ok
>Yes, we'll try to do something with upstream, but I couldn't do that in
>a trivial way. As explained tests create VMs.
>This is tracked in README.source though.


that might be an issue :)
>Actually I based the licensing of that file on that same file :
>http://sources.debian.net/src/spice-html5/0.1.4-1/debian/copyright/?hl=13#L13
>I can ask the maintainer there if he knows more.


if other packages have the same license might be fine then, but please double check :)

>I guess upstream didn't update the files. I'll sent a mail to them to ask.


thanks


>./m4/*.m4:dnl Copyright (C) 1996-2003, 2009-2010 Free Software Foundation,
>./po/Makefile.in.in:# Copyright (C) 1995-1997, 2000-2007, 2009-2010 by Ulrich Drepper <drepper@gnu.ai.mit.edu>
>./plugins/sample/po/Makefile.in.in:# Copyright (C) 1995-1997, 2000-2007, 2009-2010 by Ulrich Drepper <drepper@gnu.ai.mit.edu>
>./config.rpath:#   Copyright 1996-2010 Free Software Foundation, Inc.
>./INSTALL:Copyright (C) 1994-1996, 1999-2002, 2004-2011 Free Software Foundation,
>./INSTALL:are permitted in any medium without royalty provided the copyright
>./build-aux/config.rpath:#   Copyright 1996-2010 Free Software Foundation, Inc.
>./build-aux/pkg-version:# Copyright 2008-2012 Red Hat, Inc.
>
>not sure how to deal with those : they specify a copyright but no license
>except things like "unlimited permission to copy and/or distribute it, with or
>without modifications, as long as this notice is preserved."
>So, does this means that they will fall under the license of the project
>(LGPL-3) or are those small notices considered as a license by itself?


yes, fine for them :)

>COPYING specifies LGPL-3 ; do you mean people generally use LGPL-3+ and that
>upstream may have done a typo ? I'll ask.


yes please, I usually see LGPL-3+, and it is a little bit more permissive (not
right now, but it might become in a future version)
>will do


thanks

>Indeed! good suggestion given the number of python deps pulled and it seems to
>change quite often.
>I will ask for this too.



thanks, unfortunately you still need to have them in build-dependencies, but not
in runtime-dependencies
(please check the DEBIAN/control in the binary package if everything went good)


and please tell somewhere the package name, because I forgot it
(and I'm too lazy to check)

cheers,

G.

Message #97 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Frederic Bonnard <frederic@fr.ibm.com>

To: Gianfranco Costamagna <costamagnagianfranco@yahoo.it>

Cc: "Thierry Fauck ( thierry @ linux.vnet.ibm.com )" <thierry@linux.vnet.ibm.com>, "brenohl@br.ibm.com" <brenohl@br.ibm.com>, "772823@bugs.debian.org" <772823@bugs.debian.org>

Subject: kimchi: looking for a mentor

Date: Fri, 28 Aug 2015 19:19:00 +0200

So fast, thanks :)

> >./m4/*.m4:dnl Copyright (C) 1996-2003, 2009-2010 Free Software Foundation,
> >./po/Makefile.in.in:# Copyright (C) 1995-1997, 2000-2007, 2009-2010 by Ulrich Drepper <drepper@gnu.ai.mit.edu>
> >./plugins/sample/po/Makefile.in.in:# Copyright (C) 1995-1997, 2000-2007, 2009-2010 by Ulrich Drepper <drepper@gnu.ai.mit.edu>
> >./config.rpath:#   Copyright 1996-2010 Free Software Foundation, Inc.
> >./INSTALL:Copyright (C) 1994-1996, 1999-2002, 2004-2011 Free Software Foundation,
> >./INSTALL:are permitted in any medium without royalty provided the copyright
> >./build-aux/config.rpath:#   Copyright 1996-2010 Free Software Foundation, Inc.
> >./build-aux/pkg-version:# Copyright 2008-2012 Red Hat, Inc.
> >
> >not sure how to deal with those : they specify a copyright but no license
> >except things like "unlimited permission to copy and/or distribute it, with or
> >without modifications, as long as this notice is preserved."
> >So, does this means that they will fall under the license of the project
> >(LGPL-3) or are those small notices considered as a license by itself?
> 
> yes, fine for them :)

then, how should I specify the "License:" field if it's not a "named" license ?

> and please tell somewhere the package name, because I forgot it
> (and I'm too lazy to check)

It's in the subject now ; we won't lose it easily, eventually.

F.

Message #102 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Gianfranco Costamagna <costamagnagianfranco@yahoo.it>

To: frederic@fr.ibm.com

Cc: thierry@linux.vnet.ibm.com, brenohl@br.ibm.com, 772823@bugs.debian.org

Subject: R: kimchi: looking for a mentor

Date: Fri, 28 Aug 2015 18:31:31 +0100

Hi,

>then, how should I specify the "License:" field if it's not a "named" license ?
>

I guess it might fall into LGPL or whatever (just check the directories)

>> and please tell somewhere the package name, because I forgot it
>> (and I'm too lazy to check)
>
>It's in the subject now ; we won't lose it easily, eventually.

thanks!

G.

Message #107 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Frederic Bonnard <frederic@fr.ibm.com>

To: 772823@bugs.debian.org

Cc: robie.basak@canonical.com, thierry@linux.vnet.ibm.com, brenohl@br.ibm.com, Gianfranco Costamagna <costamagnagianfranco@yahoo.it>

Subject: kimchi: another packaging and another version

Date: Fri, 2 Oct 2015 17:46:14 +0200

Hi,

Here is a new packaging especially to fix most of the previous points and for
the new version 1.5.1 of kimchi.
Also :
- added a patch to fix the 404 error for the novnc popup (this patch won't be
  pushed upstream as is as upstream reorganize the code)
- documented more things in README.Debian (user configuration, possible errors) and README.source
- updated copyright (and a fix from Ubuntu, thanks Robie)

Note :
- kimchi source is being restructured, so package may have several changes in
  the next version
- kimchi license is going to change, back to LGPL v2

F.

On Fri, 28 Aug 2015 18:31:31 +0100, Gianfranco Costamagna <costamagnagianfranco@yahoo.it> wrote:
> 
> Hi,
> 
> >then, how should I specify the "License:" field if it's not a "named" license ?
> >
> 
> I guess it might fall into LGPL or whatever (just check the directories)
> 
> >> and please tell somewhere the package name, because I forgot it
> >> (and I'm too lazy to check)
> >
> >It's in the subject now ; we won't lose it easily, eventually.
> 
> thanks!
> 
> G.
> 

Message #112 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Gianfranco Costamagna <costamagnagianfranco@yahoo.it>

To: Frederic Bonnard <frederic@fr.ibm.com>, "772823@bugs.debian.org" <772823@bugs.debian.org>

Cc: "robie.basak@canonical.com" <robie.basak@canonical.com>, "thierry@linux.vnet.ibm.com" <thierry@linux.vnet.ibm.com>, "brenohl@br.ibm.com" <brenohl@br.ibm.com>

Subject: Re: kimchi: another packaging and another version

Date: Fri, 2 Oct 2015 15:56:53 +0000 (UTC)

Hi Frederic

can you please upload the package (if you think it is good for review/upload) on mentors.d.o
http://mentors.debian.net/intro-maintainers

and open an RFS bug then?
(when the package is uploaded you should be able to open an RFS bug starting from this template)
https://mentors.debian.net/sponsors/rfs-howto/kimchi

ITP bugs are not ideal for discussing packaging issues/review, while RFS are.


cheers,

Gianfranco




Il Venerdì 2 Ottobre 2015 17:46, Frederic Bonnard <frederic@fr.ibm.com> ha scritto:
Hi,

Here is a new packaging especially to fix most of the previous points and for
the new version 1.5.1 of kimchi.
Also :
- added a patch to fix the 404 error for the novnc popup (this patch won't be
  pushed upstream as is as upstream reorganize the code)
- documented more things in README.Debian (user configuration, possible errors) and README.source
- updated copyright (and a fix from Ubuntu, thanks Robie)

Note :
- kimchi source is being restructured, so package may have several changes in
  the next version
- kimchi license is going to change, back to LGPL v2

F.

On Fri, 28 Aug 2015 18:31:31 +0100, Gianfranco Costamagna <costamagnagianfranco@yahoo.it> wrote:
> 
> Hi,
> 
> >then, how should I specify the "License:" field if it's not a "named" license ?
> >
> 
> I guess it might fall into LGPL or whatever (just check the directories)
> 
> >> and please tell somewhere the package name, because I forgot it
> >> (and I'm too lazy to check)
> >
> >It's in the subject now ; we won't lose it easily, eventually.
> 
> thanks!
> 
> G.
>

Message #119 received at 772823@bugs.debian.org (full text, mbox, reply):

From: Lucio Correia <luciojhc@linux.vnet.ibm.com>

To: 772823@bugs.debian.org

Subject: Update kimchi to latest upstream release 2.3

Date: Fri, 2 Dec 2016 11:47:56 -0200

Dear mentors,

We are working to make kimchi's latest upstream release 2.3 available to 
Debian.

Starting with 2.0, Kimchi had the webserver functionality split out to a 
new package called Wok (Webserver originated from Kimchi), and is now 
focused only on Virtualization functionality.

Kimchi now depends on wok (ITP 846595) and ginger-base (ITP 846598) 
packages, for which we are also going to provide and maintain updates 
every Debian release.

We were looking for sponsorship at bug 800966 and will update it with 
package information.


This is updated information for kimchi package:

Description: HTML5 based management tool for KVM
Kimchi is designed to make it as easy as possible to get started with 
KVM and create your first guest.
.
Kimchi is a plugin for Wok. It manages KVM guests through libvirt. The
management interface is accessed over the web using a browser that 
supports HTML5.

License: LGPL-2.1+ and Apache-2.0
Copyright: 2013-2016 International Business Machines Corporation and others.
URL: https://github.com/kimchi-project/kimchi

Thanks,
-- 
Lucio Correia
Software Engineer
IBM LTC Brazil

Message #126 received at 772823-done@bugs.debian.org (full text, mbox, reply):

From: Lucio Correia <luciojhc@linux.vnet.ibm.com>

To: 772823-done@bugs.debian.org

Date: Thu, 6 Apr 2017 00:16:40 -0300

Will not pursue it anymore.

-- 
Lucio Correia

Send a report that this bug log contains spam.