Bug#647018: how should we upload gnuradio into Debian

2011-11-23 Thread Antoine Beaupré
On Fri, 18 Nov 2011 01:12:58 -0500, A. Maitland Bottoms bott...@debian.org 
wrote:
 Here's what I've got so far...
 
 http://anonscm.debian.org/gitweb/?p=users/bottoms/pkg-uhd.git;a=summary
 
 http://anonscm.debian.org/gitweb/?p=users/bottoms/pkg-gnuradio.git;a=summary
 
 I am not happy with the gnuradio package dependencies, python2.7 should
 be there. But, it is a start.

I have tried to compile those packages in sid, and I wasn't
successful. Gnuradio has dependency problems:

 pbuilder-satisfydepends-dummy : Depends: debhelper (= 8.0.0~) but it is not 
going to be installed
 Depends: libuhd-dev but it is not installable
 Depends: libaudio-dev but it is not going to 
be installed
 Depends: libxi-dev but it is not going to be 
installed
 Depends: libfontconfig1-dev but it is not 
going to be installed
 Depends: libxrender-dev but it is not going to 
be installed
 Depends: libpulse-dev but it is not going to 
be installed
 Depends: swig (= 1.3.31) but it is not going 
to be installed
 Depends: python-dev but it is not going to be 
installed
 Depends: libfftw3-dev but it is not going to 
be installed
 Depends: libcppunit-dev (= 1.9.14) but it is 
not going to be installed
 Depends: libboost-all-dev (= 1.35) but it is 
not going to be installed
 Depends: libsdl1.2-dev but it is not going to 
be installed
 Depends: python-wxgtk2.8 but it is not going 
to be installed
 Depends: guile-1.8-dev but it is not going to 
be installed
 Depends: libqt4-dev but it is not going to be 
installed
 Depends: python-numpy but it is not going to 
be installed
 Depends: python-opengl but it is not going to 
be installed
 Depends: libgsl0-dev (= 1.10) but it is not 
going to be installed
 Depends: python-cheetah but it is not going to 
be installed
 Depends: python-lxml but it is not going to be 
installed
 Depends: doxygen but it is not going to be 
installed
 Depends: xmlto but it is not going to be 
installed
 Depends: qt4-dev-tools but it is not going to 
be installed
 Depends: libqwt5-qt4-dev but it is not going 
to be installed
 Depends: libqwtplot3d-qt4-dev but it is not 
going to be installed
 Depends: pyqt4-dev-tools but it is not going 
to be installed
 Depends: python-qwt5-qt4 but it is not going 
to be installed
 Depends: python-gtk2-dev but it is not going 
to be installed
 Depends: pkg-config (= 0.15.0) but it is not 
going to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a 
solution).

... and uhd doesn't build at all:

$ DIST=sid ARCH=amd64 git-buildpackage 
dh clean --sourcedirectory=host --builddirectory=build
   dh_testdir -O--sourcedirectory=host -O--builddirectory=build
   dh_auto_clean -O--sourcedirectory=host -O--builddirectory=build
dh_auto_clean: invalid or non-existing path to the source directory: host
make: *** [clean] Erreur 2
gbp:error: fakeroot debian/rules clean returned 2
gbp:error: Couldn't run 'fakeroot debian/rules clean'

For gnuradio, I went with the multi-package approach that Johnathan
Corgan was working on, and I fixed a lot of the depdencies.

I have the feeling I should do the same as you and publish my
repository, so we can compare. It should appear here within 6 hours:

http://anonscm.debian.org/gitweb/?p=users/anarcat/pkg-gnuradio.git

Shouldn't we try to merge this stuff? :)

Do you have the same problems as me in the gnuradio-companion package
(failure thingy)?

A.

-- 
Premature optimization is the root of all evil
- Donald Knuth


pgpRKpEUyvFkS.pgp
Description: PGP signature


Bug#647018: how should we upload gnuradio into Debian

2011-11-18 Thread Bdale Garbee
On Thu, 17 Nov 2011 01:59:25 -0500, Antoine Beaupré anar...@debian.org wrote:
 I agree with bdale that closing existing issues seems to make most
 sense. Not sure about the need to remove it from unstable though, since
 it's going to be replaced once we fix it up a bit anyways...

I'll take care of this.  Removing the existing packages will induce no
delay in uploading a new version, since the new version will have to go
through NEW processing anyway due to changes in the binary package
list.  And removing the packages from unstable seems like the right
thing to do if I'm going to close the existing bugs.

I'll take care of this right now.  Please don't upload any new bits
until I report successful completion of the removal process to avoid
confusing the admin team.

Bdale


pgppOLXJeZCu8.pgp
Description: PGP signature


