Bug#928375: Announce - swig-4.0.0

[Alan Woodland]

On Mon, 2 Sep 2019 23:02:32 +0200 Torsten Landschoff <
tors...@landschoff.net> wrote:
> On 5/3/19 10:37 AM, Mathieu Malaterre wrote:
> > Would be super nice to have swig 4 in Debian.
> 
> absolutely. And I did not notice for months. I'll have a go - maybe
this
> weekend, but no guarantees!

How did it go? Is there anything you'd like some extra effort from
another person on? I'm pretty invested in SWIG these days, so it'd be
great to see this release in Debian.

Alan

Bug#876908: Is blcr completely useless?

[Alan Woodland]

On 26 September 2017 at 20:28, Adrian Bunk  wrote:
>
> Source: blcr
> Version: 0.8.5-2.1
> Severity: serious
> Tags: buster sid
>
> As far as I can see:
> 1. blcr is dead upstream since 2013.
> 2. blcr requires both userspace and kernel parts.
> 3. The -dkms package is removed in unstable.
> 4. The beta version in experimental has an RC bug against
>the -dkms package that the module does not build
>with the jessie (sic) kernel.
>
> mpich is linked with the userspace library,
> but does that make any sense without the kernel part?

There was some activity in 2014 - 0.8.6 beta4, but the last I heard it
still had some issues with PPC64 that meant it wasn't worth uploading
to experimental and my plan was to hold out. Since there haven't been
any new versions released since then I'm inclined to agree. That'll
need a patch to the MPI build config though to stop linking against
and requiring the blcr userspace libraries as a precursor to actually
removing BLCR from sid.

In theory people could still be running old kernels to keep support
alive and if that's the case then we should try to avoid breaking
things, but certainly I've not actively been using BLCR in my work for
quite some time now.

Alan

Bug#857390: RM: libvisca -- RoQA; unmaintained; RC-buggy; very low popcon

[Alan Woodland]

On Fri, 10 Mar 2017 19:30:57 +0100 Mattia Rizzolo 
wrote:
> 
> 
> package: ftp.debian.org
> X-Debbugs-Cc: libvi...@packages.debian.org
>  
> Please remove libvisca from the archive.
>  
> It has a very low popcon (3), and the hardware it's design to talk to
is
> 
> 
> not produced anymore (or anyway, imho quite hard to buy).
> Despite upstream having released a new upstream "only" 4 years ago,
the
> 
> 
> last (and only) maintainer upload was in 2009.
No objections from me. I long since lost access to the hardware I had
which used this protocol and from memory at least one release after the
one I uploaded introduced some bugs on the only hardware I had and
changed little else of significance.

Alan

signature.asc
Description: This is a digitally signed message part

Bug#857390: RM: libvisca -- RoQA; unmaintained; RC-buggy; very low popcon

[Alan Woodland]

On Fri, 10 Mar 2017 19:30:57 +0100 Mattia Rizzolo 
wrote:
> 
> 
> package: ftp.debian.org
> X-Debbugs-Cc: libvi...@packages.debian.org
>  
> Please remove libvisca from the archive.
>  
> It has a very low popcon (3), and the hardware it's design to talk to
is
> 
> 
> not produced anymore (or anyway, imho quite hard to buy).
> Despite upstream having released a new upstream "only" 4 years ago,
the
> 
> 
> last (and only) maintainer upload was in 2009.
No objections from me. I long since lost access to the hardware I had
which used this protocol and from memory at least one release after the
one I uploaded introduced some bugs on the only hardware I had and
changed little else of significance.

Alan

signature.asc
Description: This is a digitally signed message part

Bug#699624: unblock: blcr/0.8.5-1

[Alan Woodland]

On 5 March 2013 20:56, intrigeri intrig...@debian.org wrote:
 Hi,

 Alan Woodland wrote (02 Feb 2013 13:23:22 GMT) :
 0.8.5-1 is the official upstream release that adds support for more recent 
 kernels
 and fixes a number of other bugs which were discovered. This version fixes 
 #638339 in
 the preferred way. #638339 was originally closed with a less than ideal 
 interim
 workaround which disabled the kernel module. It was subsequently reopened. 
 0.8.5-1 is
 a proper, upstream supported complete fix which has seen extensive testing in
 experimental and more widely in the community that use it

 unblock blcr/0.8.5-1

 Usually, a debdiff would ease the review process

[snip]

Just updated to 0.8.5-2 in unstable to fix for the latest 3.2 kernel
and a bug where one of the tests would fail if the -dev package wasn't
installed. A filtered debdiff against 0.8.5-1 is attached. Both
patches were supplied by the upstream author.

Thanks,
Alan


debdiff.filtered
Description: Binary data

Bug#699624: unblock: blcr/0.8.5-1

[Alan Woodland]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package blcr

0.8.5-1 is the official upstream release that adds support for more recent 
kernels and fixes a number of other bugs which were discovered. This version 
fixes #638339 in the preferred way. #638339 was originally closed with a less 
than ideal interim workaround which disabled the kernel module. It was 
subsequently reopened. 0.8.5-1 is a proper, upstream supported complete fix 
which has seen extensive testing in experimental and more widely in the 
community that use it

unblock blcr/0.8.5-1

-- System Information:
Debian Release: 6.0.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF8, LC_CTYPE=en_GB.UTF8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#638339: blcr-0.8.4-3 STILL boes not build/work with Linux 2.6.39 or later

[Alan Woodland]

On 18 December 2012 11:33, Paul Hargrove phhargr...@lbl.gov wrote:

 With all due respect to Alan, removing the blcr-dkms package from the build 
 is *not* a fix for the reported problem
 blcr: Does not build/work with Linux 2.6.39 or later.

I agree that this is less than ideal and will upload a new version as
soon as a suitable one is released.

 With the removal of the kernel module, the user space utilities in the 
 blcr-util package still all fail with recent kernels, since they require the 
 kernel module to function:

 code
 $ cr_checkpoint 0
 Checkpoint failed: support missing from kernel
 /code

The current upload is intended as a stop-gap to avoid the complete
removal from Wheezy, which would have necessitated changes to the MPI
packages and made future support harder. As it stands userspace fails
gracefully and it's simple enough to slot working kernelspace support
back in as/when.

