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

[Reinhard Tartler]

On Fr, Dez 30, 2011 at 12:01:02 (CET), Mike Gabriel wrote:

> 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!

Well, if you are aware that they still need work, then rather fix them
instead of suppressing (== adding lintian overrides). Claiming the
package was 'lintian-clean' is just so wrong when it isn't.


>>> 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. 

Noted. I will keep that in mind for the future.

> 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.

Aha. Well, while I'm not convinced (yet?) that this was a good idea,
such pieces of information really should go into README.source. Besides,
currently the file exists but its contents are a joke, maybe you added
it only because lintian started to complain?

> So nx-libs.git is considered as a packaging only repos which draws in
> a couple of patches that should also be reported upstream.

Yeah, that's how the branch currently looks like. Still, I'm not
convinced that this approach makes it easy to hack on for x2go developers.

>> 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.

I wanted to say 'solid command of quilt', instead of 'git. Sorry.

>
> 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...).

Well, not really. TBH, I really think that this should be settled before
doing any further work on the packaging.

>>> 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?

See above.

Besides, you can only say that for sure when you start having contact
with them. I'm glad that you volunteer to make this contact.

>>>   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?

Well, if we considered x2go as upstream, then we have only to 'declare'
files that are distributed. Considering NX as 'upstream' makes things
unnecessarily complicated.

>
>>  - 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?

Yes we want them, but only if they work. If they don't, then the
commented out entries from debian/control is just cruft that is better
removed.


>>  - 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).

Compared to editing a source file, editing a patch file is just a pain
in the ass. Just avoid such nonsense and place the files directly in the
packaging subdirectory (i.e., below debian)

>
>>  - 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...

still nonsense.

>>  - same for 009_nxproxy_add-man-page.patch, and many others as well.
>
> -> Same reason as for the main Makefile...

still nonsense.

>> 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

Cheers,
Reinhard

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4