Update debian directory

[Nobuhiro Iwamatsu]

Hi, all.

I ITPed libnfc in Debian project[1].

I've updated the debian directory accordingly, and I attached.

Please check and apply?

BTW, there was a story that you want to delete the debian directory to about six months ago. 

Is there any progress? 

I think its difficult to maintain the two code here and alioth, and want to either.

Best regards,

  Nobuhiro

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663006 

[Ludovic Rousseau]

2013/1/22 Nobuhiro Iwamatsu <iwam...@gmail.com>:
> Hi, all.

Hello,

> I ITPed libnfc in Debian project[1].
> I've updated the debian directory accordingly, and I attached.
> Please check and apply?

I will test them a bit later.

> BTW, there was a story that you want to delete the debian directory to about
> six months ago.
> Is there any progress?
> I think its difficult to maintain the two code here and alioth, and want to
> either.

Exact.
I proposed to remove the debian/* files since Oxan van Leeuwen wanted
to package the software for Debian. He then stopped working on the
packaging.

If you are active maintaining the Debian package that is different.
I got no real objection the last time I proposed the idea of removing
the debian/* files from the libnfc repository.

The debian/ directory is not present in the stables archives. It is
not present in libnfc-1.7.0-rc2.tar.gz [1] for example. So you should
not have problems using a debian/ directory from alioth.
Are you using the files at [2]?.
Do you plan to also package "unreleased" version of libnfc?

Bye

[1] http://code.google.com/p/libnfc/downloads/list
[2] http://anonscm.debian.org/viewvc/collab-maint/deb-maint/libnfc/trunk/debian/

--
Dr. Ludovic Rousseau

[Philippe Teuwen]

Hi all

I've no objection with steps bringing us closer to a proper Debian
packaging of course :-) but as developer I've some practical questions.
I'm used to create regularly my own debian packages for snapshot
versions, just not to mess up my config while developing.

So now if debian/* is gone, what would be the standard way/commands for
a developer to make his own package from the git repo + alioth debian/?

Of course I could maintain a local git branch but that's cheating ;-)
and I'm willing to learn

I discovered previous packager wanted to get rid of libnfc-examples and
libnfc-pn53x-examples just because it sounded too much "just examples
users don't care" but IMHO (some of) those tools have value, maybe
packaged under another name, and I'd like to see more collaboration &
sharing with the upstream development team than "it's just what I think"
decisions.

Occasionally we do changes that require changes in the debian/* files too.
How would that work then? How do we communicate needed/desired changes?

Thanks
Phil

[Ludovic Rousseau]

2013/1/22 Philippe Teuwen <ph...@teuwen.org>:
> Hi all

Hello,

> I've no objection with steps bringing us closer to a proper Debian
> packaging of course :-) but as developer I've some practical questions.
> I'm used to create regularly my own debian packages for snapshot
> versions, just not to mess up my config while developing.
>
> So now if debian/* is gone, what would be the standard way/commands for
> a developer to make his own package from the git repo + alioth debian/?

What I do in the other projects I have as an upstream author and also
as a Debian maintainer is that I use the alioth debian/ directory in
the project repository.

WIth that setup:
- you have an up to date debian packaging
- you can have your own local modification to debian files if needed
(like a debug mode by default)

If the debian/ files on alioth are managed in git (that is not yet the
case) we could even use them as a git sub-module [1]

Nobuhiro, do you mind if the debian/ files on alioth are managed by
git? Now that I use git I prefer it over svn, especially to maintain
local changes in a branch.

> Of course I could maintain a local git branch but that's cheating ;-)
> and I'm willing to learn
>
> I discovered previous packager wanted to get rid of libnfc-examples and
> libnfc-pn53x-examples just because it sounded too much "just examples
> users don't care" but IMHO (some of) those tools have value, maybe
> packaged under another name, and I'd like to see more collaboration &
> sharing with the upstream development team than "it's just what I think"
> decisions.

If they are real tools the names *-example are misleading.

> Occasionally we do changes that require changes in the debian/* files too.
> How would that work then? How do we communicate needed/desired changes?

I think Nobuhiro is on this list now so just publish your changes
here. If Nobuhiro is not available I can push the changes to alioth.

Bye

[1] http://git-scm.com/book/en/Git-Tools-Submodules

--
Dr. Ludovic Rousseau

[Thomas Hood]

In the past upstream maintained a debian/ subdirectory for the purpose of building usable (if perhaps not entirely policy-compliant) Debian packages. That's fine. Upstream debian/ included a changelog file where changes to upstream debian/ were documented. That's fine too. But if the package is now going to be packaged for Debian then Debian can just ignore the whole upstream debian/ subdirectory and substitute its own. I do hope we don't have to worry about licensing issues with respect to things copied from upstream debian/. :)

Question remains: How to "contribute back"? Either upstream can just start using Debian's debian/ (via git submodule or some such, as just mentioned) or relevant patches can be sent back upstream. The latter makes more sense if upstream needs to build packages differently from how Debian does.

-- 

Thomas

[Thomas Hood]

I notice that debian/ is not included in the (1.7.0-rc1) tarball anyway.

-- 

Thomas

[Nobuhiro Iwamatsu]

Hi, all.

2013年1月23日水曜日 7時18分26秒 UTC+9 Ludovic Rousseau:

2013/1/22 Philippe Teuwen <ph...@teuwen.org>:
> Hi all

Hello,

> I've no objection with steps bringing us closer to a proper Debian
> packaging of course :-) but as developer I've some practical questions.
> I'm used to create regularly my own debian packages for snapshot
> versions, just not to mess up my config while developing.
>
> So now if debian/* is gone, what would be the standard way/commands for
> a developer to make his own package from the git repo + alioth debian/?

What I do in the other projects I have as an upstream author and also
as a Debian maintainer is that I use the alioth debian/ directory in
the project repository.

WIth that setup:
- you have an up to date debian packaging
- you can have your own local modification to debian files if needed
(like a debug mode by default)

If the debian/ files on alioth are managed in git (that is not yet the
case) we could even use them as a git sub-module [1]

I dont like git sub-modules....

 

Nobuhiro, do you mind if the debian/ files on alioth are managed by
git? Now that I use git I prefer it over svn, especially to maintain
local changes in a branch.

I do not mind either.

However, I think as you said, to make a smooth update of Debian package, the better to maintain the debian directory package maintainers in alioth free access is good.

 

> Of course I could maintain a local git branch but that's cheating ;-)
> and I'm willing to learn
>
> I discovered previous packager wanted to get rid of libnfc-examples and
> libnfc-pn53x-examples just because it sounded too much "just examples
> users don't care" but IMHO (some of) those tools have value, maybe
> packaged under another name, and I'd like to see more collaboration &
> sharing with the upstream development team than "it's just what I think"
> decisions.

If they are real tools the names *-example are misleading.

> Occasionally we do changes that require changes in the debian/* files too.
> How would that work then? How do we communicate needed/desired changes?

I think Nobuhiro is on this list now so just publish your changes
here. If Nobuhiro is not available I can push the changes to alioth.

I will do.

But I want to use same VCS with upstream.

 

Bye

[1] http://git-scm.com/book/en/Git-Tools-Submodules

--
 Dr. Ludovic Rousseau

Nobuhiro 

[Nobuhiro Iwamatsu]

I also thought that tar-ball has debian deirectory, because git repository had debian directory.

Thanks!

2013年1月23日水曜日 21時43分10秒 UTC+9 Thomas Hood:

[Ludovic Rousseau]

Hello,

I pushed the changes proposed by Nobuhiro.

Nobuhiro, I have some lintian warnings you may want to fix.
W: libnfc-bin: binary-without-manpage usr/bin/nfc-scan-device
I: libnfc-bin: extended-description-is-probably-too-short
I: libnfc-pn53x-examples: extended-description-is-probably-too-short
I: libnfc4: no-symbols-control-file usr/lib/x86_64-linux-gnu/libnfc.so.4.0.0


2013/1/24 Nobuhiro Iwamatsu <iwam...@gmail.com>:

>> > Occasionally we do changes that require changes in the debian/* files
>> > too.
>> > How would that work then? How do we communicate needed/desired changes?
>>
>> I think Nobuhiro is on this list now so just publish your changes
>> here. If Nobuhiro is not available I can push the changes to alioth.
>
>
> I will do.
> But I want to use same VCS with upstream.

The same VCS tool or the same VCS repository?

Bye

--
Dr. Ludovic Rousseau

[Philippe Teuwen]

On 01/25/2013 02:46 PM, Ludovic Rousseau wrote:
> Hello,
>
> I pushed the changes proposed by Nobuhiro.
>
> Nobuhiro, I have some lintian warnings you may want to fix.
> W: libnfc-bin: binary-without-manpage usr/bin/nfc-scan-device

Ref was missing in debian/libnfc-bin.install
I've pushed it now.

Phil

[Ludovic Rousseau]

2013/1/25 Philippe Teuwen <ph...@teuwen.org>:

'git push' failed? I can't find your change.

[Philippe Teuwen]

On 01/25/2013 04:57 PM, Ludovic Rousseau wrote:
> 'git push' failed? I can't find your change.

git push forgotten, ahem...

[Nobuhiro Iwamatsu]

Hi,

2013年1月25日金曜日 22時46分07秒 UTC+9 Ludovic Rousseau:

Hello,

I pushed the changes proposed by Nobuhiro.

Nobuhiro, I have some lintian warnings you may want to fix.
W: libnfc-bin: binary-without-manpage usr/bin/nfc-scan-device
I: libnfc-bin: extended-description-is-probably-too-short
I: libnfc-pn53x-examples: extended-description-is-probably-too-short
I: libnfc4: no-symbols-control-file usr/lib/x86_64-linux-gnu/libnfc.so.4.0.0

 

OK, I did not check with -I option of lintian.

I attached patches.

0001-Add-symbols-file-for-libnfc4.patch

0002-Update-package-description.patch

0003-Add-support-libnfc4-dbg-package.patch

0004-install-nfc-emulate-forum-tag2.1-to-libnfc-examples.patch

0005-Update-to-1.7.0-rc3.patch

And I found a problem about man installation.

Please apply 0001-Add-man-of-nfc-emulate-forum-tag2-to-the-installatio.patch.

2013/1/24 Nobuhiro Iwamatsu <iwam...@gmail.com>:
>> > Occasionally we do changes that require changes in the debian/* files
>> > too.
>> > How would that work then? How do we communicate needed/desired changes?
>>
>> I think Nobuhiro is on this list now so just publish your changes
>> here. If Nobuhiro is not available I can push the changes to alioth.
>
>
> I will do.
> But I want to use same VCS with upstream.

The same VCS tool or the same VCS repository?

 VCS tools. About VCS repository, either one will be fine.

 

Bye

--
 Dr. Ludovic Rousseau

best regards,

  Nobuhiro 

[Philippe Teuwen]

On 02/01/2013 01:40 AM, Nobuhiro Iwamatsu wrote:
> I attached patches.

Applied.
I removed also some trailing spaces in provided patches.

Phil

[Philippe Teuwen]

On 02/01/2013 01:40 AM, Nobuhiro Iwamatsu wrote:

> 0005-Update-to-1.7.0-rc3.patch

=> shouldn't be the symbols adapted too in debian/libnfc4.symbols?
1.7.0~rc2

[Nobuhiro Iwamatsu]

Hi,

2013年2月1日金曜日 10時02分34秒 UTC+9 Yobi Byte:

library ABI does not change from rc2 to rc3. I did not update.

But It is good to match a version.

I attached a patch for  debian/libnfc4.symbols.

[Thomas Hood]

Have you guys made binary packages available somewhere?

My PPA (https://launchpad.net/~jdthood/+archive/nfc-tools) contains binary packages of libnfc 1.7.0rc2 built using the last debian materials supplied by the former (now resigned) ITPer. These packages aren't perfect but they are better than nothing.

I'd prefer to start using, and thus testing, packages built using your latest debian materials.

If you haven't made binaries available, can I please have instructions for building such binaries, using your debian materials?

-- 

Thomas

[Philippe Teuwen]

On 02/04/2013 12:04 PM, Thomas Hood wrote:
> Have you guys made binary packages available somewhere?

Hi Thomas,
No.

> My PPA (https://launchpad.net/~jdthood/+archive/nfc-tools) contains
> binary packages of libnfc 1.7.0rc2 built using the last debian
> materials supplied by the former (now resigned) ITPer. These packages
> aren't perfect but they are better than nothing.
>
> I'd prefer to start using, and thus testing, packages built using your
> latest debian materials.

It's better indeed, as our debian/ is now in sync with the official one
on Alioth

> If you haven't made binaries available, can I please have instructions
> for building such binaries, using your debian materials?

Personally I just do a "fakeroot debian/rules binary" in a clean git
workdir.
It leaves the created *deb in the parent repository

Alternative used by Ludovic:

make dist # to generate libnfc-1.7.0-rc4.tar.gz
mkdir foo
cp libnfc-1.7.0-rc4.tar.gz foo
cd foo
tar xzvf libnfc-1.7.0-rc4.tar.gz
cp -a [...]/debian libnfc-1.7.0-rc4 # debian/ directory from git repo
mv libnfc-1.7.0-rc3.tar.gz libnfc_1.7.0~rc3.orig.tar.gz
cd libnfc-1.7.0-rc3
debuild

Cheers
Phil

[Thomas Hood]

Thanks!

As I want to work from the release tarball and from the official debian materials I have just generated a new package for the PPA as follows.

$ wget http://libnfc.googlecode.com/files/libnfc-1.7.0-rc4.tar.gz

$ tar zxf libnfc_1.7.0~rc4.orig.tar.gz

$ svn export svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/libnfc/trunk/debian libnfc-1.7.0-rc4/debian

$ cd libnfc-1.7.0-rc4

$ vi debian/changelog # Edit changelog entry appropriately

$ debuild -S

$ dput ppa:jdthood/nfc-tools libnfc_1.7.0~rc4-0ppa1_source.changes

BTW, you should do something about the following at some point.  ;)

dh_autoreconf -a

sh: 1: git: not found

sh: 1: git: not found

[Nobuhiro Iwamatsu]

Hi,

2013年2月4日月曜日 22時32分07秒 UTC+9 Thomas Hood:

I attached a patch which reivise this problem.

Best regards,

  Nobuhiro

 

[Ludovic Rousseau]

2013/2/5 Nobuhiro Iwamatsu <iwam...@gmail.com>:

I don't like the idea to have to patch configure.ac to build a Debian package.
The ./configure script should be smart enough to detect that git is
not available.

I will try to work on that.

[Thomas Hood]

In order to build mfoc 0.10.5 against libnfc 1.7.0~rc4 I discovered that I had to add Build-Dependencies on libpcsclite-dev and libusb-dev (in addition to the obvious one on libnfc-dev). I believe that these should actually be Dependencies of libnfc-dev.

$ pkg-config --print-requires libnfc

libusb

libpcsclite

-- 

Thomas

[Ludovic Rousseau]

2013/2/5 Ludovic Rousseau <ludovic....@gmail.com>:

Proposed patch:
--- /tmp/uu8lhe_configure.ac 2013-02-05 14:35:05.043624791 +0100
+++ configure.ac 2013-02-05 14:34:18.519624535 +0100
@@ -8,9 +8,10 @@ AC_CONFIG_MACRO_DIR([m4])
AC_CONFIG_HEADER(config.h)

# GIT revison
-define([git_revision], esyscmd([sh -c "git describe"]))
-GIT_REVISION=git_revision
-AC_DEFINE_UNQUOTED([GIT_REVISION], ["$GIT_REVISION"], [GIT revision])
+GIT_REVISION=`which git > /dev/null && git describe`
+if test x"$GIT_REVISION" != x""; then
+ AC_DEFINE_UNQUOTED([GIT_REVISION], ["$GIT_REVISION"], [GIT revision])
+fi

AM_INIT_AUTOMAKE
m4_ifdef([AM_PROG_AR], [AM_PROG_AR])


With the previous code 'git describe' was executed when configure is
generated, not when configure is executed.

I am not sure this code is needed. The only use of it is in libnfc/nfc.c:
const char *
nfc_version(void)
{
#ifdef GIT_REVISION
return GIT_REVISION;
#else
return PACKAGE_VERSION;
#endif // GIT_REVISION
}

In the present case PACKAGE_VERSION and GIT_REVISION have the same
value: "libnfc-1.7.0-rc4"

Why do we need GIT_REVISION at all?

[Philippe Teuwen]

On 02/05/2013 02:39 PM, Ludovic Rousseau wrote:
> In the present case PACKAGE_VERSION and GIT_REVISION have the same
> value: "libnfc-1.7.0-rc4"
>
> Why do we need GIT_REVISION at all?

It's useful for snapshots.
If HEAD is not at a release tag, this gives something like:
libnfc-1.7.0-rc4-1-ge9dfdeb

I think your fix is ok for inclusion, do you push it?

Bye
Phil

[Ludovic Rousseau]

2013/2/5 Philippe Teuwen <ph...@teuwen.org>:

> On 02/05/2013 02:39 PM, Ludovic Rousseau wrote:
>> In the present case PACKAGE_VERSION and GIT_REVISION have the same
>> value: "libnfc-1.7.0-rc4"
>>
>> Why do we need GIT_REVISION at all?
>
> It's useful for snapshots.
> If HEAD is not at a release tag, this gives something like:
> libnfc-1.7.0-rc4-1-ge9dfdeb

OK. I learnt something new.

> I think your fix is ok for inclusion, do you push it?

Pushed.

[Nobuhiro Iwamatsu]

OK, I understood your point.

Nobuhiro

2013年2月5日火曜日 17時22分04秒 UTC+9 Ludovic Rousseau:

[Romuald Conty]

Hello,

I'm not a debian package guru and I need some help...

I just see that libnfc 1.7.0~rc4 debian package is not detected as >=1.7.0 in
Build-Depends.
In example, using mfoc debian package (dkp-buildpackage -b):
[...]
dpkg-checkbuilddeps: Unmet build dependencies: libnfc-dev (>= 1.7.0)
[...]

I agree libnfc-dev 1.7.0 RC4 may not be consider as >= 1.7.0 as its clearly <
1.7.0.

How to specify in mfoc debian package that needs >= 1.7.0 RC1 ?

Next, as a workaround I changed libnfc's debian/changelog from "1.7.0~rc4" to
"1.7.0rc4" (without '~') and now mfoc's debian package build but I read that:

"The package version is a beta version or release candidate, for example 1.0b1
or 1.0rc2
Problems will arise because dpkg will consider the final version 1.0 lower than
the beta or release candidate version. The solution is to use a version like
0.99+1.0rc2-0joe1 which uses a lower version than 1.0 (0.99) and joins the
release candidate version with a plus sign. This way the final version is
greater than the previous one: 0.99+1.0rc2-0joe1 < 1.0-0joe1. "

source: http://people.debian.org/~calvin/unofficial/

Should we really use this trick or this assumption is outdated ?

What is the right way to handle release candidate in debian packaging system ?

Thanks.

--
Romuald

[Thomas Hood]

> How to specify in mfoc debian package that needs >= 1.7.0 RC1

That's easy.  Depends: libnfc4 (>= 1.7.0~rc1)

> Should we really use this trick or this assumption is outdated ?

Using "1.7.0~rc1" is a better trick than using "1.6.99+1.7.0rc1". Either one sorts before "1.7.0" in the dpkg lexicographic order.

$ dpkg --compare-versions 1 '<<' 2 && echo yes || echo no

yes

$ dpkg --compare-versions 1 '>=' 2 && echo yes || echo no

no

$ dpkg --compare-versions 1.6.99+1.7.0rc1 '<=' 1.7.0 && echo yes || echo no

yes

$ dpkg --compare-versions 1.7.0~rc1 '<=' 1.7.0 && echo yes || echo no

yes

$ dpkg --compare-versions 1.7.0rc1 '<=' 1.7.0 && echo yes || echo no

no

-- 

Thomas