Alan

 As announced in November on the BLCR mailing list 
 [https://hpcrdm.lbl.gov/pipermail/checkpoint/2012-November/000526.html], I am 
 working toward of goal of BLCR support for all current Linux kernel versions 
 by the end of this year.  In fact, I am expecting a Beta release of 
 blcr-0.8.5 later this week, for testing.

 -Paul

 --
 Paul H. Hargrove  phhargr...@lbl.gov
 Future Technologies Group
 Computer and Data Sciences Department
 Lawrence Berkeley National Laboratory



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

Bug#690458: RM: blcr/0.8.2-15 testing

[Alan Woodland]

On 7 November 2012 11:15, Julien Cristau jcris...@debian.org wrote:
 Hi Alan,

 On Sun, Oct 14, 2012 at 17:56:32 +0100, Alan Woodland wrote:

 There's a bug outstanding for dropping the Recommends to Suggests on
 the kernel module, that combined with removing the -dkms package
 should be sufficient for releasing without storing up pain for the
 future in my view.

 Any progress here?
I have prepared an upload, which drops the no longer functional -dkms
package and removes the recommends, but I'm still debating the merits
of adding a conflicts with the older versions of the -dkms package.

Alan


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

Bug#690458: RM: blcr/0.8.2-15 testing

[Alan Woodland]

On 7 November 2012 11:15, Julien Cristau jcris...@debian.org wrote:
 Hi Alan,

 On Sun, Oct 14, 2012 at 17:56:32 +0100, Alan Woodland wrote:

 There's a bug outstanding for dropping the Recommends to Suggests on
 the kernel module, that combined with removing the -dkms package
 should be sufficient for releasing without storing up pain for the
 future in my view.

 Any progress here?

I have prepared an upload, which drops the no longer functional -dkms
package and removes the recommends, but I'm still debating the merits
of adding a conflicts with the older versions of the -dkms package.

Alan


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

Bug#690458: RM: blcr/0.8.2-15 testing

[Alan Woodland]

On 14 October 2012 17:07, Ben Hutchings b...@decadent.org.uk wrote:
 On Sun, 2012-10-14 at 16:26 +0100, Adam D. Barratt wrote:
 Control: tags -1 + moreinfo

 On 14.10.2012 16:09, Ben Hutchings wrote:
  blcr is not usable with kernel version 2.6.39 or later (see bug
  #638339).  It will probably be fixed upstream at some point, but
  it cannot now be released in wheezy.  Therefore please remove
  from testing only.

 As mentioned at the BSP, the library has several reverse dependencies.
 Do we know whether dropping the kernel module and keeping the libraries
 would work? (CCing the maintainer).

 I'm not familiar with the package but from the description it appears
 that the library is only an interface to the kernel module, thus it
 won't be usable with current kernel packages.

 The changelog states that:

   * blcr-dkms still lacks support for 2.6.39/3.x kernels, but is useful to:
 - Users running newer kernels with stable
 - Users running older kernels with testing/unstable
 - Developers working on support for newer kernels

 However I don't think that any longterm kernel series older than 2.6.39
 will be supported for the lifetime of wheezy.  Further, userland
 packages in jessie will be allowed to assume a kernel version of 3.2 or
 later, so the next upgrade may fail badly.

 If the interface between the library and kernel module is stable (though
 I suspect not...) then the library might be usable with an updated
 module when that arrives.  Then it would seem reasonable to include the
 library only in wheezy.  But if not then I don't think either belongs in
 the release.

 [...]
 # Broken Build-Depends:
 mpich2: libcr-dev
 openmpi: libcr-dev

 These can be built without libcr, and indeed they are on those
 architectures where it is not available.

The library behaves sanely without the kernel module and dropping just
the -dkms package would be my preferred solution. Most binaries that
use BLCR are built to run in environments where the presence of the
kernel part isn't a given. Upstream doesn't have funding at the moment
to add support for newer kernels (they sound like it's something they
hope to return to though) and my attempts at developing a patch were
largely unsuccessful, i.e. worse than no patch at all.

I anticipate that the library itself ought to be useable when such a
patch arrives.

There's a bug outstanding for dropping the Recommends to Suggests on
the kernel module, that combined with removing the -dkms package
should be sufficient for releasing without storing up pain for the
future in my view.

Alan


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

Bug#668348: -amd64 kernel name suffix not understood by configure

[Alan Woodland]

tags 638339 help
forcemerge 638339 668348
thanks

On 11 April 2012 09:42, Steffen Moeller steffen_moel...@gmx.de wrote:
 Package: blcr-dkms
 Version: 0.8.4-2
 Severity: important

 checking the name lister (/usr/bin/nm -B) interface... (cached) BSD nm
 configure: error: --with-linux argument '3.2.0-2-amd64' is neither a kernel 
 version string nor a full path
 make[3]: *** [/var/lib/dkms/blcr/0.8.4/build/config-stamp] Error 1
 make[2]: *** [_module_/var/lib/dkms/blcr/0.8.4/build] Error 2
 make[1]: *** [sub-make] Error 2
 make: *** [all] Error 2
 make: Leaving directory `/usr/src/linux-headers-3.2.0-2-amd64'

-amd64 is understood fine, but there's no support for 3.x kernels yet
which is the real problem here. Patching configure to accept 3.x is
trivial, but I've not done that publicly yet because there are more
severe issues that fail less gracefully.

I had a go at fixing the issues (breaking changes within 3.x and
above) a while back, but failed and haven't managed to figure out why
yet.

Alan



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

Bug#638339: the problem still persists with 0.8.4

[Alan Woodland]

On 14 January 2012 11:52, Steffen Moeller steffen_moel...@gmx.de wrote:
 Package: blcr-dkms
 Version: 0.8.4-1
 Followup-For: Bug #638339

 DKMS make.log for blcr-0.8.4 for kernel 3.1.0-1-amd64 (x86_64)
 Sat Jan 14 12:43:27 CET 2012
 make: Entering directory `/usr/src/linux-headers-3.1.0-1-amd64'
 /var/lib/dkms/blcr/0.8.4/build/Kbuild:19: 
 /var/lib/dkms/blcr/0.8.4/build/module_files: No such file or directory
 cd /var/lib/dkms/blcr/0.8.4/build  env -i 
 PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/lib/dkms ./configure 
 --disable-maintainer-mode --with-linux=3.1.0-1-amd64 --with-installed-
 libcr --with-installed-util --with-components=modules --prefix=/usr  touch 
 /var/lib/dkms/blcr/0.8.4/build/config-stamp
 checking for a BSD-compatible install... /usr/bin/install -c
 [...]
 checking whether CXX='g++' acts like a C++ compiler... yes
 checking whether CXX='g++' matches wordsize of CC... yes
 checking for value of CR_SIGNUM... 64
 checking size of void *... (cached) 8
 checking compiler to build kernel modules... gcc (default)
 checking for BSD- or MS-compatible name lister (nm)... (cached) /usr/bin/nm -B
 checking the name lister (/usr/bin/nm -B) interface... (cached) BSD nm
 configure: error: --with-linux argument '3.1.0-1-amd64' is neither a kernel 
 version string nor a full path
 make[3]: *** [/var/lib/dkms/blcr/0.8.4/build/config-stamp] Error 1
 make[2]: *** [_module_/var/lib/dkms/blcr/0.8.4/build] Error 2
 make[1]: *** [sub-make] Error 2
 make: *** [all] Error 2
 make: Leaving directory `/usr/src/linux-headers-3.1.0-1-amd64'


 Please shout out for help if you need help with this.
 Thanks
 Steffen

If you're offering to help put together a new patch that would be
greatly appreciated. I have a patch that builds currently, but it
doesn't actually work (i.e. fails tests with kernel oops), so is worse
than no patch! I've not made much progress to tracking it down, but I
think both my path lookup and BKL removal handling is wrong.

[1] basically sums up the extent of my progress towards a patch.
Hacking the build to allow new version numbers is trivial, and I'm not
certain on the rest of the changes, so I've not let it loose.

Alan

[1] https://hpcrdm.lbl.gov/pipermail/checkpoint/2011-October/000335.html



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

Bug#645549: blcr: forgot to add armhf to the arch list :)

[Alan Woodland]

tags 645549 +confirmed

On 16 October 2011 22:32, Konstantinos Margaritis mar...@genesi-usa.com wrote:
 Package: blcr
 Version: 0.8.4-1
 Severity: important
 Tags: patch

 Forgot to actually add armhf to the arch list. The new package builds
 fine on armhf.

Whoops! I'll add it to the next upload.

Not quite sure when that'll be yet, I've not made as much progress
towards the 3.x kernel support as I'd hoped this weekend.

Alan



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

Bug#614560: Fwd: [Checkpoint] Announcing the release of BLCR 0.8.4

[Alan Woodland]

There's a new upstream release which adds support for more recent
kernels. I'm currently testing it with a view to making an upload
tonight.

-- Forwarded message --
From: Paul H. Hargrove phhargr...@lbl.gov
Date: 12 October 2011 02:03
Subject: [Checkpoint] Announcing the release of BLCR 0.8.4
To: checkpo...@lbl.gov checkpo...@lbl.gov


I am pleased to announce the release of Berkeley Lab Checkpoint/Restart
(BLCR) version 0.8.4, which is now available from the BLCR Downloads
page: http://ftg.lbl.gov/CheckpointRestart/CheckpointDownloads.html

Relative to 0.8.3 this release extends support to 2.6.38 kernels and
fixes minor bugs.  A summary of the user-visible changes in BLCR,
relative to 0.8.3, appears below in the form of an excerpt from the NEWS
file.

-Paul

0.8.4
---
October 11, 2011
Bug fix and expanded-support release.
 - This release fixes the following user-visible bugs and issues
   + This release adds support for vanilla Linux kernels up to 2.6.38.
   + This release adds support for recent RHEL5 kernels.
   + Occasional random failures on x86 have been identified and fixed.

--
Paul H. Hargrove                          phhargr...@lbl.gov
Future Technologies Group
HPC Research Department                   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory     Fax: +1-510-486-6900
___
BLCR mailing list
checkpo...@lbl.gov
https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/checkpoint



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

Bug#638339: [Checkpoint] Announcing the release of BLCR 0.8.4

[Alan Woodland]

On 12 October 2011 18:18, Paul H. Hargrove phhargr...@lbl.gov wrote:
 Alan,

I've had a quick go at putting together a patch for 3.0.0 this evening.

 We are aware of 2 non-trivial issues in 2.6.39
That seems to match what I've seen too, as these issues are the only
big things I've encountered so far and I have a building, semi-working
module.

I had some trouble with it reporting unmatched System.map between
running kernel and compiled module which I'm reasonably sure is a
false positive although I've not tracked it down.

 + removal of the BKL
I worked around this with a B BLCR L. It's too early though to say
if that's sufficient given I currently can't pass all the testsuite.

 + changes to the path lookup code.
I've made some progress towards this. It seems like the right thing
to do now is use struct path in a lot of places where struct nameidata
was correct previously. I've got a showstopper bug with my updated
cr_mknod though which suggests I haven't quite got the bigger picture
for the new code yet though.

I'm not out of ideas yet for the path lookup problems. I'll try and
fix this up and produce something worth sharing.

Alan



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

Bug#622720: blcr: please add support for armv7 cpus (armhf)

[Alan Woodland]

On 28 September 2011 16:19, Konstantinos Margaritis
mar...@genesi-usa.com wrote:
 On 14 April 2011 11:58, Alan Woodland awoodl...@debian.org wrote:
 tags 622720 +confirmed
 tags 622720 +pending
 thanks

 On 14 April 2011 12:21, Konstantinos Margaritis mar...@genesi-usa.com 
 wrote:
 Source: blcr
 Severity: important
 Tags: patch

 This patch is a backport from the Ubuntu armel package. Debian armhf
 uses thumb2 just as Ubuntu armel, so it has the same build problems.
 Please consider applying the patch.

 Agreed, I've added this patch to my forthcoming upload.

 Hi,

 any news on this? It's been ~5 months since the bug report.

This one's slipped me by. The major patch I was working on had
problems that meant it wasn't suitable for release. A 0.8.3 upload is
on my radar, however it basically just rolls all the patches Debian
was running into an official release. I'll try and check it out soon,

Alan



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

Bug#638339: Confirmed

[Alan Woodland]

tags 638339 +confirmed
thanks

Hi,

Thanks for this report. I'm aware of this issue, but it may be a while
until a fix is forthcoming since kernel support is lagging behind even
before the 3.0 series. I hope to have this fixed in time to release with
wheezy though.

There's a new release out yesterday, but for a Debian perspective it
changes very little other than the version number since we already
included almost all of the diff between 0.8.2 and 0.8.3 as patches.

Alan



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

Bug#626352: arguments for bug

[Alan Woodland]

On 12 May 2011 21:59, Tomáš Hnyk tomash...@gmail.com wrote:
 Nice to hear that others consider my decision for recommends reasonable.
 The original poster might like to reread the guidelines when to use
 Depends and when Recommends.

 Do you mean this:
 http://www.debian.org/doc/debian-policy/ch-relationships.html ?


 Depends
 This declares an absolute dependency
 The Depends field should be used if the depended-on package is required for
 the depending package to provide a significant amount of functionality.

 Recommends

 This declares a strong, but not absolute, dependency.

 The Recommends field should list packages that would be found together with
 this one in all but unusual installations.

 The fact that many x-data packages are
 Depends is just because they fit the criterion that the package x really
 does not work without x-data.  This is not the case for texmaker.

 Well, at least for the translations, I think that amounts to significant
 amount of functionality - consider someone who only speaks French and uses
 her system in French. If she installs with --no-install-recommends, she will
 get a program with interface she does not understand. Therefore, she will
 not be able to use the program or only with utmost difficulty. Therefore,
 the program will not be functioning for her. I think that is the reasoning
 of many of the x packages.

 So I will once again propose to split texmaker-data into texmaker-data
 depending on texmaker and including the icons and the translations and
 texmaker-docs being recommended by texmaker.

I sponsored the original upload of this package and IIRC the split was
largely based on arch: any vs. arch: all with recommends instead of
depends selected because it's neither broken nor useless without the
contents of -data, which in my view matched the description of
strong, but not absolute.

The translations issue is an interesting one that perhaps warrants
further discussion -devel and/or explicit mention in policy. (I'm not
aware of any formal consensus). If the goal of --no-install-recommends
is minimise disk space then requiring all of the translations would
seem to be at odds with it. Then again not shipping the translations
seems to be at odds with the basic principles of userfriendlyness and
play nicely with non-English languages. Is --no-install-recommends
pretty much equivalent to --no-unneeded-user-friendlyness though?

I have no strong opinions either way, but I'm interested in the
broader question from a policy POV.

Alan



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

Bug#624343: Possible workaround?

[Alan Woodland]

I've hit this bug from a different scenario - I have one SATA disk and
one external USB disk in a root on RAID1+LVM setup. During boot it
seems the USB device often doesn't settle before the md device gets to
being assembled, with the net result that it boots degraded, with the
USB device missing. No big deal I figured, I can always re-add the USB
disk later and let it re-sync as required. Until I saw the discussion
on this bug report I'd assumed that it was only a performance warning
and not a potential data loss scenario though.

If I've understood this correctly one possible workaround for this
(for the time being) would be to add a boot parameter that lets you
artificially limit max_hw_sectors? In this case it seems forcing all
md devices down from 248 to 240 would probably avoid potential data
loss issues without large performance degradation or big intrusive
changes. Is that sane?

Alan



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

Bug#622720: blcr: please add support for armv7 cpus (armhf)

[Alan Woodland]

tags 622720 +confirmed
tags 622720 +pending
thanks

On 14 April 2011 12:21, Konstantinos Margaritis mar...@genesi-usa.com wrote:
 Source: blcr
 Severity: important
 Tags: patch

 This patch is a backport from the Ubuntu armel package. Debian armhf
 uses thumb2 just as Ubuntu armel, so it has the same build problems.
 Please consider applying the patch.

Agreed, I've added this patch to my forthcoming upload.

Alan



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

Bug#614560: blcr-dkms: Error! Bad return status for module build on kernel: 2.6.37-1-amd64 (x86_64)

[Alan Woodland]

On -10/01/37 20:59, Mathieu Malaterre wrote:
 Package: blcr-dkms
 Version: 0.8.2-15
 Severity: important
 
 
 Hi,
 
   I cannot install blcr-dkms on my system:
 
[snip]
 Building module:
 cleaning build area
 make KERNELRELEASE=2.6.37-1-amd64 -C /lib/modules/2.6.37-1-amd64/build 
 M=/var/lib/dkms/blcr/0.8.2/build..(bad exit status: 2)
 
 Error! Bad return status for module build on kernel: 2.6.37-1-amd64 (x86_64)
 Consult the make.log in the build directory
 /var/lib/dkms/blcr/0.8.2/build/ for more information.

Hi,

The currently packaged version of BLCR doesn't have support for kernels
version 2.6.35 or more recent. I have a patch for this in testing with
the upstream authors currently. I hope to be able to make an upload with
a blessed patch in the not too distant future.

Alan



signature.asc
Description: OpenPGP digital signature

Bug#597601: FTBFS : cr_atomic.h: No such file or directory

[Alan Woodland]

For some reason CR_LIBARCH is getting set to i686 in pbuilder on amd64
and i386 on real i386 hardware. Looking into it further.

Alan



signature.asc
Description: OpenPGP digital signature

Bug#597601: FTBFS : cr_atomic.h: No such file or directory

[Alan Woodland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

tags 597601 +confirmed
thanks

On -10/01/37 20:59, Jonathan KLEE wrote:

 I'm trying to build blcr (0.8.2-13) on x86_64 from scratch with pbuilder but
 I have the following error :
 
 libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../libcr -I.. -D_GNU_SOURCE
 -D_REENTRANT -I../include -I../../include -I../../libcr/arch/i686/ -Wall
 -Wno-unused-function -Wall -g -O2 -MT libcr_la-cr_async.lo -MD -MP -MF
 .deps/libcr_la-cr_async.Tpo -c ../../libcr/cr_async.c  -fPIC -DPIC -o
 .libs/libcr_la-cr_async.o
 In file included from ../../libcr/cr_async.c:37:
 ../../libcr/cr_private.h:63:23: error: cr_atomic.h: No such file or
 directory
 In file included from ../../libcr/cr_private.h:65,
  from ../../libcr/cr_async.c:37:
 ../../libcr/cr_rb_lock.h:47: error: expected '=', ',', ';', 'asm' or
 '__attribute__' before 'cri_rb_lock_t'
 ../../libcr/cr_rb_lock.h:52: error: expected ')' before '*' token
 ../../libcr/cr_rb_lock.h:61: error: expected ')' before '*' token
 ../../libcr/cr_rb_lock.h:74: error: expected ')' before '*' token
 

The cause of this seems to be a faulty value for CR_LIBARCH. I can
reproduce this now, so I hope to release a fix shortly.

Alan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyh8iAACgkQ1FNW1LDdr0LqOQCglP0Y4BImxvvzbLLMrME3iMYI
YuMAn3zMG1zH4DI7RGodTbAMmOeBWAmR
=I+bs
-END PGP SIGNATURE-



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

Bug#597601: Building in a chroot

[Alan Woodland]

tags 597601 +patch
tags 597601 +pending
thanks

Hi,

I'm having some trouble getting x86 builds to work in an x86 chroot
hosted on a x86_64 machine. The fault seems to stem from the fact that
CR_LIBARCH is set to i686, not i386, which causes the building of the
library later on to search in libcr/arch/i686 for cr_atomic.h, which
doesn't exist.

The trivial fix of changing CR_ARCH32 = i686 to i386 in configure.ac
fixes the problem for x86 builds in the chroot, but breaks multiarch
support because when configure is called as sub-configure for the
32bit library it ends up with i386 as CR_ARCH, which causes the
unsupported architecture message to get displayed.

The minimally intrusive fix I've come up with is:

Index: blcr-0.8.2/configure.ac
===
--- blcr-0.8.2.orig/configure.ac2010-09-28 14:58:10.0 +0100
+++ blcr-0.8.2/configure.ac 2010-09-28 15:13:29.0 +0100
@@ -215,6 +215,7 @@
 ;;
   x86_64)
 CR_ARCH32=i686
+CR_LIBARCH32=i386
 cr_wordsize=8
 ;;
   ppc64|powerpc64)
@@ -683,7 +684,7 @@
 CR_LIBARCH=$CR_ARCH
 if test $ac_cv_sizeof_void_p != $cr_wordsize; then
   if test $cr_wordsize = 8; then
-CR_LIBARCH=$CR_ARCH32
+CR_LIBARCH=$CR_LIBARCH32
   else
 AC_MSG_ERROR([CC='$CC' yields sizeof(void *) =
$ac_cv_sizeof_void_p when expecting $cr_wordsize.$clue])
   fi


Is this sane? It seems to work on my test systems, but that doesn't
prove anything.

Thanks,
Alan



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

Bug#573112: Testing a patch now

[Alan Woodland]

tags 573112 +patch
thanks

I'm testing a newer patch from upstream which adds support for newer kernels.

Alan



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

Bug#556135: #556135: xul-ext-weave

[Alan Woodland]

On 20 May 2010 14:05, Alexander GQ Gerasiov g...@debian.org wrote:
 Hello, Michael.

 On Thu, 20 May 2010 14:24:08 +0200
 Michael Fladischer mich...@fladi.at wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi,

 I saw your response on #556135 offering help. There is a new upload
 for Weave 1.2.3 on mentors.d.n:
 Ok, lets wait a little bit, may be Alan have any comments.


 http://mentors.debian.net/debian/pool/main/w/weave/weave_1.2.3-1.dsc

 If your offer for review is still up I'd appreciate if you could take
 a look at it.
 I'd like to see README.source inside debian dir with (short) description
 of get-orig-source target and situation with crypto part.
 And links to GPL/LGPL in copyright file. (In the section describing
 extension's license.)

 It would be nice if you join alioth's pkg-mozext team to maintain the
 package there. Just register, ask for inclusion to team, create
 repository and upload in it. (And fix Maintainer/Uploader fields in
 control)


 I have removed the obsolete native crypto part from the source-package
 because 1.2.3 is the first release which uses javascript for this
 part:
 So it (original extension) uses javascript by default? Or it uses native
 code when possible to improve performance?

 Please ignore my last mail as I just discovered that the native
 library cannont be removed yet without breaking weave sync. Thus I
 removed my package from mentors.d.n.
 Oh, I see. That's ok. So will you make this package arch-dependent with
 compilation on native crypto code?
My main concern now is how we support this for the duration of
squeeze. It seems likely that at some point the version we ship will
cease to function with the mozilla.org servers, in which case the
package either needs updating or removing. We could of course work
around it by packaging the server-side components as well, but I
suspect most users will be interested in syncing with mozilla.org, not
running their own server.

Alan



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

Bug#573112: It is just a 2.6.33 problem

[Alan Woodland]

On 13 April 2010 07:26, Yves Caniou yves.can...@ens-lyon.fr wrote:
 Le Thursday 25 March 2010 19:34:35 Alan Woodland, vous avez écrit :
 retitle 573112 Please support 2.6.33 kernels
 tags 573112 +confirmed
 thanks

 I've taken a closer look at this problem and can confirm that it is
 just a problem with 2.6.33. Quite a few files have moved around. I've
 got partial patches for a few of the changes, but I just noticed the
 upstream author apparently already has patches which enable build but
 hang at run time during testing. I'll continue to look into this
 further.

 Alan

 Hello,

 I've seen the update of the  libcr packages from 8.2.10 to 8.2-11.
 I don't know about the changelog since apt-listchanges gives no information.
 I have updated my kernel to 2.6.33.2 since last report, but the update leads
 to the same problem:
 error: Could not find a directory [...]
0.8.2-11 doesn't fix the bug, but does push out several small changes
I'd been wanting to make that means now debug symbols and the
testsuite are built (this facilitates testing of a number of issues).

Upstream has produced a patch which compiles, but doesn't work. I've
had a look at debugging this quickly but haven't made any significant
progress yet.

Alan



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

Bug#556135: Uploaded my package

[Alan Woodland]

On 29 March 2010 15:04, Michael Fladischer mich...@fladi.at wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 I've uploaded my package to mentors.debian.net:

 http://mentors.debian.net/debian/pool/main/w/weave/weave_1.2b2-1.dsc

 It works well and I was able to seamlessly replace the user-installed
 Weave addon with the packaged one (1.1 - 1.2b2).

Just got back from holiday, will hopefully get a chance to take care
of things in the next week or so.

Alan



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

Bug#573112: It is just a 2.6.33 problem

[Alan Woodland]

retitle 573112 Please support 2.6.33 kernels
tags 573112 +confirmed
thanks

I've taken a closer look at this problem and can confirm that it is
just a problem with 2.6.33. Quite a few files have moved around. I've
got partial patches for a few of the changes, but I just noticed the
upstream author apparently already has patches which enable build but
hang at run time during testing. I'll continue to look into this
further.

Alan



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

Bug#556135: ITP #556135 Weave

[Alan Woodland]

On 22 March 2010 19:05, Fladischer Michael
michael.fladisc...@medunigraz.at wrote:
 Hi!

 I saw your response on ITP #556135 saying that you intend to package
 Mozilla Labs Weave and I wanted to ask you on how far your progress is.

 Maybe you want to take a look at my approach on packaging Weave. The
 package is currently in my private repository because there are still
 some warnings left with dpkg-shlibdeps.
 It is built using source format 3.0 and cdbs (not sure if dh would be
 better) with two small patches of which one is optional and only
 contained to fit my environment.

 Now to the point, my package:
 http://debian.fladi.at/pool/main/w/weave/weave_1.1+hga350f49cbeb2-1.dsc

 Maybe you find it useful for inclusion in the official Debian repository
 or at least a starting point for a proper package.
Hi,

My efforts tailed off a bit once I had a package that seemed to build
from source correctly but didn't actually work (some function was
returning 0 that wasn't expected at run time). I've been rather busy
with work lately and haven't had a chance to touch it since, but I'll
definitely be picking this one up again in a week or two.

I've not looked at license issues yet and I'm slightly concerned about
long term support for older releases of weave - this needs to be
checked with upstream and/or the server side components packaging also
before it is suitable to be included in a release.

I'm not sure if you're a DD/DM, would you be interested in
co-maintaining this with the mozilla extensions team?

Thanks,
Alan



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

Bug#573112: blcr-dkms: Does not install: configuration problem due to missing UTS_RELEASE

[Alan Woodland]

On 9 March 2010 02:24, Yves Caniou yves.can...@ens-lyon.fr wrote:
 Package: blcr-dkms
 Version: 0.8.2-9
 Severity: normal

 Compilation with the line provided in the package (but with full path for the 
 manually installed and running kernel)
 cd /var/lib/dkms/blcr/0.8.2/build  env -i
 PATH=.:..:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/sbin:/sbin:/usr/lib/dkms
 ./configure --disable-maintainer-mode --with-linux=/usr/src/linux-2.6.33 
 --with-installed-libcr --with-installed-util --with-components=modules 
 --prefix=/usr
  touch /var/lib/dkms/blcr/0.8.2/build/config-stamp

 makes the following error:
 configure: error: Directory /usr/src/linux-2.6.33 does not appear to contain 
 a Linux kernel build

Hmm not quite sure what's going on there. Is /usr/src/linux-2.6.33
literally the directory you built the kernel image in? (i.e. wget
source, extract, configure, build, boot?)

2.6.33 isn't supported by BLCR yet, but this hasn't hit the point
where I'd expect to be seeing the unsupported error message. I'll take
a look at reproducing this situation so it works correctly for no
Debian package kernels with DKMS. It may take a while for me to get
around to it though.

Alan



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

Bug#573112: blcr-dkms: Does not install: configuration problem due to missing UTS_RELEASE

[Alan Woodland]

On 9 March 2010 11:29, Yves Caniou yves.can...@ens-lyon.fr wrote:
 Le Tuesday 09 March 2010 12:21:49 Alan Woodland, vous avez écrit :
 On 9 March 2010 02:24, Yves Caniou yves.can...@ens-lyon.fr wrote:
  Package: blcr-dkms
  Version: 0.8.2-9
  Severity: normal
 
  Compilation with the line provided in the package (but with full path for
  the manually installed and running kernel) cd
  /var/lib/dkms/blcr/0.8.2/build  env -i
  PATH=.:..:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/
 usr/sbin:/usr/bin:/sbin:/bin:/usr/sbin:/sbin:/usr/lib/dkms ./configure
  --disable-maintainer-mode --with-linux=/usr/src/linux-2.6.33
  --with-installed-libcr --with-installed-util --with-components=modules
  --prefix=/usr  touch /var/lib/dkms/blcr/0.8.2/build/config-stamp
 
  makes the following error:
  configure: error: Directory /usr/src/linux-2.6.33 does not appear to
  contain a Linux kernel build

 Hmm not quite sure what's going on there. Is /usr/src/linux-2.6.33
 literally the directory you built the kernel image in? (i.e. wget
 source, extract, configure, build, boot?)

 2.6.33 isn't supported by BLCR yet, but this hasn't hit the point
 where I'd expect to be seeing the unsupported error message. I'll take
 a look at reproducing this situation so it works correctly for no
 Debian package kernels with DKMS. It may take a while for me to get
 around to it though.

 Alan

 /usr/src/linux-2.6.33 is the directory where I made (make oldconfig  make
 bzImage  make modules  make modules_install  make install). I also have
 the symbolic link /usr/src/linux as shown there:
 /usr/src $l /usr/src/linux
 lrwxrwxrwx 1 root root 12 févr. 25 06:15 /usr/src/linux - linux-2.6.33
 Tell me if I can help...

What does config.log say? Normally there will be something more
explicit about the configuration error in there.

Alan



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

Bug#573112: blcr-dkms: Does not install: configuration problem due to missing UTS_RELEASE

[Alan Woodland]

On 9 March 2010 13:26, Yves Caniou yves.can...@ens-lyon.fr wrote:
 Le Tuesday 09 March 2010 14:12:50 Alan Woodland, vous avez écrit :
 On 9 March 2010 11:29, Yves Caniou yves.can...@ens-lyon.fr wrote:
  Le Tuesday 09 March 2010 12:21:49 Alan Woodland, vous avez écrit :
  On 9 March 2010 02:24, Yves Caniou yves.can...@ens-lyon.fr wrote:
   Package: blcr-dkms
   Version: 0.8.2-9
   Severity: normal
  
   Compilation with the line provided in the package (but with full path
   for the manually installed and running kernel) cd
   /var/lib/dkms/blcr/0.8.2/build  env -i
   PATH=.:..:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/local/bi
  n:/ usr/sbin:/usr/bin:/sbin:/bin:/usr/sbin:/sbin:/usr/lib/dkms
   ./configure --disable-maintainer-mode
   --with-linux=/usr/src/linux-2.6.33
   --with-installed-libcr --with-installed-util --with-components=modules
   --prefix=/usr  touch /var/lib/dkms/blcr/0.8.2/build/config-stamp
  
   makes the following error:
   configure: error: Directory /usr/src/linux-2.6.33 does not appear to
   contain a Linux kernel build
 
  Hmm not quite sure what's going on there. Is /usr/src/linux-2.6.33
  literally the directory you built the kernel image in? (i.e. wget
  source, extract, configure, build, boot?)
 
  2.6.33 isn't supported by BLCR yet, but this hasn't hit the point
  where I'd expect to be seeing the unsupported error message. I'll take
  a look at reproducing this situation so it works correctly for no
  Debian package kernels with DKMS. It may take a while for me to get
  around to it though.
 
  Alan
 
  /usr/src/linux-2.6.33 is the directory where I made (make oldconfig 
  make bzImage  make modules  make modules_install  make install). I
  also have the symbolic link /usr/src/linux as shown there:
  /usr/src $l /usr/src/linux
  lrwxrwxrwx 1 root root 12 févr. 25 06:15 /usr/src/linux - linux-2.6.33
  Tell me if I can help...

 What does config.log say? Normally there will be something more
 explicit about the configuration error in there.

 The first error appears 2 times with:
 configure:7917: gcc -E  conftest.c
 conftest.c:15:28: error: ac_nonexistent.h: No such file or directory

 Then a warning:
 configure:8616: gcc -c -g -O2  -fno-rtti -fno-exceptions conftest.c 5
 cc1: warning: command line option -fno-rtti is valid for C++/ObjC++ but not
 for C

 Then again the error with the missing file with:
 configure:13576: g++ -E  conftest.cpp
 conftest.cpp:28:28: error: ac_nonexistent.h: No such file or directory

 And finally with:
 configure:18642: result: no UTS_RELEASE could be extracted
 configure:18656: error: Directory /usr/src/linux-2.6.33 does not appear to
 contain a Linux kernel build
Is it possible to see the whole config.log from this? There's
something weird there, but I can't say what so far.

Alan



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

Bug#572021: openmpi-checkpoint: orte-checkpoint is not installed by package, ompi-checkpoint is a link to it

[Alan Woodland]

2010/3/1 Fernando Tarlá Cardoso Lemos fernando...@gmail.com:
 Package: openmpi-checkpoint
 Version: 1.4.1-1
 Severity: grave
 Justification: renders package unusable


 /usr/bin/ompi-checkpoint is a symlink to orte-checkpoint, but orte-checkpoint
 isn't installed by this package.

Does indeeed seem to be missing:
http://packages.debian.org/sid/amd64/openmpi-checkpoint/filelist

 Likewise, ompi-restart is a symlink to orte-restart, but orte-restart isn't
 installed by this package either.

 Those two binaries are essential to OpenMPI checkpointing and their absence
 renders the package unusable.

 My suggested fix is to add /usr/bin/orte-checkpoint and /usr/bin/orte-restart
 to the list of files that are installed by this package.

Any ideas where these got to? They were definitely included in the
first version of openmpi-checkpoint that was uploaded...

Alan



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

Bug#481951: Patch?

[Alan Woodland]

There seems to be patches for this issue:
http://code.google.com/p/distcc/issues/detail?id=34#c7
Are they sane/sensbile?

Is this still a problem in Sid/Squeeze? It certainly exists in Lenny
still, but if a subsequent release has been packaged this bug could
probably be closed or tagged appropriately.

Alan



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

Bug#572229: openmpi-checkpoint should depend on blcr-util

[Alan Woodland]

2010/3/2 Fernando Tarlá Cardoso Lemos fernando...@gmail.com:
 Package: openmpi-checkpoint
 Version: 1.4.1-1
 Severity: important


 openmpi-checkpoint does not currently depend on blcr-util. However, 
 ompi-restart will segfault unless blcr-util (upstream bug maybe, I reported 
 to the OpenMPI users mailing list, still got no reply).

[snip]


 Note that brcl-util provides binaries like cr_restore, cr_checkpoint, etc. 
 One would think ompi-checkpoint/ompi-restart uses only libcr directly, but 
 that doesn't seem to be the case for ompi-restart.


I'm pretty sure it at least was the case that restart did just use
libcr directly, without calling any of the utils, hence my not setting
the dependency originally. I wonder if this is a bug or a feature now?

Alan



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

Bug#572229: openmpi-checkpoint should depend on blcr-util

[Alan Woodland]

On 2 March 2010 14:59, Fernando Lemos fernando...@gmail.com wrote:
 2010/3/2 Alan Woodland awoodl...@debian.org:
 2010/3/2 Fernando Tarlá Cardoso Lemos fernando...@gmail.com:
 Package: openmpi-checkpoint
 Version: 1.4.1-1
 Severity: important


 openmpi-checkpoint does not currently depend on blcr-util. However, 
 ompi-restart will segfault unless blcr-util (upstream bug maybe, I reported 
 to the OpenMPI users mailing list, still got no reply).

 [snip]


 Note that brcl-util provides binaries like cr_restore, cr_checkpoint, etc. 
 One would think ompi-checkpoint/ompi-restart uses only libcr directly, but 
 that doesn't seem to be the case for ompi-restart.


 I'm pretty sure it at least was the case that restart did just use
 libcr directly, without calling any of the utils, hence my not setting
 the dependency originally. I wonder if this is a bug or a feature now?

 Alan


 Yeah, I find it weird too. Here's my latest post to the OpenMPI users
 mailing list:

 http://www.open-mpi.org/community/lists/users/2010/03/12199.php

 Maybe it does not use cr_* directly but blcr-util provides something
 else that ompi-restart requires? Either way, I don't think
 ompi-restart is supposed to segfault...
blcr-util doesn't provide anything other than /usr/bin/cr_* and
documentation. I hope it doesn't anyway, (and there's no surprises in:
http://packages.debian.org/sid/amd64/blcr-util/filelist) it's designed
such that an application which uses libcr directly doesn't have to
pull in anything other than libcr.

 If you prefer, I can run my tests with the openmpi-checkpoint after
 #572021 is fixed and then report back whether or not blcr-util is
 needed.

I think I'd like to get to the bottom of why it segaults (stacktrace).
I'm unlikely to be able to commit significant amounts of time to this
until after 23rd of March though. A full backtrace or possibly even
just the final output from strace might be quite enlightening though.

Alan



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

Bug#524746: Fwd: Sponsor for player

[Alan Woodland]

On 10 February 2010 07:18, M. van Brummelen mart...@brumit.nl wrote:
 Hi,

 It got rejected.

If you'd like me to sponsor another upload, which fixes these problems
as well I'm happy to do so.

Alan

 Reject Reasons:
 robot-player: lintian output: 'arch-dependent-file-in-usr-share
 ./usr/share/player/examples/libplayerc++/camera', automatically rejected
 package.
 robot-player: If you have a good reason, you may override this lintian tag.
 robot-player: lintian output: 'arch-dependent-file-in-usr-share
 ./usr/share/player/examples/libplayerc++/clientgraphics', automatically
 rejected
 package.
 robot-player: If you have a good reason, you may override this lintian tag.
 robot-player: lintian output: 'arch-dependent-file-in-usr-share
 ./usr/share/player/examples/libplayerc++/example0', automatically rejected
 package.
 robot-player: If you have a good reason, you may override this lintian tag.
 robot-player: lintian output: 'arch-dependent-file-in-usr-share
 ./usr/share/player/examples/libplayerc++/example1', automatically rejected
 package.
 robot-player: If you have a good reason, you may override this lintian tag.
 robot-player: lintian output: 'arch-dependent-file-in-usr-share
 ./usr/share/player/examples/libplayerc++/example2', automatically rejected
 package.
 robot-player: If you have a good reason, you may override this lintian tag.
 robot-player: lintian output: 'arch-dependent-file-in-usr-share
 ./usr/share/player/examples/libplayerc++/example3', automatically rejected
 package.
 robot-player: If you have a good reason, you may override this lintian tag.
 robot-player: lintian output: 'arch-dependent-file-in-usr-share
 ./usr/share/player/examples/libplayerc++/example4', automatically rejected
 package.
 robot-player: If you have a good reason, you may override this lintian tag.
 robot-player: lintian output: 'arch-dependent-file-in-usr-share
 ./usr/share/player/examples/libplayerc++/goto', automatically rejected
 package.
 robot-player: If you have a good reason, you may override this lintian tag.
 robot-player: lintian output: 'arch-dependent-file-in-usr-share
 ./usr/share/player/examples/libplayerc++/grip', automatically rejected
 package.
 robot-player: If you have a good reason, you may override this lintian tag.
 robot-player: lintian output: 'arch-dependent-file-in-usr-share
 ./usr/share/player/examples/libplayerc++/laserobstacleavoid',
 automatically rejected
 package.
 robot-player: If you have a good reason, you may override this lintian tag.
 robot-player: lintian output: 'arch-dependent-file-in-usr-share
 ./usr/share/player/examples/libplayerc++/ptz', automatically rejected
 package.
 robot-player: If you have a good reason, you may override this lintian tag.
 robot-player: lintian output: 'arch-dependent-file-in-usr-share
 ./usr/share/player/examples/libplayerc++/randomwalk', automatically rejected
 package.
 robot-player: If you have a good reason, you may override this lintian tag.
 robot-player: lintian output: 'arch-dependent-file-in-usr-share
 ./usr/share/player/examples/libplayerc++/sonarobstacleavoid',
 automatically rejected
 package.
 robot-player: If you have a good reason, you may override this lintian tag.
 robot-player: lintian output: 'arch-dependent-file-in-usr-share
 ./usr/share/player/examples/libplayerc++/speech', automatically rejected
 package.
 robot-player: If you have a good reason, you may override this lintian tag.
 robot-player: lintian output: 'arch-dependent-file-in-usr-share
 ./usr/share/player/examples/libplayerc++/speech_cpp_client', automatically
 rejected
 package.
 robot-player: If you have a good reason, you may override this lintian tag.
 robot-player: lintian output: 'arch-dependent-file-in-usr-share
 ./usr/share/player/examples/libplayerc++/wallfollow', automatically rejected
 package.
 robot-player: If you have a good reason, you may override this lintian tag.
 robot-player: lintian output: 'arch-dependent-file-in-usr-share
 ./usr/share/player/examples/libplayerc/simple', automatically rejected
 package.
 robot-player: If you have a good reason, you may override this lintian tag.
 robot-player: lintian output: 'arch-dependent-file-in-usr-share
 ./usr/share/player/examples/libplayerc/speech_c_client', automatically
 rejected
 package.
 robot-player: If you have a good reason, you may override this lintian tag.

 Regards,
 Martijn van Brummelen


 On Thu, Nov 12, 2009 at 05:36:47PM +, Alan Woodland wrote:
 Hi,

 I've just sponsored an NMU for player to DELAYED/7, which makes only
 one change, a fix for the RC bug #524746. If you'd like me to cancel
 this to give you more time drop me an email.

 So what happened with your upload ? We are three month later and this bug
 is
 still open.

 Cheers,
 --
 Bill. ballo...@debian.org

 Imagine a large red swirl here.










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

Bug#556135: Working on a package now

[Alan Woodland]

retitle 556135 ITP: xul-ext-weave -- Syncronize personal data between
Mozilla browsers
owner 556135 !
thanks

I'm using weave myself quite a lot now, so I'll take a look at
providing this soon.

Alan



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

Bug#560983: Help please?

[Alan Woodland]

tags 560983 +help
tag 557310 pending
thanks

Hi,

I had a look at doing this today and it's not as trivial as I'd hoped.
If someone else wanted to take a look at this I'd very much appreciate
it.

Thanks,
Alan



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

Bug#542490: [Pkg-mozext-maintainers] RFS: tabmixplus 0.3.8.2-1 (was: packaging tabmixplus)

[Alan Woodland]

2010/1/5 Benjamin Drung bdr...@ubuntu.com:
 Am Dienstag, den 05.01.2010, 17:34 +0100 schrieb Christoph Anton Mitterer:
 Sorry for the late reply,..

 No problem.

 On Tue, 2009-12-22 at 18:29 +0100, Benjamin Drung wrote:
  * The license block (BEGIN LICENSE BLOCK to END LICENSE BLOCK)
 needs
  to be reformatted.
 What do you mean? Is it ok like this?

 Yes, that's what I wanted. (License text without the borders)

 Thanks for the copyright file. I have applied it. The package is now
 ready for upload.

 Can a DD of the mozext team sponsor this package? It can be check out
 from the git repo

 http://git.debian.org/?p=pkg-mozext/tabmixplus.git;a=summary

 or from mentors.debian.net

 http://mentors.debian.net/debian/pool/main/t/tabmixplus/tabmixplus_0.3.8.2-1.dsc

 Thanks.

Will take a look at it quickly now and upload if there aren't any problems.

Alan



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

Bug#562080: [Pkg-mozext-maintainers] Bug#562080: xul-ext-traybiff: mail LED notification does not work on Asus laptops

[Alan Woodland]

2009/12/22 Jakub Adam jakub.a...@ktknet.cz:
 Subject: xul-ext-traybiff: mail LED notification does not work on Asus
 laptops
 Package: xul-ext-traybiff
 Version: 1.2.3-7
 Severity: normal
 Tags: patch

 This plugin is able to autodetect LEDs present on some laptops and use them
 for notifications on new mail
 arrival (in addition to icon in system panel). Unfortunately this
 functionality will not work on
 Asus laptops, because the position of special file used to control the LED
 state changed.
 Following little patch can be used to fix the issue:

 --- traybiff-1.2.3/components/nsMessengerFreeDesktopIntegration.cpp
 2007-05-19 10:01:55.0 +0200
 +++ nsMessengerFreeDesktopIntegration.cpp       2009-12-22
 00:29:35.0 +0100
 @@ -93,6 +93,8 @@
  const char* HW_INDICATOR_CONTROL_FILENAMES[] = {
        // ASUS laptop led on Linux
        /proc/acpi/asus/mled,
 +       // ASUS laptop led on Linux, newer interface
 +       /sys/class/leds/asus::mail/brightness,
        // ACER New Mail led on Linux
        /proc/driver/acerhk/led
  };

Thanks for the patch - I don't have one of these laptops myself, so
I'm reliant on users for bug reports about things like this. I'll make
sure it gets included in the next upload.

 Also, to work properly, file /sys/class/leds/asus::mail/brightness must be
 writable by regular users.
 Permissions must be changed after every boot and this can be done by
 following init script

I don't think an init script is the right way (tm) to fix this. The
general opinion on #debian-devel seems to be that a setuid helper
would be the 'quick fix' although a longer term fix would be to expose
a stable, clean interface via a character device in /dev, which could
then be granted write access to users via udev. I don't have time
right now to do this (and holding off/waiting probably helps get the
interface design right too), but I'll try and take a look at it later
on.

Alan



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

Bug#561365: requires libtool to install

[Alan Woodland]

tags 561365 +confirmed
thanks

2009/12/16 Yuri D'Elia wav...@thregr.org:
 Package: blcr-dkms
 Version: 0.8.2-6
 Severity: normal

 In the current package version, libtool is executed during the build phase of
 the module. libtool is not listed as a dependency, and thus the build fails.

 libtool should not be required and/or executed though.
 This is likely a timestamp/autoconf issue.

I'm not 100% sure what's messing up the timestamps here, but I'll make
a new release shortly with uses am_maintainer mode to ensure that
autotools never get called during DKMS build phase.

Alan



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

Bug#560983: gmail-notify: egg.trayicon is deprecated, use gtk.StatusIcon instead

[Alan Woodland]

tags 560983 +confirmed
thanks

2009/12/13 Emilio Pozuelo Monfort po...@debian.org:
 Package: gmail-notify
 Severity: normal
 User: pkg-gnome-maintain...@lists.alioth.debian.org
 Usertags: oldlibs eggtrayicon

 Hi,

 gmail-notify uses egg.trayicon, but it should use gtk.StatusIcon which is
 better and well maintained.

 I'd like to remove eggtrayicon from the archive before Squeeze is released
 if possible, so would be great if gmail-notify could be ported by then.
Sure, I'll take a look at doing this after I get back from Xmas.

Alan



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

Bug#559267: [Pkg-mozext-maintainers] Bug#559267: Bug#559267: Sage Firefox extensions vulnerabilities

[Alan Woodland]

diff -uNr sage.orig/content/createhtml.js sage/content/createhtml.js
--- sage.orig/content/createhtml.js	2009-12-10 14:01:59.0 +
+++ sage/content/createhtml.js	2009-12-10 14:41:04.0 +
@@ -136,7 +136,8 @@
 return this.entityEncode(feed.getTitle());
 
 			case **LINK**:
-return feed.getLink();
+// Partial fix for CVE-2009-4102
+return this.cleanHref(feed.getLink());
 break;
 
 			case **AUTHOR**:
@@ -147,7 +148,8 @@
 
 			case **DESCRIPTION**:
 if (feed.hasDescription()) {
-	return feed.getDescription();
+ 	 // Entity encode call is Partial fix for CVE-2009-4102
+	 return this.entityEncode(SageUtils.htmlToText(feed.getDescription()));
 }
 return ;
 
@@ -216,7 +218,8 @@
 return i  +1;
 
 			case **LINK**:
-return item.getLink();
+			   // Partial fix for CVE-2009-4102
+			   return this.cleanHref(item.getLink());
 
 			case **TITLE**:
 if (item.hasTitle()) {
@@ -242,7 +245,8 @@
 		this.simpleHtmlParser.parse(item.getContent());
 		ds = this.filterHtmlHandler.toString();
 	} else {
-		ds = SageUtils.htmlToText(item.getContent());
+		 // Entity encode call is fix for regression from CVE-2006-4712
+		 ds = this.entityEncode(SageUtils.htmlToText(item.getContent()));
 	}
 	return div class=\item-desc\ + ds + /div;
 }
@@ -291,6 +295,31 @@
 		return dirService.get(aProp, Components.interfaces.nsILocalFile);
 	},
 	
+	// Partial fix for CVE-2009-4102
+	cleanHref: function(aUrl) 
+	{
+		 // We only want to allow http, ftp, news and mailto before :
+		 var ltype = aUrl.split(:)[0];
+		 aUrl = aUrl.replace(/^[^:]*:/, );
+	 	 switch(ltype.toLowerCase()) 
+   {
+		 case http:
+		aUrl = ltype + : + aUrl;
+   		 break;
+		 case nntp:
+		aUrl = ltype + : + aUrl;
+   		 break;
+		 case mailto:
+		aUrl = ltype + : + aUrl;
+   		 break;
+		 case ftp:
+		aUrl = ltype + : + aUrl;
+   		 break;
+   }
+		 // Did I miss some safe ones?
+		 return aUrl
+	},
+
 	entityEncode: function(aStr)
 	{
 		function replacechar(match) {


signature.asc
Description: OpenPGP digital signature

Bug#559267: [Pkg-mozext-maintainers] Bug#559267: Bug#559267: Sage Firefox extensions vulnerabilities

[Alan Woodland]

diff -uNr sage.orig/content/createhtml.js sage/content/createhtml.js
--- sage.orig/content/createhtml.js	2009-12-10 14:01:59.0 +
+++ sage/content/createhtml.js	2009-12-10 14:41:04.0 +
@@ -136,7 +136,8 @@
 return this.entityEncode(feed.getTitle());
 
 			case **LINK**:
-return feed.getLink();
+// Partial fix for CVE-2009-4102
+return this.cleanHref(feed.getLink());
 break;
 
 			case **AUTHOR**:
@@ -147,7 +148,8 @@
 
 			case **DESCRIPTION**:
 if (feed.hasDescription()) {
-	return feed.getDescription();
+ 	 // Entity encode call is Partial fix for CVE-2009-4102
+	 return this.entityEncode(SageUtils.htmlToText(feed.getDescription()));
 }
 return ;
 
@@ -216,7 +218,8 @@
 return i  +1;
 
 			case **LINK**:
-return item.getLink();
+			   // Partial fix for CVE-2009-4102
+			   return this.cleanHref(item.getLink());
 
 			case **TITLE**:
 if (item.hasTitle()) {
@@ -242,7 +245,8 @@
 		this.simpleHtmlParser.parse(item.getContent());
 		ds = this.filterHtmlHandler.toString();
 	} else {
-		ds = SageUtils.htmlToText(item.getContent());
+		 // Entity encode call is fix for regression from CVE-2006-4712
+		 ds = this.entityEncode(SageUtils.htmlToText(item.getContent()));
 	}
 	return div class=\item-desc\ + ds + /div;
 }
@@ -291,6 +295,31 @@
 		return dirService.get(aProp, Components.interfaces.nsILocalFile);
 	},
 	
+	// Partial fix for CVE-2009-4102
+	cleanHref: function(aUrl) 
+	{
+		 // We only want to allow http, ftp, news and mailto before :
+		 var ltype = aUrl.split(:)[0];
+		 aUrl = aUrl.replace(/^[^:]*:/, );
+	 	 switch(ltype.toLowerCase()) 
+   {
+		 case http:
+		aUrl = ltype + : + aUrl;
+   		 break;
+		 case nntp:
+		aUrl = ltype + : + aUrl;
+   		 break;
+		 case mailto:
+		aUrl = ltype + : + aUrl;
+   		 break;
+		 case ftp:
+		aUrl = ltype + : + aUrl;
+   		 break;
+   }
+		 // Did I miss some safe ones?
+		 return aUrl
+	},
+
 	entityEncode: function(aStr)
 	{
 		function replacechar(match) {


signature.asc
Description: OpenPGP digital signature

Bug#559267: Diff for Lenny

[alan . woodland]

lenny-xss-fix.debdiff
Description: Binary data


signature.asc
Description: OpenPGP digital signature

Bug#559267: Sage Firefox extensions vulnerabilities

[Alan Woodland]

Hi,

For my sins I'm the maintainer of the Debian package of Sage. I'm
looking at fixing the security bug that was recently reported [1].
Both of your names were mentioned in [2] as reporting the bug.

I'm looking to either prepare my own patch, in which a test case and
some advice would be extremely helpful, or ideally verify and apply an
existing patch. I've read through the two sets of slides at [3], but
there doesn't seem to be much detail on the actual exploit or a test
case. There are some references online to 'the author [of sage] being
made aware of patches', but nothing public that I can find.

Q: Is this a regression of the 2006 vulnerability [4]? Are there more
problems I should be aware of besides that?
Q: How would you suggest dealing with this?

Thanks,
Alan

P.S. If you want to discuss this privately I can send/receive PGP
encrypted mails to my @debian.org address using the key in the Debian
keyring.

[1] http://bugs.debian.org/559267
[2] http://www.securityfocus.com/bid/37120\
[3] http://malerisch.net/docs/security_docs.html
[4] http://www.gnucitizen.org/blog/cross-context-scripting-with-sage/



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

Bug#559267: [Pkg-mozext-maintainers] Bug#559267: CVE-2009-4102: RSS Feeds Cross Domain Scripting Vulnerability

[Alan Woodland]

2009/12/3 Giuseppe Iuculano iucul...@debian.org:
 Package: firefox-sage
 Severity: grave
 Tags: security

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1


 Hi,
 the following CVE (Common Vulnerabilities  Exposures) id was
 published for firefox-sage.

 CVE-2009-4102[0]:
 | Sage 1.4.3 and earlier extension for Firefox performs certain
 | operations with chrome privileges, which allows remote attackers to
 | execute arbitrary commands and perform cross-domain scripting attacks
 | via the description tag of an RSS feed.

 If you fix the vulnerability please also make sure to include the
 CVE id in your changelog entry.

 For further information see:

 [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4102
    http://security-tracker.debian.org/tracker/CVE-2009-4102

Hmm, I'll take a look at this this afternoon. It's possible we might
not be hit by this one, last time there was an XSS bug I applied a
patch that went further than upstream did.

Alan



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

Bug#559267: [Pkg-mozext-maintainers] Bug#559267: CVE-2009-4102: RSS Feeds Cross Domain Scripting Vulnerability

[Alan Woodland]

2009/12/3 Alan Woodland alan.woodl...@gmail.com:
 2009/12/3 Giuseppe Iuculano iucul...@debian.org:
 Package: firefox-sage
 Severity: grave
 Tags: security

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1


 Hi,
 the following CVE (Common Vulnerabilities  Exposures) id was
 published for firefox-sage.

 CVE-2009-4102[0]:
 | Sage 1.4.3 and earlier extension for Firefox performs certain
 | operations with chrome privileges, which allows remote attackers to
 | execute arbitrary commands and perform cross-domain scripting attacks
 | via the description tag of an RSS feed.

 If you fix the vulnerability please also make sure to include the
 CVE id in your changelog entry.

 For further information see:

 [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4102
    http://security-tracker.debian.org/tracker/CVE-2009-4102

 Hmm, I'll take a look at this this afternoon. It's possible we might
 not be hit by this one, last time there was an XSS bug I applied a
 patch that went further than upstream did.

Ho hum, I've so far not succeeded in finding a test case that exploits
this (safely). I thought the attached feed would break things, but
apparently not so far.

Alan
?xml version=1.0 encoding=UTF-8?
rss
  channel
titleno title/title
descriptionscriptalert(hello world -  feed description);/script/description
linkn/a/link
lastBuildDaten/a/lastBuildDate
generatorRSS Writer/generator
imageurlhttp://www.phelios.net/urltitlen/a/titlelinkhttp://www.phelios.net/linkdescriptionn/a/description/image
  /channel
  item
titleitem title/title
linkitem link/link
descriptionTest 1scriptalert(hello world -  item description);/script/description
  /item
/rss

Bug#524746: Fwd: Sponsor for player

[Alan Woodland]

Hi,

I've just sponsored an NMU for player to DELAYED/7, which makes only
one change, a fix for the RC bug #524746. If you'd like me to cancel
this to give you more time drop me an email.

Thanks,
Alan

-- Forwarded message --
From: Alan Woodland alan.woodl...@gmail.com
Date: 2009/11/12
Subject: Re: Sponsor for player
To: M. van Brummelen mart...@brumit.nl


2009/11/12 M. van Brummelen mart...@brumit.nl:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Alan,

 I saw you were looking for a sponsor for player on
 mentors.debian.net.
 I'm a DD, and I've been using player in our lab quite a bit. Are you
 still looking for a sponsor? I'd be glad to take a look over the
 packages with a view to making an upload for you if you are.
 Yes I am still looking for a sponsor for the player package.
 If you have the time to review and/or upload my package I and many
 users will be happy :) I did not ask on the mailinglist yet to give
 the original maintainer some time too respond.

Built fine, the diff is minimal and sensible, so I don't think there's
a problem. I'll make a 7 day delayed upload, it's more than the
recommended delay for an NMU which fixes only RC bugs. You should see
a mail about it soon I think.

Alan



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

Bug#507218: Songbird RFP

[Alan Woodland]

retitle 555700 ITP: songbird -- desktop Web player, a digital jukebox
and Web browser
forcemerge 412437 507218 555700
thanks

Hi,

Thanks for this RFP. There are currently two existing ITP bugs for
Songbird. Currently packaging Songbird is blocked by the large(ish)
number of custom patches [0] for xulrunner it depends upon. A number
of these we can work around or don't relate to any Debian
architectures, but that's not true of all of them. I'm not happy with
the idea of shipping a 2nd, patched version of xulrunner in Debian
from the security perspective alone and whilst I would very much like
to see Songbird in Debian I don't think pushing these patches into the
Debian version of xulrunner is appropriate either. Unfortunately at
the moment it seems like the best course of action is waiting on the
upstream authors to reduce this list.

I am fairly regularly monitoring this situation though, and if
something changes I do intend to produce a package.

Thanks for your interest,
Alan

[0] - http://wiki.songbirdnest.com/User:Stevel/XULRunner_Patches



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

Bug#555714: mpich2: Please add support for blcr

[Alan Woodland]

Package: mpich2
Version: 1.2-2
Severity: wishlist
Tags: patch

Hi,

Since BLCR is now in the archive it would be nice if mpich2 was built 
using this library to provide checkpoint support. The attached patch 
enables this at configure time.

Thanks,
Alan

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
diff -u mpich2-1.2/debian/rules mpich2-1.2/debian/rules
--- mpich2-1.2/debian/rules
+++ mpich2-1.2/debian/rules
@@ -15,7 +15,9 @@
 	--enable-f90 \
 	--sysconfdir=/etc/mpich2 \
 	--includedir=/usr/include/mpich2 \
-	--docdir=/usr/share/doc/mpich2
+	--docdir=/usr/share/doc/mpich2 \
+	--with-blcr=/usr \
+	--with-hydra-ckpointlib=blcr
 
 DEB_MAKE_CLEAN_TARGET := distclean
 
diff -u mpich2-1.2/debian/control mpich2-1.2/debian/control
--- mpich2-1.2/debian/control
+++ mpich2-1.2/debian/control
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: Debian Science Maintainers debian-science-maintain...@lists.alioth.debian.org
 Uploaders: Lucas Nussbaum lu...@lucas-nussbaum.net
-Build-Depends: debhelper (= 7), cdbs, python, gfortran, txt2man, libxt-dev, x11proto-core-dev, default-jdk, python-support, quilt
+Build-Depends: debhelper (= 7), cdbs, python, gfortran, libcr-dev, txt2man, libxt-dev, x11proto-core-dev, default-jdk, python-support, quilt
 Standards-Version: 3.8.3
 Homepage: http://www.mcs.anl.gov/research/projects/mpich2/
 Vcs-Browser: http://git.debian.org/?p=debian-science/packages/mpich2.git;a=summary
diff -u mpich2-1.2/debian/changelog mpich2-1.2/debian/changelog
--- mpich2-1.2/debian/changelog
+++ mpich2-1.2/debian/changelog
@@ -1,3 +1,10 @@
+mpich2 (1.2-2.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Add BLCR checkpoint library support
+
+ -- Alan Woodland awoodl...@debian.org  Wed, 11 Nov 2009 10:22:37 +
+
 mpich2 (1.2-2) unstable; urgency=low
 
   * Upload to unstable. (Actually, 1.2-1 was already uploaded to unstable)

Bug#547351: l7-filter-userspace: [FTBFS] 'nfct_sprintf_protocol' was not declared

[Alan Woodland]

2009/11/10 Alan Woodland alan.woodl...@gmail.com:
 2009/11/10 Jakub Wilk uba...@users.sf.net:
 tags 547351 + patch
 thanks

 I've finally managed to write a patch:
 http://hg.debian.org/hg/collab-maint/l7-filter-userspace/raw-file/tip/debian/patches/netfilter-conntrack-0.100.diff

 Testing will be *much* appreciated.

 Excellent, I'll have a fiddle with it tomorrow. I'm interested to see
 how you fixed it - I had a look at it myself and it wasn't as obvious
 as I'd hoped.

 Have you used any of the patch management systems before btw?

Thinking about it this would probably be a good candidate for an
upload to experimental - the patch is high risk, but important and
needs wider testing before it has the possibility of entering
unstable.

Alan



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

Bug#555714: mpich2: Please add support for blcr

[Alan Woodland]

Ok, that makes sense to wait for 1.3.x then I guess. I also forgot in
my patch to point out that BLCR only exists in Debian for i386, amd64,
armel and powerpc.

The patch I submitted for OpenMPI which enabled BLCR support did
indeed add an extra binary package, openmpi-checkpoint which avoids
linking/depending on libcr0 unless you want the checkpoint support. I
couldn't see a similar way to achieve this functionality in MPICH2
though.

Alan



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

Bug#555475: lib32cr0: installs libraries in old /emul/ia32-linux hierarchy

[Alan Woodland]

2009/11/9 Aaron M. Ucko u...@debian.org:
 Package: lib32cr0
 Version: 0.8.2-4
 Severity: serious
 Justification: Policy 9.1.1

 lib32cr0 installs into /emul/ia32-linux/usr/lib.  Although that was
 once the correct location for 32-bit libraries on amd64 Debian systems
 (with /usr/lib32 a mere symlink thereto), current practice is to use
 /usr/lib32, which is now a real directory.  Could you please switch
 over, and furthermore declare Conflicts: libc6-i386 (= 2.9-18) to
 ensure that the files don't accidentally wind up in the old location
 due to the presence of an obsolete symlink?
Sure, I was just about to make a new upload actually, so I'll hold off
and add this too.

Alan



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

Bug#547351: l7-filter-userspace: [FTBFS] 'nfct_sprintf_protocol' was not declared

[Alan Woodland]

2009/11/10 Jakub Wilk uba...@users.sf.net:
 tags 547351 + patch
 thanks

 I've finally managed to write a patch:
 http://hg.debian.org/hg/collab-maint/l7-filter-userspace/raw-file/tip/debian/patches/netfilter-conntrack-0.100.diff

 Testing will be *much* appreciated.

Excellent, I'll have a fiddle with it tomorrow. I'm interested to see
how you fixed it - I had a look at it myself and it wasn't as obvious
as I'd hoped.

Have you used any of the patch management systems before btw?

Alan



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

Bug#545919: [Pkg-openmpi-maintainers] Bug#545919: openmpi: Please add support for BLCR

[Alan Woodland]

2009/10/13 Manuel Prinz man...@debian.org:
 tag 545919 + pending
 thanks

 Hi Alan,

 thanks very much for your patch! I applied it to our SVN repository with
 minor modifications. I will upload a new package soon, but need to do
 some testing before that.

 Am Sonntag, den 13.09.2009, 10:59 +0100 schrieb Alan Woodland:
 The attached patch builds an extra binary package, openmpi-checkpoint
 on architectures which have BLCR available. (Option #3 from the
 earlier mail). I think it all works sanely, and shouldn't introduce
 any new problems.

 As said, I did some minor modifications, but nothing serious. It builds
 well and does not seem to introduce a problem from what I can see at the
 moment. So everything's great so far! :)

 I agree with your choice of option #3. I first had doubts about
 introducing a new package because it's really small but it seems to be
 the best solution.

 Not sure if you want to recommend or suggest
 openmpi-checkpoint though? I'd say recommend since I think checkpoints
 would be useful for the majority of usages for openmpi, but I don't
 feel strongly either way really.

 I agree with you here and left it as Recommends.

 Thanks again for your patch!

Thanks for accepting it! Please feel free to send any bug reports
relating to this my way, and I'll try to take a look. I have
subscribed to the PTS, but I'll definitely notice something forwarded
to my main mailbox :)

Alan



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

Bug#549740: mozilla-traybiff: FTBFS: nscore.h:51:21: error: prtypes.h: No such file or directory

[Alan Woodland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

fixed 549740 1.2.3-6
thanks
Lucas Nussbaum wrote:
 Source: mozilla-traybiff
 Version: 1.2.3-5
 Severity: serious
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20091005 qa-ftbfs
 Justification: FTBFS on amd64

 Hi,

 During a rebuild of all packages in sid, your package failed to build on
 amd64.
Fixed in traybiff (source package renamed) 1.2.3-6 and above, 1.2.3-7
is in incoming at the moment.

Alan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrKSccACgkQ1FNW1LDdr0LPugCgoIxMs9411NJcqOlr0pghoql3
y6UAoKiDwYzRLsRRpJ/x+zhNqDUwNbxR
=dO6X
-END PGP SIGNATURE-




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

Bug#549592: RM: mozilla-traybiff-common -- NBS; No longer needed

[Alan Woodland]

Package: ftp.debian.org
Severity: normal


mozilla-traybiff-common used to share files between icedove-traybiff and 
iceape-traybiff. Iceape was dropped late on in the Lenny release cycle, and the 
minimal change for mozilla-traybiff kept the -common package rather than 
merging it.

Since iceape is no longer supported in traybiff and packaging has moved to 
mozilla-devscripts splitting like this is no longer required. When traybiff 
1.2.3-7 hits unstable please remove mozilla-traybiff-common. Upgrades for users 
of icedove-traybiff are handled correctly by the transitional package 
icedove-traybiff and a conflict in xul-ext-traybiff.

Thanks,
Alan



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

Bug#549216: ITP: libvisca -- Implementation of VISCA cameras control protocol

[Alan Woodland]

Package: wnpp
Severity: wishlist
Owner: Alan Woodland awoodl...@debian.org

* Package name: libvisca
  Version : 1.0.1
  Upstream Author : Damien Douxchamps ddouxcha...@users.sourceforge.net
* URL : http://damien.douxchamps.net/libvisca/
* License : LGPL-2
  Programming Lang: C
  Description : Implementation of VISCA cameras control protocol

 VISCA is a protocol used to control many pan and tilt cameras. It is commonly
 found in cameras used for computer vision or robotics research, as well as
 video conferencing.
 .
 libVISCA is a library for controlling a VISCA(tm) compliant camera through the
 RS232 port of your PC. VISCA, on its side, is a protocol developed by Sony so
 that a lot of machine vision cameras from Sony are compliant with VISCA.
 .
 Typical cameras include the FCB-IX47 family of camera block for OEMs.
 Note that other devices, such as VCRs, can be controlled.
 .

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)



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

Bug#548587: hurd: bashisms in MAKEDEV

[Alan Woodland]

Package: hurd
Version: 20090404-1
Severity: important

/dev/MAKEDEV seems to assume the default shell is bash, which is no longer true 
in sid.

nostradamus-hurd:~# cd /dev
nostradamus-hurd:/dev# ./MAKEDEV hd2
./MAKEDEV: 53: function: not found
eval: 1: hd2: not found
./MAKEDEV: 56: Syntax error: } unexpected
nostradamus-hurd:/dev# bash ./MAKEDEV hd2

Note: not sure important is the right severity for this, switch to dash is a 
release goal for squeeze...

Alan

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: hurd-i386 (i386-AT386)

Kernel: GNU-Mach 1.3.99/Hurd-0.3
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages hurd depends on:
ii  gnumach  2:1.3.99.dfsg.cvs20090220-2 The GNU version of the Mach microk
ii  libc0.3  2.9-25  GNU C Library: Shared libraries
ii  libncursesw5 5.7+20090803-2  shared libraries for terminal hand
ii  libpthread-s 0.2-1+b1pthread stubs not provided by nati
ii  sysv-rc  2.87dsf-6   System-V-like runlevel change mech

hurd recommends no packages.

Versions of packages hurd suggests:
pn  hurd-doc  none (no description available)

-- no debconf information



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

Bug#548239: ITA gmail-notify

[Alan Woodland]

retitle 548239 ITA: gmail-notify -- A Gmail Notifier
owner 548239 !
thanks

I'll adopt gmail-notify, hopefully making an upload over the weekend.

Alan



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

Bug#547725: Bug#548239: ITA gmail-notify

[Alan Woodland]

2009/9/25 Sandro Tosi mo...@debian.org:
 On Fri, Sep 25, 2009 at 11:05, Alan Woodland awoodl...@debian.org wrote:
 retitle 548239 ITA: gmail-notify -- A Gmail Notifier
 owner 548239 !
 thanks

 I'll adopt gmail-notify, hopefully making an upload over the weekend.

 you might also consider joining the PAPT [1] and maintainer this package 
 there.

 [1] http://wiki.debian.org/Teams/PythonAppsPackagingTeam

Sure, I'm all in favour of team based packaging, will read through the
wiki and migrate the package to python-apps-team with myself as an
uploader this weekend then.

Alan



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

Bug#547725: gmail-notify: broken maintainer address

[Alan Woodland]

Hi,

I was the original sponsor for gmail-notify. I've been aware of the
absent maintainer for sometime now, although I know no more than you
do about the reasons. I prepared an NMU almost exactly 10 days ago
that addresses most of the outstanding bugs for this package, and
emailed the maintainer again (he did use a gmail address for a while
too).

If my delayed upload goes through (which it looks like it will
tonight) my intention was to talk to QA about MIA, since I can't quite
work out where sponsored uploads fit into MIA, and currently mia-query
returns 'X-MIA: Not in database'.

One of my tests for sponsorship is 'would I be willing to be
maintainer if the sponsoree disapeared?', so I'm willing to take this
package over. I don't want to end up hijacking it without any kind of
due process though.

Alan



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

Bug#547351: l7-filter-userspace: [FTBFS] 'nfct_sprintf_protocol' was not declared

[Alan Woodland]

2009/9/19 Jakub Wilk uba...@users.sf.net:
 * Alan Woodland awoodl...@debian.org, 2009-09-18, 21:51:

 Justification: Policy 5.8.2

 My copy of Debian Policy does not have such a section:

 $ zgrep -cF 5.8.2 /usr/share/doc/debian-policy/policy.txt.gz
 0

Whoops, not sure where that came from! How about 4.9 instead? That
pretty much covers debian/rules making packages.

 With the new version of libnetfilter-conntrack these functions seem to
 have been removed entierly, and the build now fails:

 l7-conntrack.cpp: In function 'int sprintf_conntrack_key(char*,
 nfct_conntrack*, unsigned int)':
 l7-conntrack.cpp:129: error: 'nfct_sprintf_protocol' was not declared in
 this scope
 ...

 That looks very bad.
 *Lots* of code that l7-f-u relied on was removed from the library.

If it was deprecated there must be a recommended alternative surely?
Are upstream likely to fix this in the near future? Might be worth
asking the libnetfilter-conntrack for advice?

Do you want to package the kernel module instead? (or do you want me
to take a look at doing it?)

Alan



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

Bug#546665: l7-protocols: overwrites user configuration files

[Alan Woodland]

2009/9/18 Jakub Wilk uba...@users.sf.net:
 * Alan Woodland awoodl...@debian.org, 2009-09-17, 19:44:

 2) Patch l7-filter-userspace to look into /usr/share/l7-protocols for
 protocol definitions rather than /etc/l7-protocols. Then l7-protocols
 could
 provide no /etc/l7-protocols at all.

 This might be a sensible option, although it's a significant deviation
 from what upstream do. There are definitely other packages that take
 this approach.

 Would it be possible to make it look in both /etc/l7-protocols (which
 gets installed/created empty by default) *and*
 /usr/share/l7-protocols? That might make sense from a behaviour point
 of view.

 That would be doable but not quite trivial.

 But what should be the semantics of -p option in that case? Should
 /usr/share/l7-protocols be always read, or only if -p is not given?

I'd say it should look in /etc/l7-protocols and
/usr/share/l7-protocols if there is no -p given and where ever the
user specifies if -p is given. That way it's pretty much minimal
change from upstream (you could patch the manpage to say the default
path is /usr/share... and /etc/...).

I think it'd probably be worth getting a second opinion though on this
one really, try asking on debian-de...@lists.debian.org perhaps to see
what the collective wisdom is.

Alan



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

Bug#547351: l7-filter-userspace: [FTBFS] 'nfct_sprintf_protocol' was not declared

[Alan Woodland]

Subject: l7-filter-userspace: [FTBFS] 'nfct_sprintf_protocol' was not declared
Package: l7-filter-userspace
Version: 0.11-1
Justification: Policy 5.8.2
Severity: serious

The buildd logs from the original build (e.g. 
https://buildd.debian.org/fetch.cgi?pkg=l7-filter-userspacever=0.11-1arch=amd64stamp=1250566476file=log)
 have a few warnings about deprecated functions.

With the new version of libnetfilter-conntrack these functions seem to have 
been removed entierly, and the build now fails:

l7-conntrack.cpp: In function 'int sprintf_conntrack_key(char*, 
nfct_conntrack*, unsigned int)':
  
l7-conntrack.cpp:129: error: 'nfct_sprintf_protocol' was not declared in this 
scope
...

Alan

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-1-686-bigmem (SMP w/1 CPU core)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash



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

Bug#546665: l7-protocols: overwrites user configuration files

[Alan Woodland]

2009/9/17 Piotr Lewandowski piotr.lewandow...@gmail.com:
 Hi Alan,

 I need your advice what to do with my first RC-bug. :)

I would normally recommend CC'ing discussions relating to how to fix
the bug to the bug report itself - someone else might read the bug and
have something relevant to offer to the discussion, or alternatively
if the bug takes a while to fix it shows someone contemplating an NMU
why the solution is non-trivial and how you've considered fixing it
(which as the maintainer you're likely to know the repercussions of
the 'obvious' fix better than someone who first saw the package 5
minutes ago).

 * Jakub Wilk uba...@users.sf.net, 2009-09-14 23:58:

 Package: l7-protocols
 Version: 20090528-1
 Severity: serious
 Justification: Policy 10.8.3

 l7-protocols would happily overwrite user configuration files:

 # ls -l /etc/l7-protocols/extra/http-itunes.pat -rw--- 1 root root 30
 Sep 14 22:57 /etc/l7-protocols/extra/http-itunes.pat

 # dpkg -i /path/to/l7-protocols_20090528-1_all.deb [...]
 Unpacking l7-protocols (from .../l7-protocols_20090528-1_all.deb) ...
 Setting up l7-protocols (20090528-1) ...

 # ls -l /etc/l7-protocols/extra/http-itunes.pat*
 lrwxrwxrwx 1 root root 45 Sep 14 22:57
 /etc/l7-protocols/extra/http-itunes.pat -
 /usr/share/l7-protocols/extra/http-itunes.pat

 I've talked to Jakub about this issue and we've came up with some possible
 solutions (none of which are ideal):

 1) /etc/l7-protocols would be a symlink to /usr/share/l7-protocols managed
 by maintainer scripts of l7-protocols. It is not clear what to do during
 removal (and before purge) - we shouldn't leave a dangling symlink in /etc.

I would avoid this one:
mkdir /etc/l7-protocols/local-custom
# really makes it in /usr/share/l7-protocols is a bad idea

 2) Patch l7-filter-userspace to look into /usr/share/l7-protocols for
 protocol definitions rather than /etc/l7-protocols. Then l7-protocols could
 provide no /etc/l7-protocols at all.
This might be a sensible option, although it's a significant deviation
from what upstream do. There are definitely other packages that take
this approach.

Would it be possible to make it look in both /etc/l7-protocols (which
gets installed/created empty by default) *and*
/usr/share/l7-protocols? That might make sense from a behaviour point
of view.

 3) l7-protocols maintainer would maintain symlink farm, just like
 ca-certificates does. (This would be a significant maintenance burden,
 though.)
I don't much like this one, it seems like over-engineering the problem
with all that it would entail.

 4) Just put all the protocol definitions into /etc/l7-protocols and make
 them conffiles.
That's an interesting one. They fall nicely into a grey area with
regards to what is/isn't really a conf file.

 5) Mark symlinks in /etc/l7-protocols as conffiles. I don't know if it
 really would help, though.
To be honest I'm not actually sure what the behaviour would be in that
case either! Would be interesting to try it and see, if it works this
would be quite a good solution.

 What do you think?

I think I'd rank the solutions in order of preference 5 (if it
works!), 2 (adding both locations), 4, 2 (changing the location), 3, 1

How trivial would a patch for 2 be?

Alan



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

Bug#545919: [Pkg-openmpi-maintainers] Bug#545919: openmpi: Please add support for BLCR

[Alan Woodland]

The attached patch builds an extra binary package, openmpi-checkpoint
on architectures which have BLCR available. (Option #3 from the
earlier mail). I think it all works sanely, and shouldn't introduce
any new problems. Not sure if you want to recommend or suggest
openmpi-checkpoint though? I'd say recommend since I think checkpoints
would be useful for the majority of usages for openmpi, but I don't
feel strongly either way really.

Alan
diff -u openmpi-1.3.3/debian/changelog openmpi-1.3.3/debian/changelog
--- openmpi-1.3.3/debian/changelog
+++ openmpi-1.3.3/debian/changelog
@@ -1,7 +1,14 @@
+openmpi (1.3.3-2) unstable; urgency=low
+
+  * Build with BLCR support on i386,amd64,ppc,armel
+  * Adds openmpi-checkpoint package, which includes the binaries for checkpointing
+
+ -- Alan Woodland awoodl...@debian.org  Wed, 09 Sep 2009 16:41:22 +0100
+
diff -u openmpi-1.3.3/debian/rules openmpi-1.3.3/debian/rules
--- openmpi-1.3.3/debian/rules
+++ openmpi-1.3.3/debian/rules
@@ -27,8 +27,25 @@
 	CFLAGS += -mcpu=v9
 endif
 
+
+CHKPT =
+
+ifeq $(DEB_HOST_ARCH) amd64
+CHKPT += --with-ft=cr --with-blcr=/usr --with-blcr-libdir=/usr/lib
+endif
+ifeq $(DEB_HOST_ARCH) i386
+CHKPT += --with-ft=cr --with-blcr=/usr --with-blcr-libdir=/usr/lib
+endif
+ifeq $(DEB_HOST_ARCH) armel
+CHKPT += --with-ft=cr --with-blcr=/usr --with-blcr-libdir=/usr/lib
+endif
+ifeq $(DEB_HOST_ARCH) powerpc
+CHKPT += --with-ft=cr --with-blcr=/usr --with-blcr-libdir=/usr/lib
+endif
+
 COMMON_CONFIG_PARAMS = \
 			$(CROSS)\
+			$(CHKPT)\
 			--prefix=/usr \
 			--mandir=\$${prefix}/share/man 		\
 			--infodir=\$${prefix}/share/info 	\
@@ -116,6 +133,8 @@
 	sed -i 's/3OpenMPI/3/' debian/openmpi/usr/share/man/man3/*.3
 
 	dh_install -s --sourcedir=$(CURDIR)/debian/openmpi --list-missing
+	# This gets installed by the wildcard, but we want to remove it really, so it's only used for checkpointing
+	-rm -f debian/libopenmpi*/usr/lib/openmpi/lib/openmpi/mca_crs_blcr.so
 
 binary-indep: install-indep
 	dh_testdir -i
diff -u openmpi-1.3.3/debian/control openmpi-1.3.3/debian/control
--- openmpi-1.3.3/debian/control
+++ openmpi-1.3.3/debian/control
@@ -4,7 +4,7 @@
 Homepage: http://www.open-mpi.org/
 Maintainer: Debian OpenMPI Maintainers pkg-openmpi-maintain...@lists.alioth.debian.org
 Uploaders: Manuel Prinz man...@debian.org, Sylvestre Ledru sylves...@debian.org
-Build-Depends: debhelper (= 5.0.0), libibverbs-dev (= 1.1.1) [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386], gfortran, gcc (= 4:4.1.2), chrpath, quilt
+Build-Depends: debhelper (= 5.0.0), libibverbs-dev (= 1.1.1) [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386], gfortran, gcc (= 4:4.1.2), chrpath, quilt, libcr-dev [amd64 i386 powerpc armel]
 Standards-Version: 3.8.3
 Vcs-Svn: svn://svn.debian.org/svn/pkg-openmpi/openmpi/trunk/
 Vcs-Browser: http://svn.debian.org/wsvn/pkg-openmpi/openmpi/trunk/
@@ -12,6 +12,7 @@
 Package: openmpi-bin
 Architecture: alpha amd64 i386 ia64 powerpc ppc64 sparc kfreebsd-i386 kfreebsd-amd64 hurd-i386
 Depends: ${shlibs:Depends}, ${misc:Depends}, openmpi-common (= ${source:Version})
+Recommends: openmpi-checkpoint
 Suggests: gfortran
 Description: high performance message passing library -- binaries
  Open MPI is a project combining technologies and resources from several other
@@ -113,0 +115,12 @@
+
+Package: openmpi-checkpoint
+Architecture: amd64 i386 powerpc armel
+Depends: ${shlibs:Depends}, ${misc:Depends}, openmpi-bin (= ${binary:Version})
+Description: high performance message passing library -- checkpoint support
+ Open MPI is a project combining technologies and resources from several other
+ projects (FT-MPI, LA-MPI, LAM/MPI, and PACX-MPI) in order to build the best
+ MPI library available. A completely new MPI-2 compliant implementation, Open
+ MPI offers advantages for system and software vendors, application developers
+ and computer science researchers.
+ .
+ This package contains binaries needed for checkpointing OpenMPI applications
only in patch2:
unchanged:
--- openmpi-1.3.3.orig/debian/openmpi-checkpoint.install
+++ openmpi-1.3.3/debian/openmpi-checkpoint.install
@@ -0,0 +1,13 @@
+usr/bin/ompi-restart
+usr/bin/orte-restart
+usr/bin/opal-restart
+usr/bin/ompi-checkpoint
+usr/bin/orte-checkpoint
+usr/bin/opal-checkpoint
+usr/share/man/man1/ompi-checkpoint.1
+usr/share/man/man1/opal-checkpoint.1
+usr/share/man/man1/orte-checkpoint.1
+usr/share/man/man1/ompi-restart.1
+usr/share/man/man1/opal-restart.1
+usr/share/man/man1/orte-restart.1
+usr/lib/openmpi/lib/openmpi/mca_crs_blcr.so

Bug#546464: gmail-notify: diff for NMU version 1.6.1.1-0.1

[Alan Woodland]

Package: gmail-notify
Version: 1.6.1-3
Severity: normal
Tags: patch

Dear maintainer,

I've prepared an NMU for gmail-notify (versioned as 1.6.1.1-0.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru gmail-notify-1.6.1/debian/changelog 
gmail-notify-1.6.1.1/debian/changelog
--- gmail-notify-1.6.1/debian/changelog 2009-09-13 12:34:13.0 +0100
+++ gmail-notify-1.6.1.1/debian/changelog   2009-09-13 12:34:14.0 
+0100
@@ -1,3 +1,16 @@
+gmail-notify (1.6.1.1-0.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * New upstream release 1.6.1.1, (Closes: #457748)
+  * Depend on python-eggtrayicon instead of python-gnome2-extras (Closes: 
#485318)
+  * Changed gmail.google.com to mail.google.com (Closes: #503740)
+  * Applied patch for proxy support from Luca Falavigna (Closes: #428260)
+  * Applied preference window patch from Ubuntu (Closes: #432676)
+  * Replace  with amp; in popups (Closes: #420871)
+  * Add debian/watch
+
+ -- Alan Woodland awoodl...@debian.org  Sun, 13 Sep 2009 11:31:01 +0100
+
 gmail-notify (1.6.1-3) unstable; urgency=low
 
   * Chance default x-www-browser to www-browser (closes: #389532) 
diff -Nru gmail-notify-1.6.1/debian/control gmail-notify-1.6.1.1/debian/control
--- gmail-notify-1.6.1/debian/control   2009-09-13 12:34:13.0 +0100
+++ gmail-notify-1.6.1.1/debian/control 2009-09-13 12:34:14.0 +0100
@@ -7,7 +7,7 @@
 
 Package: gmail-notify
 Architecture: all 
-Depends: ${shlibs:Depends}, ${misc:Depends},${python:Depends}, python-gtk2, 
python-gnome2-extras
+Depends: ${shlibs:Depends}, ${misc:Depends},${python:Depends}, python-gtk2, 
python-eggtrayicon
 Recommends: www-browser
 Description: A Gmail Notifier
  Gmail Notifier is a Linux alternative for the notifier program released
diff -Nru gmail-notify-1.6.1/debian/patches/05_proxy_support.patch 
gmail-notify-1.6.1.1/debian/patches/05_proxy_support.patch
--- gmail-notify-1.6.1/debian/patches/05_proxy_support.patch1970-01-01 
01:00:00.0 +0100
+++ gmail-notify-1.6.1.1/debian/patches/05_proxy_support.patch  2009-09-13 
12:34:14.0 +0100
@@ -0,0 +1,232 @@
+diff -Nur gmail-notify-1.6.1/gmailatom.py gmail-notify-1.6.1.new/gmailatom.py
+--- gmail-notify-1.6.1/gmailatom.py2007-06-09 13:41:13.0 +0200
 gmail-notify-1.6.1.new/gmailatom.py2007-06-09 18:32:24.0 
+0200
+@@ -116,12 +116,17 @@
+   host = https://mail.google.com;
+   url = host + /mail/feed/atom
+ 
+-  def __init__(self, user, pswd):
++  def __init__(self, user, pswd, proxy=None):
+   self.m = MailHandler()
+   # initialize authorization handler
+   auth_handler = urllib2.HTTPBasicAuthHandler()
+   auth_handler.add_password( self.realm, self.host, user, pswd)
+-  opener = urllib2.build_opener(auth_handler)
++  # manage proxy
++  if proxy:
++  proxy_handler = urllib2.ProxyHandler({'http': proxy})
++  opener = urllib2.build_opener(proxy_handler, 
auth_handler)
++  else:
++  opener = urllib2.build_opener(auth_handler)
+   urllib2.install_opener(opener)
+ 
+   def sendRequest(self):
+diff -Nur gmail-notify-1.6.1/GmailConfig.py 
gmail-notify-1.6.1.new/GmailConfig.py
+--- gmail-notify-1.6.1/GmailConfig.py  2007-06-09 18:32:08.0 +0200
 gmail-notify-1.6.1.new/GmailConfig.py  2007-06-09 18:32:09.0 
+0200
+@@ -18,8 +18,8 @@
+   configElements = None 
+ 
+   # Declare global variables for configuration as dictionary
+-  options = { gmailusername:None, gmailpassword:None, 
browserpath:www-browser, lang:English,   
+-  voffset:0, hoffset:0, 
checkinterval:2, 
++  options = { gmailusername:None, gmailpassword:None, 
browserpath:www-browser, proxy:None,
++  lang:English, voffset:0, hoffset:0, 
checkinterval:2, 
+   animationdelay:15, popuptimespan:5000}
+   
+   config = ConfigParser.RawConfigParser()
+@@ -49,6 +49,7 @@
+   [gmailusername,2,None,None],
+   [gmailpassword,22,None,None],
+   [browserpath,3,None,None],
++  [proxy,36,None,None],
+   [voffset,28,None,None],
+   [hoffset,27,None,None],
+   [checkinterval,31,None,None],
+@@ -57,7 +58,7 @@
+   ]
+ 
+   # Create table and attach to window
+-  table = gtk.Table( rows=11, columns=2, homogeneous=gtk.FALSE )
++  table = gtk.Table( rows=12, columns=2, homogeneous=gtk.FALSE

Bug#537275: icedove-traybiff: Tray icon does not work in KDE 4

[Alan Woodland]

2009/7/16 Tim Gokcen hexe...@gmail.com:
 Package: icedove-traybiff
 Version: 1.2.3-4.3
 Severity: important

 After upgrading to KDE 4 in the 'testing' distribution, the tray icon for
 Icedove no longer functions. Instead of showing a 'letter' icon, the tray
 has a blank space where the icon should be. Sometimes, the blank takes on
 the appearance of a neighbouring tray icon, as if kdm doesn't really know
 what to put there and the memory for the tray view is being corrupted.

 The source of this problem may, of course, be with KDE4, but other non-KDE
 tray icons do work properly for me, such as for example xmms2tray.
 No KDE 4 applications that I have tried (Kmix, Kopete, Klipper, Akregator)
 exhibit this problem.
I actually have KDE4 on my development box now, so I can test this one
out. As far as I can see it works ok, except for when you have 'always
show the icon' ticked, which results in part of the new mail icon
remaining in transparent areas of the 'no mail' icon. Are you still
seeing this?

Alan



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

Bug#545919: [Pkg-openmpi-maintainers] Bug#545919: openmpi: Please add support for BLCR

[Alan Woodland]

2009/9/10 Alan Woodland awoodl...@debian.org:
 2009/9/10 Manuel Prinz man...@debian.org:
 Hi Alan!

 Am Donnerstag, den 10.09.2009, 00:33 +0100 schrieb Alan Woodland:
 BLCR is now in main. It would be nice if openmpi were built using this
 where it is available.

 I've attached a short patch adding options to configure, and build-depends

 Thanks a lot for the patch!

 I did think about adding it but BLCR was not packaged yet. I will add it
 in the next upload.

 Unfortunately, I do not have any possibility to test Open MPI with BLCR
 at the moment. Can you confirm it works as expected?

 I checked it configured and built last night on my machine, but I've
 not had a chance to test any functionality properly yet.

Ok, I've had a bit more of a fiddle with it now. Several things have come up :)

Firstly a dependency on libcr0 is now generated automatically for
libopenmpi1.3, which is technically accurate, but not really strictly
needed. If libcr0 isn't installed mpirun still works exactly as before
anyway. The only time you notice that libcr0 isn't installed is when
you pass the -am ft-enable-cr flag to mpirun which causes it to try
and dlopen() the library that is really linked against libcr0.

Secondly it seems that we're going to need to install ompi-checkpoint
and ompi-restart in order for this to be useful. This could be done a
number of ways I think:
1) add to debian/openmpi-bin.install (Simple, gets the extra utilities
even on platforms blcr doesn't support though. Might not be a bad
thing anyway if they're useful for the 'self' checkpoint mechanism
anyway?)
2) add a conditional in install-arch and arrange for them to only be
installed on amd64,i386,ppc,armel where BLCR  builds and works
currently
3) add an extra package (e.g. openmpi-checkpoint, build it only on
supported arches. Suggest/recommend this package, probably from
openmpi-bin? This solution also fits nicely with what I said earlier
about not needing libcr0 unless you actually want to use blcr
checkpoints, because we could suppress the automatic dependency for
libcr0 and manually add it to this package instead, so avoiding
forcing all openmpi users to install libcr0 unless they actually care
about checkpoints)

What are your thoughts on this?

I'll try and convert the I've got into a repeatable, automated test
and then add it to this bug report in a bit too.

Alan



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

Bug#545919: [Pkg-openmpi-maintainers] Bug#545919: openmpi: Please add support for BLCR

[Alan Woodland]

2009/9/12 Alan Woodland alan.woodl...@gmail.com:
 2009/9/10 Alan Woodland awoodl...@debian.org:
 2009/9/10 Manuel Prinz man...@debian.org:
 Hi Alan!

 Am Donnerstag, den 10.09.2009, 00:33 +0100 schrieb Alan Woodland:
 BLCR is now in main. It would be nice if openmpi were built using this
 where it is available.

 I've attached a short patch adding options to configure, and build-depends

 Thanks a lot for the patch!

 I did think about adding it but BLCR was not packaged yet. I will add it
 in the next upload.

 Unfortunately, I do not have any possibility to test Open MPI with BLCR
 at the moment. Can you confirm it works as expected?

 I checked it configured and built last night on my machine, but I've
 not had a chance to test any functionality properly yet.

 Ok, I've had a bit more of a fiddle with it now. Several things have come up 
 :)

 Firstly a dependency on libcr0 is now generated automatically for
 libopenmpi1.3, which is technically accurate, but not really strictly
 needed. If libcr0 isn't installed mpirun still works exactly as before
 anyway. The only time you notice that libcr0 isn't installed is when
 you pass the -am ft-enable-cr flag to mpirun which causes it to try
 and dlopen() the library that is really linked against libcr0.
Forgot to say: Even when it can't dlopen() this because of the
unresolved external dependency it still behaves sanely, warns about
not being able to do the checkpoint and continues.

Alan



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

Bug#545919: [Pkg-openmpi-maintainers] Bug#545919: openmpi: Please add support for BLCR

[Alan Woodland]

2009/9/12 Alan Woodland alan.woodl...@gmail.com:
 I'll try and convert the I've got into a repeatable, automated test
 and then add it to this bug report in a bit too.
As promised I've attached a somewhat crude test for the BLCR
checkpointing to this email. run_test.sh compiles and runs everything.

Alan
#define _GNU_SOURCE
#include unistd.h
#include stdlib.h
#include poll.h
#include assert.h
#include sys/types.h
#include stdio.h
#include sys/stat.h
#include fcntl.h
#include string.h
#include sys/wait.h

/*
 * Test harness for MPI BLCR checkpointing. Depends upon mpi_test_blcr.c,
 * a modified version of ring_c.c that ships with the OpenMPI examples.
 * (C) 2009 Alan Woodland awoodl...@debian.org,  under the same terms 
 * as OpenMPI.
 */

int main() {
  int pipes[2];
  if (pipe(pipes)) {
	 perror(pipe);
	 exit(-1);
  }

  int fds[RANK];
  for (int i = 0; i  RANK; ++i) {
	 char fname[50];
	 sprintf(fname, %d_run.log, i);
	 // Create it if it doesn't exist yet anyway, truncate it if it does
	 fds[i] = open(fname, O_CLOEXEC|O_CREAT|O_TRUNC|O_RDWR);
	 if (!fds[i]) {
		perror(open);
		exit(-1);
	 }
  }

  pid_t child = fork();
  if (-1 == child) {
	 perror(fork);
	 exit(-1);
  }  

  if (child) {
	 int counter = 10;
	 // parent
	 close(pipes[0]); // close the read end
	 FILE *master = fopen(0_run.log, r);
	 if (!master) {
		perror(fopen);
		exit(-1);
	 }
	 while (counter != 6) {
		int r, n;
		const int got = fscanf(master, %d:%d, r, n);
		if (got = 0)
		  continue;
		assert(got == 2);
		assert(r == 0);
		assert(n == counter -1 || (n == counter  n == 10));
		counter = n;
		fprintf(stderr, Counter is now: %d\n, counter);
	 }
	 fclose(master);
	 fprintf(stderr, Counter=6, doing checkpoint\n);

	 char cmd[2048];
	 char snapshotid[2048];
	 sprintf(cmd, ompi-checkpoint %d, child);
	 FILE *chkpt = popen(cmd, r);
	 write(pipes[1], \n, 1);
	 assert(chkpt);
	 while (!feof(chkpt)) fscanf(chkpt, %s\n, snapshotid);
	 int result = pclose(chkpt);
	 assert(!result);
	 
	 fprintf(stderr, Snapshot done: %s\n, snapshotid);
	 kill(child, SIGINT);

	 // check everyone hit 6 ok:
	 for (int i = 0; i  RANK; ++i) {
		char buf[2048];
		ssize_t got = read(fds[i], buf, 2048);
		int scanned;
		FILE *stream = fmemopen(buf, got, r);
		int lastn = -1;
		while (!feof(stream)) {
		  int r, n;
		  fscanf(stream, %d:%d\n, r, n);
		  assert(r == i);
		  assert(n == lastn - 1 || lastn  0);
		  assert(lastn = 0 || n == 10);
		  lastn = n;
		}
		fclose(stream);
		assert(lastn = 6);
		fprintf(stderr, Log from: %d passed stage1! (Final=%d)\n, i, lastn);
	 }

	 // Restart it and check everything hits 0
	 sprintf(cmd, ompi-restart %s, snapshotid);
	 FILE *restarted = popen(cmd, w);
	 assert(restarted);
	 result = pclose(restarted);
	 assert(!result);
	 
	 fprintf(stderr, Restart done\n);
	 // check everyone hit 0 ok:
	 for (int i = 0; i  RANK; ++i) {
		char buf[2048];
		ssize_t got = read(fds[i], buf, 2048);
		int scanned;
		FILE *stream = fmemopen(buf, got, r);
		int lastn = -1;
		while (!feof(stream)) {
		  int r, n;
		  fscanf(stream, %d:%d\n, r, n);
		  assert(r == i);
		  assert(n == lastn - 1 || lastn  0);
		  lastn = n;
		}
		fclose(stream);
		assert(lastn == 0 || (!i  lastn == 1));
		fprintf(stderr, Log from: %d passed stage2! (Final=%d)\n, i, lastn);
	 }

  }
  else {
	 char rank[10];
	 sprintf(rank, %d, RANK);
	 // child
	 close(pipes[1]); // close the write end
	 if (-1 == dup2(pipes[0], STDIN_FILENO)) {
		perror(dup2);
		exit(-1);
	 }
	 close(pipes[0]);
	 // Debian-ism! 
	 int result = execlp(mpirun.openmpi, mpirun, -np, rank, -am, ft-enable-cr, ./a.out, NULL);
	 perror(execlp);
	 exit(-1);
  }

  return 0;
}
/*
 * Copyright (c) 2004-2006 The Trustees of Indiana University and Indiana
 * University Research and Technology
 * Corporation.  All rights reserved.
 * Copyright (c) 2006  Cisco Systems, Inc.  All rights reserved.
 *
 * Simple ring test program
 *
 * Modifications for checkpoint testing added 2009, awoodl...@debian.org
 */

#include stdio.h
#include stdlib.h
#include unistd.h
#include mpi.h

int main(int argc, char *argv[])
{
int rank, size, next, prev, message, tag = 201;

/* Start up MPI */

MPI_Init(argc, argv);
MPI_Comm_rank(MPI_COMM_WORLD, rank);
MPI_Comm_size(MPI_COMM_WORLD, size);
 
/* Calculate the rank of the next process in the ring.  Use the
   modulus operator so that the last process wraps around to
   rank zero. */

next = (rank + 1) % size;
prev = (rank + size - 1) % size;
	 
	 char fname[50];
	 sprintf(fname, %d_run.log, rank);
	 FILE *log = fopen(fname, w);
	 if (!log) {
		perror(fopen);
		exit(-1);
	 }

/* If we are the master process (i.e., MPI_COMM_WORLD rank 0),
   put the number of times to go around the ring in the
   message. */

if (0 == rank) {
message = 10;

printf(Process 0 sending %d to %d, tag %d (%d processes in ring)\n, 
   message, next, tag

Bug#545919: [Pkg-openmpi-maintainers] Bug#545919: openmpi: Please add support for BLCR

[Alan Woodland]

2009/9/10 Manuel Prinz man...@debian.org:
 Hi Alan!

 Am Donnerstag, den 10.09.2009, 00:33 +0100 schrieb Alan Woodland:
 BLCR is now in main. It would be nice if openmpi were built using this
 where it is available.

 I've attached a short patch adding options to configure, and build-depends

 Thanks a lot for the patch!

 I did think about adding it but BLCR was not packaged yet. I will add it
 in the next upload.

 Unfortunately, I do not have any possibility to test Open MPI with BLCR
 at the moment. Can you confirm it works as expected?

I checked it configured and built last night on my machine, but I've
not had a chance to test any functionality properly yet.

I can't see any tests in the source package that would cover this
right now, so I'll look about putting together a really simple set
that would verify BLCR checkpointing functionality with a simple MPI
application. (It won't pass on buildds though since I assume the
kernel module won't be loaded on any buildds)

Alan



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

Bug#545919: openmpi: Please add support for BLCR

[Alan Woodland]

Package: openmpi
Severity: wishlist
Tags: patch

Hi,

BLCR is now in main. It would be nice if openmpi were built using this
where it is available.

I've attached a short patch adding options to configure, and build-depends

Thanks,
Alan

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686-bigmem (SMP w/1 CPU core)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
diff -u openmpi-1.3.3/debian/changelog openmpi-1.3.3/debian/changelog
--- openmpi-1.3.3/debian/changelog
+++ openmpi-1.3.3/debian/changelog
@@ -1,3 +1,9 @@
+openmpi (1.3.3-2) unstable; urgency=low
+
+  * Build with BLCR support on i386,amd64,ppc,armel
+
+ -- Alan Woodland awoodl...@debian.org  Wed, 09 Sep 2009 16:41:22 +0100
+
 openmpi (1.3.3-1) unstable; urgency=low
 
   * New upstream version
diff -u openmpi-1.3.3/debian/rules openmpi-1.3.3/debian/rules
--- openmpi-1.3.3/debian/rules
+++ openmpi-1.3.3/debian/rules
@@ -27,8 +27,25 @@
 	CFLAGS += -mcpu=v9
 endif
 
+
+CHKPT =
+
+ifeq $(DEB_HOST_ARCH) amd64
+CHKPT += --with-ft=cr --with-blcr=/usr --with-blcr-libdir=/usr/lib
+endif
+ifeq $(DEB_HOST_ARCH) i386
+CHKPT += --with-ft=cr --with-blcr=/usr --with-blcr-libdir=/usr/lib
+endif
+ifeq $(DEB_HOST_ARCH) armel
+CHKPT += --with-ft=cr --with-blcr=/usr --with-blcr-libdir=/usr/lib
+endif
+ifeq $(DEB_HOST_ARCH) powerpc
+CHKPT += --with-ft=cr --with-blcr=/usr --with-blcr-libdir=/usr/lib
+endif
+
 COMMON_CONFIG_PARAMS = \
 			$(CROSS)\
+			$(CHKPT)\
 			--prefix=/usr \
 			--mandir=\$${prefix}/share/man 		\
 			--infodir=\$${prefix}/share/info 	\
diff -u openmpi-1.3.3/debian/control openmpi-1.3.3/debian/control
--- openmpi-1.3.3/debian/control
+++ openmpi-1.3.3/debian/control
@@ -4,7 +4,7 @@
 Homepage: http://www.open-mpi.org/
 Maintainer: Debian OpenMPI Maintainers pkg-openmpi-maintain...@lists.alioth.debian.org
 Uploaders: Manuel Prinz man...@debian.org, Sylvestre Ledru sylves...@debian.org
-Build-Depends: debhelper (= 5.0.0), libibverbs-dev (= 1.1.1) [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386], gfortran, gcc (= 4:4.1.2), chrpath, quilt
+Build-Depends: debhelper (= 5.0.0), libibverbs-dev (= 1.1.1) [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386], gfortran, gcc (= 4:4.1.2), chrpath, quilt, libcr-dev [amd64 i386 powerpc armel]
 Standards-Version: 3.8.3
 Vcs-Svn: svn://svn.debian.org/svn/pkg-openmpi/openmpi/trunk/
 Vcs-Browser: http://svn.debian.org/wsvn/pkg-openmpi/openmpi/trunk/

Bug#543263: closed by Alan Woodland awoodl...@debian.org (Bug#543263: fixed in blcr 0.8.2-3)

[Alan Woodland]

2009/8/25 Martin Zobel-Helas zo...@ftbfs.de:
 reopen 543263
 retitle 543263 Fails with Assembler messages
 version 543263 0.8.2-3
 thanks

 Hi,

 now it fails with

 | libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../libcr -I.. -D_GNU_SOURCE 
 -D_REENTRANT -I../include -I../../include -I../../libcr/arch/sparc/ -Wall 
 -Wno-unused-function -Wall -g -O2 -MT libcr_la-cr_async.lo -MD -MP -MF
 | +.deps/libcr_la-cr_async.Tpo -c ../../libcr/cr_async.c  -fPIC -DPIC -o 
 .libs/libcr_la-cr_async.o
 | /tmp/cckixYGU.s: Assembler messages:
 | /tmp/cckixYGU.s:619: Error: Architecture mismatch on membar.
 | /tmp/cckixYGU.s:619:  (Requires v9|v9a|v9b; requested architecture is 
 sparclite.)
 | /tmp/cckixYGU.s:620: Error: Architecture mismatch on cas.
 | /tmp/cckixYGU.s:620:  (Requires v9|v9a|v9b; requested architecture is 
 sparclite.)
 | /tmp/cckixYGU.s:621: Error: Architecture mismatch on membar.


I spotted this one again too. Looks like it won't work on sparclite
without some fairly serious porting work (I've been talking to
upstream about portability issues, including this). It really needs
async-safe atomic compare and swap routines as things currently stand.

Which would you see as the best option for the time being then?
Marking package as 'not for sparc', or compile with -mcpu=v9 (is that
the right option?) and fail gracefully at run time on older sparcs?
There's no way I can get a patch done to support sparclite without
some major work to the library itself (which upstream is interested in
and helpful in discussing)

I'm not 100% sure I agree with your justification of serious though -
it's not a miss-build, and it's never successfully built on sparc.

Alan



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

Bug#543263: Discussions on upstream mailing list about this bug

[Alan Woodland]

http://www.nersc.gov/hypermail/checkpoint/1250.html
http://www.nersc.gov/hypermail/checkpoint/1245.html



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

Bug#543263: blcr_0.8.2-2 FTBFS on sparc (dist=unstable)

[Alan Woodland]

tags 543263 confirmed
thanks

2009/8/23 Martin Zobel-Helas zo...@ftbfs.de:
 Package: blcr
 Version: 0.8.2-2
 Severity: serious

 checking for value of CR_ASM_OP_HAND_CHKPT... 2147787009
 checking for value of CR_ASM_CHECKPOINT_STUB... 16384
 checking for value of CR_ASM_OP_HAND_ABORT... 2147787010
 checking for value of CR_ASM_CHECKPOINT_OMIT... 4
 checking for value of CR_ASM_SI_PID_OFFSET... 12
 checking for value of CR_ASM_NR_ioctl... 54
 checking for value of CR_ASM_NR_rt_sigreturn... 101
 checking for direction of stack growth... down
 checking for value of CR_SIGNUM... 64
 checking for void *... (cached) yes
 checking size of void *... (cached) 4
 configure: error: --enable-multilib not supported on architecture sparc
 make: *** [build-arch-stamp] Error 1
 dpkg-buildpackage: error: debian/rules build gave error exit status 2


Oops, that's my mistake. I'll make an upload shortly that corrects this.

Alan



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

Bug#542643: Does not build with 2.6.30-1-686

[Alan Woodland]

2009/8/22 Paul H. Hargrove phhargr...@lbl.gov:
 Alan Woodland wrote:

 2009/8/22 Paul H. Hargrove phhargr...@lbl.gov:


 Removing the check for _end will negate the validation that is being
 performed.
 Instead, I would suggest that an alternative symbol should be used for
 validation.

 Does the build work after replacing ' [AB] _end' with ' [TD] sys_open' in
 the line quoted from configure?


 As far as I can make out patching configure as you suggested has the
 desired effect with no negative side effects. What I can't quite
 figure out still is why _end would disappear from Debian's 2.6.30
 System.map.

 If you're ok with it I'll make an upload with this patch applied to
 configure tonight or tomorrow.

 Alan


 Alan,

 Keep in mind that configure is generated from configure.ac.  If one were to
 touch configure.in, any changes in configure would get lost.  This makes the
 use of the patched source fragile. So, I suspect one wants to either:
 1) Patch ONLY configure.ac and regenerate configure
 OR
 2) Patch both and touch configure to avoid an automatic re-run of autoconf

 I suspect #2 is the best/safest bet because it does not require the end-user
 have autoconf.  However, you should probably ask around to see if there is a
 Debian standard for patches that affect files generated by autotools
 (autoconf, automake, etc.).  This can't be the first instance of something
 like this.

After re-running autoconf the kernel module part fails to build,
during configure with:

configure: error: conditional am__fastdepCXX was never defined.
Usually this means the macro was only invoked conditionally.
make: *** [binary-modules] Error 1

configure was called with:
./configure  --with-installed-libcr --with-installed-util
--with-components=modules --prefix=/usr --with-linux=2.6.30-1-686

I think this comes from this line of configure.ac:

# If building the tests, we can optionally test C++
if test x$cr_build_tests = xyes; then
  CR_PROG_CXX
fi

Calling CR_PROG_CXX unconditionally seems to prevent this problem, and
I can't see any obvious negative repercussions for doing so...

I knew there was a reason for not re-running autoconf!

Alan



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

Bug#542643: Does not build with 2.6.30-1-686

[Alan Woodland]

2009/8/22 Paul H. Hargrove phhargr...@lbl.gov:
 Removing the check for _end will negate the validation that is being
 performed.
 Instead, I would suggest that an alternative symbol should be used for
 validation.

 Does the build work after replacing ' [AB] _end' with ' [TD] sys_open' in
 the line quoted from configure?

As far as I can make out patching configure as you suggested has the
desired effect with no negative side effects. What I can't quite
figure out still is why _end would disappear from Debian's 2.6.30
System.map.

If you're ok with it I'll make an upload with this patch applied to
configure tonight or tomorrow.

Alan



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

Bug#541818: blcr: Support for more arches.

[Alan Woodland]

On 16 Aug 2009, at 21:16, Paul H. Hargrove wrote:
[snip]

I'll keep that info around for anyone else who asks about other  
architectures.


 Regarding the question of *BSD or Hurd (ignoring that L in BLCR  
stands for Linux):
While I don't want to totally rule-out the possibility, I doubt  
that porting to another OS is an easy task.  Counting only arch- 
independent code here are about 14,000 lines in cr_module and over  
2,000 in vmadump_common.c.  I can identify less than 1,500 of those  
lines as doing something OS-independent; the rest is all dealing  
with Linux kernel data structures.  So, to be honest I think if  
somebody were to port BLCR to another OS they will have earned  
the right to name their package something else if they want.
It would be handy for me as a developer to have the same libcr  
interface on hurd and *bsd platforms for checkpointing features  
should any hurd/BSD developers end up reading this. Might make an  
interesting project for a suitably motivated student I guess too, so  
I might see about adding it to the list of suggested projects.



Alan,
 I the interest of the least confusion among potential users, I do  
think marking the package as arch-specific (i386, amd64, arm, ppc,  
ppc64) and os-specific (linux) is the best practice.  Users who  
want BLCR for unsupported arches will probably still ask why is my  
arch not supported?.  If/when a future release adds arches, then  
the arch-specific list can expand, right?
That is correct, the architecture list can be amended with every  
upload that is made. (Correcting it would be a valid reason to make  
an upload). From the point of view of an end user it doesn't make any  
difference whether the architecture list says 'any' or just the ones  
it's known to work on. Debian users only get to see packages that  
have correctly built for their architecture in this list of available  
packages unless they're explicitly looking for source, in which case  
they might be inclined towards porting it. They should also get  
marked 'Not For Us' at some point which stops the load on the build  
system too.


From my POV the most useful feature of having it listed as 'any' to  
start with is that the port maintainers get to see it failing in the  
automated build system. I suspect these are also the people most  
likely to have time and inclination to add support for their  
architecture.


A (limited) survey of existing modules suggests this seems to be the  
approach taken by most kernel modules except those that rely on  
binary blobs. Since this doesn't impact users at all (only developers  
and mostly porters) and given that configure fails reliably and  
cleanly I don't think there's too much point changing this.


Alan



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

Bug#541818: blcr: Support for more arches.

[Alan Woodland]

(For readers on checkpo...@lbl.gov blcr was accepted into Debian last  
night)



It seems that your package currently doesn't work on all arches.
It fails with errors like:
checking build system type... alphaev68-unknown-linux-gnu
checking host system type... alphaev68-unknown-linux-gnu
configure: error: Sorry, architecture alphaev68 is not supported
at this time.

This is correct


It seems that it atleast requires some porting work to add
other arches, but I think it's actually not that much?
Mostly it's just vmadump that would need porting I think. It's pretty  
sensitive to layout of process related structs I think, as well as  
low level specifics like registers that are architecture dependent  
obviously. The source is well structured and tidy though so someone  
knowledgeable about the unsupported architectures should find it easy  
enough to patch I think. The relevant places are:

- vmadump4/
- libcr/arch/
- cr_module/arch/

I just noticed too that there is actually a alpha version of vmadump  
already there, so it's just libcr and cr_module that's missing for  
alpha.


I deliberately didn't mark it as amd64, i386, sparc, arm and ppc only  
in the hopes that someone with hardware, time and knowledge might  
contribute patches.



It also looks like this is Linux specific?  Do you think
this can work on kfreebsd or hurd?
Hmm, that's an interesting one. The user space bits do a pretty good  
job of insulating you from any/all kernel space mechanics that make  
the checkpointing possible. I guess that means in theory it would be  
possible to do quite sanely. I've got precisely no experience with  
any *bsd kernel space development, and my knowledge of hurd is almost  
the same too. Maybe it would have made sense to mark it as not for  
the non-linux ports though to save the buildds from trying every time.


I'm always interested in patches and I'm pretty sure upstream would  
be grateful also.


Alan



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

Bug#537275: Suggestions?

[Alan Woodland]

tags 537275 +help
thanks

Hi,

This is a general call for help really - I don't have KDE 4 available
to test things with, and I'm not too familiar with egg tray icons...
patches would be much appreciated.

Alan



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

Bug#538407: libmagic1: Please add support for recognising BLCR context files

[Alan Woodland]

Package: file
Version: 5.03-1
Severity: wishlist
Tags: patch

I'm currently packaging BLCR (ITP: #529619), and the source for it includes 
blcr.magic, which would be useful to see in the main libmagic 
packages.

Thanks,
Alan
#  This is file type detection data for the file(1), as described in the
#  magic(5) manpage.  In most cases adding this to /etc/magic will allow
#  the file(1) utility to identify BLCR's context files.  However, you
#  should consult your file(1) and magic(5) manpages to determine the
#  proper location for your own installation.
#
# Berkeley Lab Checkpoint Restart (BLCR) checkpoint context files
# http://ftg.lbl.gov/checkpoint
0   string  C\0\0\0R\0\0\0  BLCR
16 lelong  1   x86
16 lelong  3   alpha
16 lelong  5   x86-64
16 lelong  7   ARM
8  lelong  x   context data (little endian, version %d)
# Uncomment the following only of your file program supports search
#0 search/1024 VMA\06  for kernel 
#1   bytex   %d.
#2   bytex   %d.
#3   bytex   %d
0   string  \0\0\0C\0\0\0R  BLCR
16 belong  2   SPARC
16 belong  4   ppc
16 belong  6   ppc64
16 belong  7   ARMEB
16 belong  8   SPARC64
8  belong  x   context data (big endian, version %d)
# Uncomment the following only of your file program supports search
#0 search/1024 VMA\06  for kernel 
#1   bytex   %d.
#2   bytex   %d.
#3   bytex   %d

Bug#529619: Fwd: BLCR Debian Packages

[Alan Woodland]

Forgot to CC the ITP bug...


-- Forwarded message --
From: Alan Woodland alan.woodl...@gmail.com
Date: 2009/7/23
Subject: BLCR Debian Packages
To: checkpo...@lbl.gov checkpo...@lbl.gov
Cc: Alan Woodland awoodl...@debian.org


Hi,

A Debian user has requested packages of BLCR.
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529619)

As a BLCR user and Debian developer, with a vested interest in seeing
BLCR packages I thought I'd give it a go myself (I hope that's ok with
you?). I'm in the process of packaging things, but I've got a few
questions/issues I'd like to check up on:

1) Are the userspace parts (library, utilities and development
headers) are independent of the running kernel version? They only
depend upon a kernel module of the same BLCR version for the current
running kernel correct? The package structure that fits best with the
Debian way is to make libcr0, libcr-dev blcr-util, blcr-source (and on
amd64 lib32cr0), as well as blcr-modules-KERNEL appropriate to the
release. To build all the userspace bits I'm currently configuring
with the '--with-installed-modules' option.

2) To build the blcr-modules-KERNEL the ideal solution would be to use
module assistant (this means that even on custom kernels users could
type 'm-a a-i blcr' and get a working kernel module automagicaly built
for them. In order to do this there needs to be a cut down source
tarball built, which lives inside the blcr-source package that can
build the kernel modules for a given kernel. At the moment I'm just
re-taring the whole of the BLCR source tree for this and then making
module assistant call the whole configure script again, with
--with-installed-libcr --with-installed-util --with-components=modules
so that it only builds the kernel modules. Is there a nicer way of
going about this? The configure script is obviously critical here, but
can you suggest a nice way of trimming things down? Most modules seem
to end up just shipping *.c and *.h required for the kernel module in
this, along with a paired down makefile. I did wonder about moving the
kernel space bits into a sub-tree and having configure call configure
on a subdirectory, but that's a pretty substantial patch.

Does this sound reasonable? Would someone be willing to test (and
review?) this for me? I'd very much like to see BLCR in Debian, but I
don't want to end up acting unilaterally!

Thanks,
Alan



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

Bug#529619: BLCR Debian Packages

[Alan Woodland]

2009/7/23 Guy Coates g...@sanger.ac.uk:
 I'm not a DD, but I do have some experience with packaging (including the joy 
 of
 module-assistant), so I'd be happy to review the packages.


Wow, quite a lot of interest in a short space of time!

First rough cut packages are online @ http://users.aber.ac.uk/ajw/debian/
They're definitely not ready for uploading, I've only built them on
Lenny so far (that's my main priority right now for $day_job usage).
Modules seem to build ok with m-a a-i blcr, although I can't actually
insmod them yet since I've been building them for a kernel I've not
yet booted! (Long running job on my desktop).

Known issues:
- Various mentions of AUFS in package descriptions/documentation, I
used AUFS packages as a starting point.
 (hey, if it passes lintian, it must be fine, right :)
- A few lintian warnings, mostly about the copyright file (which
doesn't reference the locally installed one yet, and has the old FSF
address etc.)
- The blcr.tar.bz2 shipped in the blcr-source package is 'heavy' to
say the least.
- module assistant mostly prints incomplete junk in the progress
dialog whilst it's building (I've no idea how to fix that properly)
- probably not integrated right with the rest of module-assistant
anyway, I have exactly 0 experience with module-assistant packaging
until now.
- Dependencies might be wrong until I try doing things in a chroot to check
- No postinst script yet for the modules package.

Anyone care to use/break/test/review/critique/patch these?

Thanks,
Alan

P.S. Rather nice packaging something that has manpages already
written, and a version for the shared objects that isn't just 0.0.0!



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

Bug#529619: ITP BLCR

[Alan Woodland]

package wnpp
owner 529619 Alan Woodlandawoodl...@debian.org
retitle 529619 ITP: blcr -- Berkeley Lab Checkpoint/Restart
thanks

I've been using this quite a lot lately on several clusters as well as
my desktops. Would be very handy to see this in Debian, and I can
probably do some packaging as part of my day job!

* Package name: blcr
  Version : 0.8.2
  Upstream Author : checkpo...@lbl.gov
* URL :
https://ftg.lbl.gov/CheckpointRestart/CheckpointRestart.shtml
* License : GPL2/LGPL
  Programming Lang: C
  Description : Checkpoint/Restart support for Linux

Alan



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

Bug#503631: confirmation

[Alan Woodland]

 wrote:
 Hi all!
 
 First of all, this bug is ages old, it's been around at least from 4.3. 
 onwards.
 
 Second, it is amd64-only; I can reproduce it with 100% certainty on all 
 amd64-machines, but nowhere else (including, btw, one 64-bit alpha).
 
 Third, dx works fine nevertheless: executive works, program runs etc, it's 
 simply not possible to edit the program due to the layout bug.

I have the exact same symptoms here. Interestingly I ran dxui through
valgrind and got a few warnings about using uninitalised memory:

==7745== Source and destination overlap in memcpy(0xBCB2720, 0xBCB2740, 96)
==7745==at 0x4C2323A: memcpy (mc_replace_strmem.c:402)
==7745==by 0x5A0330E: _XmBuildResources (in /usr/lib/libXm.so.2.0.1)
==7745==by 0x59EF1FC: (within /usr/lib/libXm.so.2.0.1)
==7745==by 0x7E51350: (within /usr/lib/libXt.so.6.0.0)
==7745==by 0x7E51350: (within /usr/lib/libXt.so.6.0.0)
==7745==by 0x7E51835: XtInitializeWidgetClass (in
/usr/lib/libXt.so.6.0.0)
==7745==by 0x7E527D8: _XtCreateWidget (in /usr/lib/libXt.so.6.0.0)
==7745==by 0x7E809A8: (within /usr/lib/libXt.so.6.0.0)
==7745==by 0x7E80BD3: XtVaCreateManagedWidget (in
/usr/lib/libXt.so.6.0.0)
==7745==by 0x47B234: EditorWindow::createWorkArea(_WidgetRec*)
(EditorWindow.C:1290)
==7745==by 0x5484AF: MainWindow::initialize() (MainWindow.C:282)
==7745==by 0x544148: IBMMainWindow::initialize() (IBMMainWindow.C:194)
==7745==
==7745== Conditional jump or move depends on uninitialised value(s)
==7745==at 0x59DEDA2: _XmCalcLabelDimensions (in
/usr/lib/libXm.so.2.0.1)
==7745==by 0x59DF730: (within /usr/lib/libXm.so.2.0.1)
==7745==by 0x7E51428: (within /usr/lib/libXt.so.6.0.0)
==7745==by 0x7E51E64: (within /usr/lib/libXt.so.6.0.0)
==7745==by 0x7E5279B: _XtCreateWidget (in /usr/lib/libXt.so.6.0.0)
==7745==by 0x7E809A8: (within /usr/lib/libXt.so.6.0.0)
==7745==by 0x7E80BD3: XtVaCreateManagedWidget (in
/usr/lib/libXt.so.6.0.0)
==7745==by 0x4D4A9B: PageSelector::buildSelector() (PageSelector.C:261)
==7745==by 0x4D5D2A: PageSelector::PageSelector(EditorWindow*,
_WidgetRec*, Network*) (PageSelector.C:174)
==7745==by 0x47B3BF: EditorWindow::createWorkArea(_WidgetRec*)
(EditorWindow.C:1323)
==7745==by 0x5484AF: MainWindow::initialize() (MainWindow.C:282)
==7745==by 0x544148: IBMMainWindow::initialize() (IBMMainWindow.C:194)
==7745==
==7745== Conditional jump or move depends on uninitialised value(s)
==7745==at 0x59DE07D: _XmLabelGetPixmapSize (in /usr/lib/libXm.so.2.0.1)
==7745==by 0x59DED54: _XmCalcLabelDimensions (in
/usr/lib/libXm.so.2.0.1)
==7745==by 0x59DF730: (within /usr/lib/libXm.so.2.0.1)
==7745==by 0x7E51428: (within /usr/lib/libXt.so.6.0.0)
==7745==by 0x7E51E64: (within /usr/lib/libXt.so.6.0.0)
==7745==by 0x7E5279B: _XtCreateWidget (in /usr/lib/libXt.so.6.0.0)
==7745==by 0x7E809A8: (within /usr/lib/libXt.so.6.0.0)
==7745==by 0x7E80BD3: XtVaCreateManagedWidget (in
/usr/lib/libXt.so.6.0.0)
==7745==by 0x4D4A9B: PageSelector::buildSelector() (PageSelector.C:261)
==7745==by 0x4D5D2A: PageSelector::PageSelector(EditorWindow*,
_WidgetRec*, Network*) (PageSelector.C:174)
==7745==by 0x47B3BF: EditorWindow::createWorkArea(_WidgetRec*)
(EditorWindow.C:1323)
==7745==by 0x5484AF: MainWindow::initialize() (MainWindow.C:282)
^C==7745==
==7745== ERROR SUMMARY: 4 errors from 3 contexts (suppressed: 12 from 2)
==7745== malloc/free: in use at exit: 1,127,265 bytes in 17,721 blocks.
==7745== malloc/free: 28,373 allocs, 10,652 frees, 5,401,815 bytes
allocated.
==7745== For counts of detected errors, rerun with: -v
==7745== searching for pointers to 17,721 not-freed blocks.
==7745== checked 7,251,808 bytes.

The ones in _XmLabelGetPixmapSize sound like they could be to blame
maybe, but I can't quite figure out the source of it...

 Also, the layout bug can be fixed by recompiling against libmotif-dev instead 
 of lesstif2-dev, so I guess blame can be squarely placed on lesstif2 or its 
 use by dx.

That's handy to see a work-around at least!

Alan



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

Bug#412437: getdeb.net deb source (+ Alioth project)

[Alan Woodland]

2009/1/18 Ryan Niebur ryanrya...@gmail.com:
 Hi,

 (sorry for the late response)

 On Tue, Jan 13, 2009 at 10:14:18AM +, Alan Woodland wrote:
 Savvas Radevic wrote:
 Also this personal package archive (Fabien Tassin):
 http://ppa.launchpad.net/fta/ubuntu/pool/main/s/songbird/
 The project on alioth has been approved now, and I've added Ryan to the
 developers on it. I did have a quick look over the Ubuntu source they
 have in launchpad yesterday lunchtime, but didn't build it yet. I also
 couldn't quite figure out how to make git play nice with bzr either. Any
 thoughts on that yet Ryan? Feel free to set something up on the group
 filespace on alioth if you want!

 There's this http://github.com/pieter/git-bzr/tree/master
 It claims to work with the git-core in experimental.

 I can try to figure out how to make it play nice with git-buildpackage
 (if possible..)
That would be good if you could give that a try?

 or we could just not use git-buildpackage (just keep the debian
 directory in a git repo w/o upstream source)
There's still the issue of if we should view ubuntu as an intermediate
upstream or just fork what they've already got.

git-buildpackage does sound quite reasonable to me.

 If that doesn't work out, I'm not completely opposed to using bzr..

 do you have an opinion on it?
So far I've used neither git nor bzr, my own work repositories are
only starting to migrate from CVS to SVN at the moment!

 any of those solutions are fine with me.
 (git w/o upstream source would be my choice).
That works for me provided we find a solution to integrate with
ubuntu's packaging efforts.

Alan



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

Bug#412437: getdeb.net deb source (+ Alioth project)

[Alan Woodland]

Savvas Radevic wrote:

I don't know if this helps, but the getdeb.net team has already
packaged version 1.0.0
Here's the deb source along with some ubuntu 8.10 intrepid ibex deb packages:
http://archive.getdeb.net/getdeb/ubuntu/intrepid/so/
  
The getdeb packages are basically just a wrapper around the binarys 
distributed by upstream themselves as far as I could see.

Also this personal package archive (Fabien Tassin):
http://ppa.launchpad.net/fta/ubuntu/pool/main/s/songbird/
The project on alioth has been approved now, and I've added Ryan to the 
developers on it. I did have a quick look over the Ubuntu source they 
have in launchpad yesterday lunchtime, but didn't build it yet. I also 
couldn't quite figure out how to make git play nice with bzr either. Any 
thoughts on that yet Ryan? Feel free to set something up on the group 
filespace on alioth if you want!


Alan



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

Bug#412437: start the team?

[Alan Woodland]

2009/1/2 Alan Woodland alan.woodl...@gmail.com:
 2008/12/31 Ryan Niebur ryanrya...@gmail.com:
 Hi,

 Alan, since you've already worked on this a bit, do you want to start
 the team and the repository with what you already have done?  Then any
 of us can work on integrating in some of the work that Ubuntu did.
 Sounds like a plan. I'm away for a couple more days, when I get back
 I'll set things in motion.

 Alan
I've submitted the project to alioth for approval now, so should be
under 72 hours until things are up and running for it.

Alan



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

Bug#412437: start the team?

[Alan Woodland]

2008/12/31 Ryan Niebur ryanrya...@gmail.com:
 Hi,

 Alan, since you've already worked on this a bit, do you want to start
 the team and the repository with what you already have done?  Then any
 of us can work on integrating in some of the work that Ubuntu did.
Sounds like a plan. I'm away for a couple more days, when I get back
I'll set things in motion.

Alan



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

Bug#412437: songbird

[Alan Woodland]

2008/12/1 Ryan Niebur [EMAIL PROTECTED]:
 Hi,

 It looks like there isn't much happening with packaging songbird. I'm
 interested in helping with songbird, too. Would you like to start an
 alioth team to work on it? I'd be happy to help. If you're gonna start
 a team, I really don't care about what type of VCS you use, I know 'em
 all (except CVS :D). I prefer git, though...

 If you don't have time to set up a team, I will, just tell me to. :)

 Anyway, I think that a team would help get some work going, and then
 we could songbird into Debian.

Team sounds like a good plan. I'm very short on time at the moment,
and building songbird with debian's xulrunner library was more fiddly
than I originally anticipated.

I'd vote for SVN personally since that's what I use at work everyday,
but I'm flexible :-)

Alan



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#503631: Re: Bug#503631: dx: Visual Program Editor doesn't shows networks

[Alan Woodland]

Mark Purcell wrote:
 Package: dx
 Followup-For: Bug #503631
 
 tags 503631 unreproducible
 severity 503631 important
 subscribe 503631 [EMAIL PROTECTED]
 thanks
 
 David, Daniel,
 
 I am unable to reproduce this RC bug on lenny. I obtain
 an empty window titled Untitled which allows me to
 add network components.
 
 As such I am reducing the severity of this bug report.

I can confirm that I am also seeing thins - I get exactly the same
problem on my AMD64 machine, but not on my i386 one... which makes me
suspect that it's some lurking 64bit bug somewhere?

I can also be reasonable sure that dxexec is working correctly - if I
use the data prompter to import data it displays the Image window
correctly, just not the VPE.

Alan




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#493247: FTBFS on armel - uses -fshort-wchar option

[Alan Woodland]

Riku Voipio wrote:

Package: mozilla-traybiff
Version: 1.2.3-4.1
Severity: serious

armel buildlog:

g++ -L/usr/lib/iceape -lxpcom -lplds4 -lplc4 -lnspr4 -lpthread -ldl 
-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 
-lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0   
-Wl,--discard-all -Wl,-Bsymbolic 
-Wl,--version-script=libtraybiff.version_script -shared -o libtraybiff.so 
trayBiffModule.o nsMessengerFreeDesktopIntegration.o eggtrayicon.o 
eggstatusicon.o eggmarshalers.o
/usr/bin/ld: ERROR: trayBiffModule.o: Conflicting definitions of wchar_t
/usr/bin/ld: failed to merge target specific data of file trayBiffModule.o
/usr/bin/ld: ERROR: nsMessengerFreeDesktopIntegration.o: Conflicting 
definitions of wchar_t
/usr/bin/ld: failed to merge target specific data of file 
nsMessengerFreeDesktopIntegration.o
collect2: ld returned 1 exit status

trivial patch added. I see your packages have seen nothing NMU's recently, so 
I'll proceed
to upload this and the RC-buggy ogle package over the weekend...

  
Go for it, sorry my spam filter seems to have been being rather zealous 
lately!


Alan



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#486170: not compatible with iceweasel 3.0

[Alan Woodland]

tags 486170 +upstream
tags 486170 +confirmed
thanks

Hi,

Thanks for the bug report. I'm currently waiting for upstream to make a
new release fixing this:

http://www.mozdev.org/pipermail/sage/2008-May/001560.html

Alan



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#480822: Don't build depend on libxul-dev

[Alan Woodland]

2008/5/17 Mike Hommey [EMAIL PROTECTED]:
 On Sat, May 17, 2008 at 11:32:49AM +0200, Mike Hommey wrote:
 tag 480822 + patch
 thanks

 On Mon, May 12, 2008 at 09:07:27AM +0200, Mike Hommey wrote:
  Package: mozilla-traybiff
  Severity: wishlist
  User: [EMAIL PROTECTED]
  Usertags: xulrunner-transition
 
  With the upcoming xulrunner transition, libxul-dev is going to disappear.
 
  I already sent instructions on what you should be doing in
  http://lists.debian.org/debian-release/2008/05/msg9.html
 
  This bug report is mostly to help follow the transition going.
 
  FYI, I will start NMUing plugins and components next week, and will break
  the remaining packages by uploading xulrunner 1.9 in unstable on May 25.
 
  Though help will be appreciated, I'll also prepare updated packages for
  these during this week and next.

 Here is the patch to implement the change. Please upload a new package
 with the patch applied ASAP. Without action from your part within the
 next week, I'll upload a NMU.

 With the patch, this time.

Hi, I'm away in Austria at the moment until the end of the week, so an
upload from me isn't very likely.  Feel free to NMU, at your
convenience.

Thanks,
Alan



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#470124: ogle: diff for NMU version 0.9.2-5.1

[Alan Woodland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

tags 470124 +confirmed
thanks

Marc Brockschmidt wrote:
 Package: ogle
 Version: 0.9.2-5
 Severity: normal
 Tags: patch
 
 Hi,
 
 Attached is the diff for my ogle 0.9.2-5.1 NMU.

Thanks for doing that, sorry I didn't get round to it before you made
the upload.

Alan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIBNJt1FNW1LDdr0IRAqHxAJ9QpKUmc8TVyZ3ZfBgbccULr6KIKACgpPzy
ItPrF8aV4MJU6AWx96IoE3o=
=B/0Q
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]