Bug#647018: how should we upload gnuradio into Debian

2011-11-18 Thread Bdale Garbee
On Thu, 17 Nov 2011 01:59:25 -0500, Antoine Beaupré anar...@debian.org wrote:
 I agree with bdale that closing existing issues seems to make most
 sense. Not sure about the need to remove it from unstable though, since
 it's going to be replaced once we fix it up a bit anyways...

I just talked to Ganneff and weasel on IRC.  The best plan is to keep
the 'gnuradio' name for at least one of the new source packages, and
have the changelog of that package close all the existing bugs as part
of a 'new upstream version' entry in the changelog.

For your cut'n'paste convenience, I offer:

  * new upstream version, re-packaged from scratch with modern tools
closes: #642716, #645332, #394849, #616832, #590048, #642580,
#647018, #557050, #559640, #631863

I've reviewed all of them quickly, and only 590048 (about a typo in the
description in the control file) is at all relevant to a re-packaging of
a newer version.  The rest should just be closed without further thought.

Bdale


pgpuaPRxEmaGM.pgp
Description: PGP signature


Bug#647018: how should we upload gnuradio into Debian

2011-11-17 Thread A. Maitland Bottoms
Here's what I've got so far...

http://anonscm.debian.org/gitweb/?p=users/bottoms/pkg-uhd.git;a=summary

http://anonscm.debian.org/gitweb/?p=users/bottoms/pkg-gnuradio.git;a=summary

I am not happy with the gnuradio package dependencies, python2.7 should
be there. But, it is a start.

-Maitland



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#647018: how should we upload gnuradio into Debian

2011-11-16 Thread Antoine Beaupré
Hi,

I am writing to you directly as you are either:

 (1) maintaining the upstream debian branch of gnuradio
 (2) the current maintainer of the Debian package
 (3) a NMU uploader of the Debian package :)

Short version: I want to avoid duplicating any work and enquire if you
have the intention of packaging 3.5.0rc0.

Long version:

