[Pkg-x2go-devel] NX Packages built from nx-libs.git on X2Go Git now lintian-clean

[Mike Gabriel]

Hi Reinhard,

On Fr 30 Dez 2011 00:12:10 CET Reinhard Tartler wrote:

> On Do, Dez 29, 2011 at 21:57:43 (CET), Mike Gabriel wrote:
>

> TBH, I think (almost) all lintian warnings should rather be fixed than
> supressed.

Yes, I think that too. Every suppressed warning/error has its story:

1. possible-new-upstream-release-without-new-version
-> a new upstream release of any of the NX component does not mean that we
    use a new version number... nonetheless in the changelog there should be
    a message: New upstream release of <NX-component> (<version>).

2. postinst-has-useless-call-to-ldconfig and  
postrm-has-useless-call-to-ldconfig
    relate to a bug in debhelper... -> #205142

3. ancient-autotools-helper-file, outdated-autotools-helper-file, ancient-
    libtool are all fixed via the patch system (by patching in stable versions
    of config.guess, config.sub, ltmain.sh). However, these patches to not
    appear in the source tarball an so the warnings/errors are still reported.

4. breaks-without-version -> I could check what version is needed here to
    definitely make sure to replace nxcomp* with libxcomp*3.
    So this one is on my TODO!

>> I guess it now is time for others to take a closer look at the code  and
>> esp. the patch series. Reinhard could you take some time to do  that?
>
> I'm a bit surprised to see that you are asking on this mailing list for
> review for a branch on git.x2go.org, and not one on alioth.

I will push the whole repos to Alioth, if agreed. The location on  
git.x2go.org currently is for convenience as it integrates with our  
Debian and Ubuntu build system. Consider it as lazyness for now. I can  
move the Git repos over to Alioth immediately.

> I assume you
> want to use that branch both as upstream and as packaging branch at the
> same time?

Since NoMachine has become active again about NX (they have released  
nxagent 3.5.0-7 since we had set up the new nx-libs.git repos) I do  
not consider the X2Go project as upstream anymore. So nx-libs.git is  
considered as a packaging only repos which draws in a couple of  
patches that should also be reported upstream.

> This was not what I had in mind when I proposed the layout of
> the x2go branches. In particular, I don't have the impression that all
> x2go developers are comfortable with working on quilt series. Maybe this
> changed without me noticing it? - In any case, I think the requirement
> of solid command of git raises the bar to hack on the sources
> considerably.

You are absolutely right. nx-libs.git is a packaging repos. The  
question is how open we are to patches for NX (as upstream is not so  
open to them, I guess... this is an opinion, haven't tried to send in  
a patch yet).

However, I also plan to setup an x2goagent-ng project (this is  
upstream information now) that also works with quilt. It would give a  
much better overview on what is X2Go code and what is the original NX  
within x2goagent. It would also ease working in nxagent updates that  
come from NoMachine. Hmmm... when thinking of this quilt is not  
necessarily needed, maybe an nxagent upstream branch that documents  
the changes between all nxagent versions is sufficient... (getting  
off-topic here...).

>> Other contributors of feedback are really welcome.
>>
>> Open issues still are:
>>
>>   o no common debian/watch file yet that checks all sub-tarballs  
>> that nx-libs
>>     draws in from NoMachine upstream
>
> Uh? I thought x2go was upstream for Debian, not Nomachine?

-> as NoMachine is active again on NX we should consider them as upstream?

>>   o no get-orig-source stanza in debian/rules, this is highly recommended
>
> *shrug*, I don't care much here. I'd consider a working watch file more
> important.

Ok.

>>   o I have a working xinerama patch for nxagent/x2goagent pending that also
>>     shall find its way into nx-libs.git
>
> noted.

:-)

> What occurs to me after a rather brief look:
>
>  - I don't believe that debian/copyright is complete

-> Agreed. ToDo -> Mike

>  - nx-X11/extras contains a lot of duplicated libraries that are already
>    in debian. I'm not convinced that all of them are really needed. In
>    any case, I fear they'd all need to be documented in debian/copyright

There was a lintian error: embedded library (for libexpat that uses  
libxmltok. The libxmltok files are shipped in extras for example.

I will try to remove that folder before building and see what  
compilation errors fail. If nothing fails it certainly means that we  
do not use those files. Will we then have to name them in the  
copyright file?

>  - For the debian packages, the maintainer field must point to the team,
>    not oleksandr. For the upstream code, this is fine.

ToDo -> Mike

>  - The Homepage field should point to the x2go homepage. The origin of
>    the sources has to be documented in debian/copyright, not in
>    debian/control

ToDo -> Mike

>  - debian/control contains a commented out package. Remove it or enable
>    it. don't leave them commented out, that's pointless.

Those are the *-dbg packages. The stripping of debug information did  
not work with the nx-libs source tree. No idea why... Do we want *-dbg  
packages? If yes, then may I ask you to take a look at that?

>  - The description of the package libnx-x11 is too terse. Other
>    description could also be improved

ToDo -> Mike

>  - debian/changelog needs to close an ITP bug.

Then we first have to create an ITP for the whole NX library/binary  
stuff. Do you report an ITP also for already existing packages  
(libxcomp*)? Or is this then a continuation? What would be the best  
text template for this?

>  - 001_add-main-makefile.patch is pointless. Just place the makefile in
>    debian/

If it does not hurt there, I would like to leave it there, as it  
allows me to create a patched tarball for people who want to build  
nx-libs.git for other distros (LinuxFromScratch, Gentoo).

>  - most (all?) patches in debian/patches lack a patch documentation
>    header, see http://dep.debian.net/deps/dep3/

-> ToDo Mike

>  - patch 006_remove-configure-files.patch is pointless, just remove the
>    file in debian/rules in the clean target

-> Already switch to this, the patch is commented out in debian/patches/series

>  - 008_nxproxy_add-nxproxy-wrapper.patch is pointless, just place the
>    wrapper in some subfolder in debian/

-> Same reason as for the main Makefile...

>  - same for 009_nxproxy_add-man-page.patch, and many others as well.

-> Same reason as for the main Makefile...

> I have to stop now. I think you got the basic idea of what I've looked
> for in this run. Yes, I think there is still a *lot* of work left before
> we can upload nx-libs to Debian¹.

> 1: Which is another reason why I was against the 'nx-libs.git'
> approach. Btw, did you find out in the end what the problem actually was?

No! Unfortunately not...

Thanks for taking a look till here so far...
Mike


-- 

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

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

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.alioth.debian.org/pipermail/pkg-x2go-devel/attachments/20111230/431592ca/attachment.pgp>