I am interested in seeing how we could package 3.5.0rc0 in experimental,
as per the bug report in CC (#647018). I have tried to start from the
upstream Debian branch and merge in the v3.5.0rc0 tag, but had miserable
results. I had never seen git fail so badly at a merge, and you can try
it to see, it is not pretty:

warning: inexact rename detection was skipped due to too many files.
warning: you may want to set your merge.renamelimit variable to at least 1476 
and retry the command.
Automatic merge failed; fix conflicts and then commit the result.
anarcat@marcos:gnuradio$ 

So I am now looking at creating a fresh new Debian branch off the
v3.5.0rc0 tag, and import the debian/ directory in there clean.

But that's the easy (ie. meta) part - it looks like there's going to
be some work on necessary on the dependencies. My first attempt at
building a package yielded libtool problems directly in the build
bootstrap, and I suspect there will be much more along the way:

[ -f ./configure ] || ./bootstrap
configure.ac:136: warning: AC_PROG_LIBTOOL is m4_require'd but not m4_defun'd
config/gr_scripting.m4:22: GR_SCRIPTING is expanded from...
[...]
gnuradio-core/src/guile/Makefile.am:66: Libtool library used but `LIBTOOL' is 
undefined
gnuradio-core/src/guile/Makefile.am:66:   The usual way to define `LIBTOOL' is 
to add `AC_PROG_LIBTOOL'

*So*, instead of going on a wild run to start fixing this stuff, I am
writing you guys to see if anyone is already working on this or
interested in helping.

It would be great to have 3.5 make a grand entry in Debian, it would be
right in time for Wheezy. :)

Thanks for your comments, and sorry for the intrusion.

A.

-- 
Information is not knowledge
Knowledge is not wisdom
Wisdom is not truth
- Frank Zappa


pgpNy7yiz9SVt.pgp
Description: PGP signature


Bug#647018: how should we upload gnuradio into Debian

2011-11-16 Thread Bdale Garbee
On Wed, 16 Nov 2011 19:38:44 -0500, Antoine Beaupré anar...@debian.org wrote:
 Short version: I want to avoid duplicating any work and enquire if you
 have the intention of packaging 3.5.0rc0.

I really do not have time to lead the packaging of gnuradio in Debian
any more, and would love to see someone else take the lead on it.

 *So*, instead of going on a wild run to start fixing this stuff, I am
 writing you guys to see if anyone is already working on this or
 interested in helping.

I suggest you talk to Maitland Bottoms about what's done, I'll cc him on
this reply to bring him into the conversation.

 It would be great to have 3.5 make a grand entry in Debian, it would be
 right in time for Wheezy. :)

I would like to suggest we start by requesting that the current gnuradio
packages be purged from the Debian archive, and all existing gnuradio
bugs open in the BTS be closed.  Then, start over clean packaging a
current gnuradio version for Debian, using as much of Johnathan's
continuous adaptation of my older work that's in upstream as makes
sense, but worrying less about what went before than about the right way
to package these bits for Debian for the future.

If this happens, I'm likely to find time to *use* gnuradio again some in
the next year, and am willing to help poke around the edges from time to
time, but my attention really is elsewhere these days.

 Thanks for your comments, and sorry for the intrusion.

Thanks for asking!

Bdale


pgpD3fuOHiQOw.pgp
Description: PGP signature


Bug#647018: how should we upload gnuradio into Debian

2011-11-16 Thread A. Maitland Bottoms
 Bdale == Bdale Garbee bd...@gag.com writes:
Bdale On Wed, 16 Nov 2011 19:38:44 -0500, Antoine Beaupré anar...@debian.org 
wrote:
 Short version: I want to avoid duplicating any work and enquire if you
 have the intention of packaging 3.5.0rc0.

 *So*, instead of going on a wild run to start fixing this stuff, I am
 writing you guys to see if anyone is already working on this or
 interested in helping.

Good call. Nice to meet you.

Bdale I suggest you talk to Maitland Bottoms about what's done, I'll cc him on
Bdale this reply to bring him into the conversation.

I'm here. I'm just now setting up a pkg-uhd git repository on Alioth so
that I can share my efforts. (I had been keeping up with gnuradio git
and UHD and CMake building using my own non-policy-compliant packages
for squeeze. But now I can see a way to keep lintian happy.)

 It would be great to have 3.5 make a grand entry in Debian, it would be
 right in time for Wheezy. :)

Exactly!
The story so far:
 - Package UHD
   This is where the free software meets the contrib, where the
   sdcc bits and the FPGA tool builds fled to after being removed
   from gnuradio proper.

 - Package gnuradio 3.5.0rc0
   Can build-depend on the free parts of UHD and stay in main.
   So far I have a gnuradio 3.4.1 package for squeeze.
   gnuradio 3.5.0rc0 packages are debugging for my multiarch libuhd packages.

 - Package gr-fcd
   Since there are lots of FUNcube Dongle devices out there to support.

Other fun:
 - Package the zylin ZPU gcc toolchain
   http://opencores.org/project,zpu

 - Update sdcc packages to 3.0
   for USRP1 and B100 firmware (source in UHD)

Bdale but worrying less about what went before than about the right way
Bdale to package these bits for Debian for the future.

I have gained some skills in using the 3.0 (quilt) format of Debian packages
to make it clear what the patches to upstream are. Of course, we're all using
git so that is redundant, but that is OK. And I've been keeping up with the
fancy new debhelper tricks which makes debian/rules smaller and easier to read.

Bdale If this happens, I'm likely to find time to *use* gnuradio again some in
Bdale the next year,

I also have gr-fcd packaged - Alexandryu Csete oz9aec's GnuRadio FUNcube Dongle
driver, in case you've got one of those. I should ITP that soon.

Bdale and am willing to help poke around the edges from time to
Bdale time, but my attention really is elsewhere these days.

In the spirit of optimism I've got you in the Uploaders: field,
just to keep your name in debian/control :)

-Maitland



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#647018: how should we upload gnuradio into Debian

2011-11-16 Thread Antoine Beaupré
On Wed, 16 Nov 2011 22:18:23 -0500, A. Maitland Bottoms bott...@debian.org 
wrote:
  Bdale == Bdale Garbee bd...@gag.com writes:
 Bdale On Wed, 16 Nov 2011 19:38:44 -0500, Antoine Beaupré 
 anar...@debian.org wrote:
  Short version: I want to avoid duplicating any work and enquire if you
  have the intention of packaging 3.5.0rc0.
 
  *So*, instead of going on a wild run to start fixing this stuff, I am
  writing you guys to see if anyone is already working on this or
  interested in helping.
 
 Good call. Nice to meet you.

Same :)

 Bdale I suggest you talk to Maitland Bottoms about what's done, I'll cc him 
 on
 Bdale this reply to bring him into the conversation.
 
 I'm here. I'm just now setting up a pkg-uhd git repository on Alioth so
 that I can share my efforts. (I had been keeping up with gnuradio git
 and UHD and CMake building using my own non-policy-compliant packages
 for squeeze. But now I can see a way to keep lintian happy.)

That's great! That was one piece I was missing...

  It would be great to have 3.5 make a grand entry in Debian, it would be
  right in time for Wheezy. :)
 
 Exactly!
 The story so far:
  - Package UHD
This is where the free software meets the contrib, where the
sdcc bits and the FPGA tool builds fled to after being removed
from gnuradio proper.
 
  - Package gnuradio 3.5.0rc0
Can build-depend on the free parts of UHD and stay in main.
So far I have a gnuradio 3.4.1 package for squeeze.
gnuradio 3.5.0rc0 packages are debugging for my multiarch libuhd packages.

Are you working on the 3.5 package now?

I have done some tweaks to the control file on my side, and completely
flushed the rules file down to just the dh(7) template, and it actually
builds! I had to fiddle with the *.install files to fix some stuff and
also remove the *usrp* packages, but it's otherwise starting to look
good.

Is there a git repo you're working on for this? I guess I am not sure I
understand how far you got there...

  - Package gr-fcd
Since there are lots of FUNcube Dongle devices out there to support.

indeed :)

 Other fun:
  - Package the zylin ZPU gcc toolchain
http://opencores.org/project,zpu
 
  - Update sdcc packages to 3.0
for USRP1 and B100 firmware (source in UHD)

From what i understand, this isn't necessary in gnuradio 3.5 anymore,
and indeed i was able to build without it...

 Bdale but worrying less about what went before than about the right way
 Bdale to package these bits for Debian for the future.
 
 I have gained some skills in using the 3.0 (quilt) format of Debian packages
 to make it clear what the patches to upstream are. Of course, we're all using
 git so that is redundant, but that is OK. And I've been keeping up with the
 fancy new debhelper tricks which makes debian/rules smaller and easier to 
 read.

that stuff is amazing. :)

 Bdale If this happens, I'm likely to find time to *use* gnuradio again some 
 in
 Bdale the next year,
 
 I also have gr-fcd packaged - Alexandryu Csete oz9aec's GnuRadio FUNcube 
 Dongle
 driver, in case you've got one of those. I should ITP that soon.

now *that* is also completely amazing, glad to see that.

i had an ITP for something similar (i *think*) here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645333

but now i think it'd be more productive to work on gnuradio...

thanks for the feedback,

A.
-- 
Wherever they's a fight so hungry people can eat, I'll be there.
Wherever they's a cop beatin' up a guy, I'll be there.
If Casy knowed, why, I'll be in the way guys yell when they're mad an'
I'll be in the way kids laugh when they're hungry an' they know
supper's ready. An' when our folks eat the stuff they raise an' live
in the house they build, why I'll be there.
- John Steinbeck, The Grapes of Wrath


pgpmvSIficmDP.pgp
Description: PGP signature


Bug#647018: how should we upload gnuradio into Debian

2011-11-16 Thread A. Maitland Bottoms
Oh yes, merging v3.5.0rc0 from the various existing
debian branches is not easy.

I gave up on that approach a while ago.

The trendy new way to build GnuRadio is using CMake.
For long term support that seems the way to proceed.

Antoine Beaupré anar...@debian.org writes:
  But that's the easy (ie. meta) part - it looks like there's going to
  be some work on necessary on the dependencies.

That is why I have UHD packages.
Here be dragons:
http://people.debian.org/~bottoms/#UHD

For my own purposes I have one jumbo Debian source package
that uses the new multiple tarball feature.
uhd_3.3.1.orig.tar.gz
uhd_3.3.1.orig-contrib-images.tar.gz
uhd_3.3.1-1.debian.tar.gz
uhd_3.3.1-1.dsc

uhd_3.3.1.orig.tar.gz can be built from the git tag.
uhd_3.3.1.orig-contrib-images.tar.gz is the contrib part,
generated binary files downloaded from 
http://files.ettus.com/uhd_releases/003_003_001/images-only/UHD-images-003.003.001.tar.gz
(it can be argued that this is not a valid source tarball.)

Perhaps I can package a free installer script that fetches
the compiled images into the free UHD package.

Or, perhaps I should have two separate source packages, one
free, and one contrib. Both share the uhd_3.3.1.orig.tar.gz
source tarball. That may give archive maintainers trouble.

-Maitland



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#647018: how should we upload gnuradio into Debian

2011-11-16 Thread Antoine Beaupré
Note that I have now a package that compiles under sid. I am not sure it
works in any shape or form, but if that's useful i could upload it to
experimental or something...

I agree with bdale that closing existing issues seems to make most
sense. Not sure about the need to remove it from unstable though, since
it's going to be replaced once we fix it up a bit anyways...

Mait: I am holding off further work until you let me know if you have
gone further ahead than this (ie. just getting the 3.5rc0 package to
compile).

Thanks for the feedback!

-- 
The world is a dangerous place, not because of those who do evil,
but because of those who look on and do nothing.
- Albert Einstein


pgp4EW9262s4C.pgp
Description: PGP signature