Bug#1002956: Remote RCE in rabbitmq-server

[Tim Abbott]

On Wed, Aug 3, 2022 at 12:22 AM Thomas Goirand  wrote:

> Hi Tim,
>
> Please don't top-post, we don't do that in Debian, and also:
>

Apologies!

FYI, I'm sad too, but there's nothing I can do but pinging again the
> stable release team about this. You hear me well: the stable release
> team. Not the security team since they do not want to do a security
> announcement and an update through stable-security (so it shall be done
> through a point release, dealing with the stable release team).
>
> This means writing to 1002...@bugs.debian.org. That's the only email
> address that has influence on accepting the fixed version. Feel free to
> ping that email address until you get a reply. I agree that no reply
> since the 29th of Jan is sad...
>

I still don't understand why the determination was made to not do a
security announcement for this bug, given that it makes a Debian system
that installs this package vulnerable to remote RCE without manual
intervention.

But given that determination was made, perhaps the best way I can
contribute is by making sure this bug thread links to
https://blog.zulip.com/2022/01/25/zulip-server-4-9-security-release/#cve-2021-43799-remote-code-execution-vulnerability-involving-rabbitmq,
which has a bunch of public context about the impact of this bug, as well
as background explanation that may help release managers who don't know
much about Erlang/RabbitMQ.

-Tim Abbott

Bug#827209: Please package new version

[Tim Abbott]

Package: python-ujson
Version: 1.33-1
Severity: wishlist

Version 1.35 is out now, and adds some new features (e.g. the `intent`
option) that make it more compatible with simplejson, so it seems worth
doing an update.  Thanks!

-Tim Abbott

Bug#819613: ITP: python-typing -- Type Hints for Python 2

[Tim Abbott]

Package: wnpp
Severity: wishlist

Package name: python-typing
Version: 3.5.0.1
Upstream Author: Guido van Rossum, Jukka Lehtosalo, and Łukasz Langa
License: Python
URL: https://github.com/python/typing
Description: Typing -- Type Hints for Python
 .
 This is a backport of the standard library typing module to Python
 versions older than 3.5.
 .
 Typing defines a standard notation for Python function and variable
 type annotations. The notation can be used for documenting code in a
 concise, standard format, and it has been designed to also be used by
 static and runtime type checkers, static analyzers, IDEs and other
 tools.

Bug#764433: RFA: tachyon

[Tim Abbott]

Package: wnpp
Severity: normal

I request an adopter for the tachyon package.

The package description is:

Tachyon is a portable, high performance parallel ray tracing system
supporting
MPI and multithreaded implementations. Tachyon is built as a C callable
library,
which can be used with the included demo programs or within your own
application.
The distribution also includes a simple scene file parser front-end
which reads
a few different formats.

Tachyon implements all of the basic geometric primitives such as
triangles, planes,
spheres, cylinders, etc. Some of the goals in developing Tachyon were
to make it fast
and for it to parallelize well. These are what set it apart from more
full-featured
programs like POV-Ray, Rayshade, and others. Tachyon supports enough
features to be
an excellent alternative to slower programs for demanding animation and
scientific
visualization tasks. As time goes on, Tachyon will indeed incorporate
more features,
but with a continued emphasis on rendering performance.

Jerome Benoit has privately expressed interest.

Bug#762746: RFA: sympow

[Tim Abbott]

Package: wnpp
Severity: normal

I request an adopter for the sympow package.

The package description is:

  SYMPOW is a scientific program for computing special values of symmetric
  power elliptic curve L-functions.

Jerome Benoit has privately expressed interest.


-Tim Abbott

Bug#761243: RFA: symmetrica

[Tim Abbott]

Package: wnpp
Severity: normal

I request an adopter for the symmetrica package.

The package description is:

  Symmetrica is a library for combinatorics. It has support for the
  representation theory of the symmetric group and related groups,
  combinatorics of tableaux, symmetric functions and polynomials,
  Schubert polynomials, and the representation theory of Hecke
  algebras of type A_n.

Jerome Benoit has privately expressed interest.

-Tim Abbott

Bug#760345: RFA: gap-guava

[Tim Abbott]

Package: wnpp
Severity: normal

I request an adopter for the gap-guava package.

The package description is:

  Coding theory library for GAP

GUAVA is a package that implements coding theory algorithms in GAP.
Codes can be created and manipulated and information about codes can
be calculated.

Jerome Benoit has privately expressed interest.

-Tim Abbott

Bug#743328: genus2reduction: obsoleted by libpari 2.7

[Tim Abbott]

Sounds good to me!


-Tim Abbott


On Tue, Apr 15, 2014 at 2:12 AM, Tobias Hansen  wrote:

> Hi Bill,
>
> I already did.
>
> Cheers,
> Tobias
>
> On 04/15/2014 11:02 AM, Bill Allombert wrote:
> > Woould anybody object if I asked for the removal of this package ?
> > As far as I can see it is not maintained, buggy, and quite useless now
> > that gp includes the functionnality (without the bugs).
> >
> > Cheers,
>

Bug#693672: config-package-dev: please support using debhelper dh instead of cdbs

[Tim Abbott]

Geoffrey Thomas actually has a branch adding support for doing it via
debhelper -- Anders and I have unfortunately been slow about reviewing it.
I'll see if I can find the time to get it out.

-Tim Abbott


On Mon, Nov 19, 2012 at 1:31 AM, Paul Wise  wrote:

> Package: config-package-dev
> Version: 4.13
> Severity: wishlist
>
> I personally prefer using debhelper's dh system instead of cdbs. It
> would be great if config-package-dev could support configuration
> packages built using debhelper's dh system and drop the cdbs dep.
>
> -- System Information:
> Debian Release: wheezy/sid
>   APT prefers testing
>   APT policy: (700, 'testing'), (600, 'unstable'), (550, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.6-trunk-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages config-package-dev depends on:
> ii  cdbs  0.4.115+deb7u1
>
> --
> bye,
> pabs
>
> http://wiki.debian.org/PaulWise
>



-- 
-Tim Abbott

Bug#660288: Please enable CONFIG_KALLSYMS_ALL

[Tim Abbott]

On 06/07/2012 07:34 PM, Ben Hutchings wrote:


On Mon, Jun 04, 2012 at 05:26:28PM -0400, Tim Abbott wrote:
> Hi Ben,
>
> Your comment about source code is rather off-topic for this bug
> report, but since there seems to be a misunderstanding on this
> point, I'd like to clarify: Every Ksplice update tarball ships with
> a README file containing instructions on how to request the source
> code for that update from the appropriate people in Oracle Legal.
> Anyone who follows those instructions can get a copy of the relevant
> source code.

I understand that Matthew Garrett tried to take up this offer a while
ago, and is still waiting for complete source code.  It doesn't seem
to be a good faith attempt to fulfil GPL obligations.
This is not my department, but as I understand it, Matthew Garrett 
received complete source code in response to each of his various 
requests for Ksplice source code.



> To briefly clarify my original email, it is true that enabling
> CONFIG_KALLSYMS_ALL would make life slightly easier for Ksplice and
> similar tools that look at kernel data structures (e.g. debugging
> tools).

No doubt true, but it is also strictly redundant with debuginfo.
This is where I disagree.  Debuginfo is both huge (since it contains 
lots of data beyond the basic symbol information in kallsyms) and is 
also not necessarily available on user systems, meaning that any sort of 
patching or debugging tool intending to get wide use can't rely on it.  
Further, any system which contains third-party modules (open source or 
not) will not have symbol data for those modules unless the vendors of 
those third-party modules provide a separate debuginfo package (many do 
not); with kallsyms, you're guaranteed to have accurate information that 
comes from the modules that are actually loaded on the system.


As I think I mentioned before, when folks upgrade the kernel version on 
disk on a Debian system and don't immediately reboot (which folks do 
_all the time_ whether they're using Ksplice or not), and then load 
kernel modules, they'll get kernel modules from the upgraded kernel (at 
least in the common case where the ABI doesn't change). As a 
consequence, if you're any sort of debugging/instrumentation tool that 
inspects the running kernel's code, you need to be able to handle the 
case where the kernel is running modules that don't actually go with 
either the running kernel (via "uname -a") or the currently version of 
the linux-image-* package installed on disk. Trying to do anything to 
get symbol information in that sort of situation using debuginfo is a 
disaster; what you want is kallsyms.



> That said, Ksplice doesn't require CONFIG_KALLSYMS_ALL --
> the Ksplice Uptrack service has been providing updates for systems
> running Debian Linux since 2009.  While your enabling
> CONFIG_KALLSYMS_ALL might allow us to delete like 50 lines of code 2
> years from now when Squeeze reaches end of life, I submitted this
> bug report primarily because I'd like it to be the case that other
> folks developing similar innovative new technologies don't have to
> do the extra work of supporting !CONFIG_KALLSYMS_ALL in order to
> support all the major Linux distributions.  I hope you'll consider
> my suggestion on its technical merits.
  
I'm going to have see a request from an actual other person before I

care to spend time on this.

(In case anyone else in the kernel team wants to proceed with this,
that's not a NAK.  The issue is that memory and/or flash partition
constraints make this unsuitable for some configurations, and you'll
need to work out which ones to enable it for.)
CONFIG_KALLSYMS_ALL adds less than 1% to the size of the kernel over 
CONFIG_KALLSYMS (obviously this depends on what options one had enabled 
in the first place), so only on truly embedded settings will that matter 
at all.  Could you at least just enable it for the architectures where 
none of Debian's stock kernels are designed for embedded environments 
(e.g. x86, sparc, power)?


-Tim Abbott

Bug#675714: tachyon: diff for NMU version 0.99~b2+dfsg-0.4

[Tim Abbott]

Mònica,

Thanks for taking care of this bug; your patch looks good.

-Tim Abbott

On Wed, 20 Jun 2012, Mònica Ramírez Arceda wrote:

> tags 675714 + pending
> thanks
> 
> Dear maintainer,
> 
> I've prepared an NMU for tachyon (versioned as 0.99~b2+dfsg-0.4) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.
> 
> Regards.
> 

Bug#660288: Please enable CONFIG_KALLSYMS_ALL

[Tim Abbott]

Hi Ben,

Your comment about source code is rather off-topic for this bug report, 
but since there seems to be a misunderstanding on this point, I'd like 
to clarify: Every Ksplice update tarball ships with a README file 
containing instructions on how to request the source code for that 
update from the appropriate people in Oracle Legal.  Anyone who follows 
those instructions can get a copy of the relevant source code.


To briefly clarify my original email, it is true that enabling 
CONFIG_KALLSYMS_ALL would make life slightly easier for Ksplice and 
similar tools that look at kernel data structures (e.g. debugging 
tools).  That said, Ksplice doesn't require CONFIG_KALLSYMS_ALL -- the 
Ksplice Uptrack service has been providing updates for systems running 
Debian Linux since 2009.  While your enabling CONFIG_KALLSYMS_ALL might 
allow us to delete like 50 lines of code 2 years from now when Squeeze 
reaches end of life, I submitted this bug report primarily because I'd 
like it to be the case that other folks developing similar innovative 
new technologies don't have to do the extra work of supporting 
!CONFIG_KALLSYMS_ALL in order to support all the major Linux 
distributions.  I hope you'll consider my suggestion on its technical 
merits.


    Best regards,
-Tim Abbott

On 06/02/2012 10:51 PM, Ben Hutchings wrote:

On Fri, 2012-02-17 at 15:35 -0500, Tim Abbott wrote:

Package: linux-2.6
Severity: wishlist

(Moving this topic from a debian-kernel thread to the BTS).

Would it be possible to turn on CONFIG_KALLSYMS_ALL in the Debian kernel
for Wheezy? It's a useful debugging option, and makes it easier to
implement useful tools like Ksplice that inspect the code and data
structures of the running kernel, in particular in relation to operating
on modules (one can use System.map to look up addresses for data
structures in the core kernel). Most other major Linux distributions
have had CONFIG_KALLSYMS_ALL enabled in their kernels for some time now
(RHEL, Fedora, Ubuntu, etc.).

The discussion so far of why this option is useful on the debian-kernel
thread is at:
<http://lists.debian.org/debian-kernel/2012/01/msg01017.html>.

So I think you're saying that you need this to make ksplice work.
I would be much more interested in helping you to do that if you would
start releasing source to ksplice patches.

Ben.




--
-Tim Abbott




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

Bug#592354: fplll

[Tim Abbott]

Hey Bart,

Yes I'm quite happy to have Julien doing NMUs with the fplll package -- 
he's been helping with get some of the packages that I maintain up to date 
since I've been too busy to do so of late.  Thanks,

-Tim Abbott

On Fri, 25 May 2012, Bart Martens wrote:

> Hello Julien,
> 
> Did you get permission from Tim Abbott to NMU fplll ?
> http://mentors.debian.net/package/fplll
> http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu
> 
> Regards,
> 
> Bart Martens
> 



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

Bug#662001: singular: should this package be removed?

[Tim Abbott]

Hi Simon,

Bernhard Link has been organizing a group of folks to take over 
maintaining this package.

Also, I should mention it is not primarily a library -- the main use case 
for singular is a command-line repl for doing mathematical calculations; 
the library version is only used by the sagemath software (not currently 
in Debian).

So I'd recommend against removing the package at this time.

    -Tim Abbott

On Sat, 3 Mar 2012, Simon McVittie wrote:

> Package: singular
> Version: 3-0-4-3.dfsg-3
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: proposed-removal
> 
> singular seems like a possible candidate for removal from Debian:
> 
> * library with no reverse dependencies
> * no maintainer upload since 2009
> * no maintainer response to an RC bug for several months
> * assorted linking problems (see the patches from Mònica's attempted NMU)
> 
> If you don't think this package is needed any more, please send the
> following commands to cont...@bugs.debian.org, replacing nn with this
> bug's number:
> 
> severity nn normal
> reassign nn ftp.debian.org
> retitle nn RM:  -- RoM; 
> thanks 
> 
> Alternatively, please keep up with fixing it.
> 
> For more information, see
> http://wiki.debian.org/ftpmaster_Removals
> http://ftp-master.debian.org/removals.txt
> 
> Regards,
> smcv
> 
> 
> 

Bug#660288: Please enable CONFIG_KALLSYMS_ALL

[Tim Abbott]

Package: linux-2.6
Severity: wishlist

(Moving this topic from a debian-kernel thread to the BTS).

Would it be possible to turn on CONFIG_KALLSYMS_ALL in the Debian kernel 
for Wheezy? It's a useful debugging option, and makes it easier to 
implement useful tools like Ksplice that inspect the code and data 
structures of the running kernel, in particular in relation to operating 
on modules (one can use System.map to look up addresses for data 
structures in the core kernel). Most other major Linux distributions 
have had CONFIG_KALLSYMS_ALL enabled in their kernels for some time now 
(RHEL, Fedora, Ubuntu, etc.).


The discussion so far of why this option is useful on the debian-kernel 
thread is at:

<http://lists.debian.org/debian-kernel/2012/01/msg01017.html>.

    -Tim Abbott



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

Bug#573538: [debian-sage] Re: [sage-devel] Re: please schedule a rebuild for sagemath on alpha architecture

[Tim Abbott]

On Sat, 7 Aug 2010, William Stein wrote:

> On Sat, Aug 7, 2010 at 10:49 AM,   wrote:
> > I think there are a couple new dependencies that are not in Debian; there
> > weren't any as of version 4.0 or so.  I would recommend first getting
> > sagemath working building the copies contained in the sagemath tarball,
> > and then package them separately for Debian and switch over later in
> > development (this is how I did the original development, and it was much
> > easier to debug problems incrementally).
> >
> > I suspect that starting by doing the work incrementally with 3.0.6 first
> > might be easier than starting with 4.5 to begin with.  There's a good
> > chance you'll want to switch tacts once you get the hang of it, but I
> > think if you try migrating the current package to 4.5, you'll end up
> > feeling overwhelmed by the problems and give up.  Some partial progress of
> > mine on updating direct to 3.4.1 (shortly before 4.0) is available, in
> > case you find it useful (I don't think I was very far along):
> >
> > http://web.mit.edu/sage/www/sage-3.4.1-debian.tar.gz
> >
> > My experience is that one spends most of your time working on sagemath
> > packaging on (1) debugging and (2) waiting for it to build (it took about
> > 30 minutes to build on the server I was using).  When I tried to update
> 
> Sage 4.5.x will take a lot longer than 30 minutes if you don't build
> in parallel.
> If you build the sagemath package in parallel in can take as little as
> 3 or 4 minutes
> on sage.math.washington.edu

Yeah, unfortunately, the server I was using had only 2 cores.

Also, I should note that the 30 minutes was just the time to build the ~10 
spkgs that weren't being dealt with as packages -- this was with using 
system packages for all the dependencies (I imagine your number is for 
building the whole thing?)

-Tim Abbott

> 
>  -- William
> 
> > direct from 3.0.5 to 3.4.1, I found debugging problems resulting from
> > upstream changes took most of the time.  I bet it would be much easier
> > when you can find the upstream change that caused the problem; since each
> > sagemath version has relatively small changes, that can make life easier,
> > especially if you're still getting used to dealing with the Sage build
> > system.
> >
> > One thing that I should warn you about is that now Debian has
> > substantially newer versions of various packages than Sage 3.0.5 was
> > designed for, and in some cases that will break things.  The current Sage
> > 3.0.5 package was prepared for Lenny, and then tweaked a bit to keep it
> > compiling on newer stuff.  So it's possible that the incremental approach
> > will prove to be painful and you don't want to do it.  But if I were you,
> > I would probably start by just trying to do 3.0.5 -> 3.0.6, just because I
> > think that'll help build confidence and give you a better sense of the
> > nature of the challenge than going straight to 4.5.
> >
> > But it's really up to you.  I don't have the time to help more than just
> > providing background information on how I did it and what problems I
> > encountered.
> >
> >        -Tim Abbott
> >
> >> If the answer is no then the next question is what is the minimal
> >> version that we can package given the current set of packages
> >> available in Debian. There is no clear cut approach. we need to go
> >> back and forth a bit. We may need to file some ITPs and work on some
> >> transitions which is where the team becomes important.
> >>
> >> As for the support requests from users, sooner or later they realize
> >> that if there is a problem they have to go with the later version
> >> anyway. A bit of that frustration is probably good as it will drive
> >> some to come and take part in packaging sage for Debian.
> >
> > --
> > To post to this group, send an email to sage-de...@googlegroups.com
> > To unsubscribe from this group, send an email to 
> > sage-devel+unsubscr...@googlegroups.com
> > For more options, visit this group at 
> > http://groups.google.com/group/sage-devel
> > URL: http://www.sagemath.org
> >
> 
> 
> 
> -- 
> William Stein
> Professor of Mathematics
> University of Washington
> http://wstein.org
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "debian-sage" group.
> To post to this group, send email to debian-s...@googlegroups.com.
> To unsubscribe from this group, send email to 
> debian-sage+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/debian-sage?hl=en.
> 
> 

Bug#573538: Packaging again sagemath

[Tim Abbott]

Hello all,

I'm the maintainer of the sagemath package.  Due to the package taking 8 
months to get through NEW (resulting in it starting out 8 months out of 
date) and my founding a startup around the time it entered NEW, I've never 
had the time to update it across the original 8 months of backlog caused 
by the NEW process.

I would support removing the package from Debian.  An alternative that I 
think would be better is to move it to Debian experimental (so that if I 
find someone to work on incrementally updating it, we can do that without 
having the package go through NEW a second time).


Having done some of the work on updating the current sagemath package to 
sagemath 4+, I'm fairly confident that upstream hasn't changed the 
structure of their build system and the old package will will save a lot 
of time for future work on producing a package compliant with Debian 
policy (e.g. it handles the issues involved in sagemath being distributed 
as a tarball containing a large number of .tar.bz2 files, of which maybe 
10 are original sagemath code and the rest are dependencies, and contains 
all the code you need to make sagemath link against the system libraries).

That said, I don't foresee having the time myself, and have yet to find 
anyone else who is serious about taking up this project.  Upstream is, I 
think rightly, currently more interested in getting setup their own apt 
repository that distributes a working sagemath package that just bundles 
all the dependencies (it's much easier to do, but would not be suitable 
for inclusion in Debian).

        Best regards,
-Tim Abbott

On Thu, 5 Aug 2010, Lucas Nussbaum wrote:

> retitle 573538 RM: sagemath -- RoQA; broken and outdated; RC-buggy
> reassign 573538 ftp.debian.org
> severity 573538 normal
> thanks
> 
> Hi,
> 
> I'm requesting the removal of the sagemath package. It is completely
> outdated in Debian, which makes everybody unhappy (upstream developers,
> users).
> 
> It would still be nice to have this software in Debian, but coordinated
> efforts and discussions with the upstream community to resolve the open
> issues about dependencies on all other pieces of software are required
> first.
> 
> The current Debian packaging can be found on
> http://snapshot.debian.org/package/sagemath/3.0.5dfsg-5.1/, even if I'm
> not too sure that it will be useful as a basis to package sagemath 4+.
> 
> - Lucas
> 
> 
> 



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

Bug#573538: sagemath: moving to team maintainance?

[Tim Abbott]

Hello Rogério,

You are right that I don't have the time to maintain sagemath -- I'd be 
very happy to move to a team maintenance structure.  I've copied several 
folks who have expressed interest in updating the Sage packaging over the 
last few weeks, who may help provide the initial team.

There's a mailing list debian-s...@googlegroups.com that originally 
gathered to discuss packaging Sage in Debian, and probably is reasonable 
to use for this purpose for now.

Given the time I have available at this stage, I imagine that my role will 
primarily be explaining extensive documentation of how the current 
packaging structure works (and publishing some of my current partial work 
somewhere), and the actual work of updating the software will need to be 
done by others.  I'm also happy to help with making uploads happen to the 
packages I currently maintain as needed.

Is anyone interested in organizing the effort?

-Tim Abbott

p.s. when replying to this thread, please try to not drop all the other 
lists from the thread.

On Sat, 8 May 2010, Rogério Brito wrote:

> Hi, Tim.
> 
> I see that you don't seem to have the time to package sagemath and it
> could be in a better state. Would you be willing to have co-maintainers,
> maintain it with a team etc?
> 
> A package this important should not be removed from the distribution
> and, even though I am not a member of the science team, I would love to
> help with some of the issues that happen to appear.
> 
> 
> Thanks, Rogério Brito.
> 
> P.S.: Please, keep me CC'ed, as I am not subscribed to the lists etc.
> -- 
> Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
> http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
> DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
> 
> 
> 

Bug#577261: libsymmetrica: no -doc package and *.doc files not included

[Tim Abbott]

Thanks for the bug report, I'll look into adding these.

    -Tim Abbott

On Sat, 10 Apr 2010, CJ Fearnley wrote:

> Package: libsymmetrica-2.0
> Version: 2.0-1
> Severity: normal
> File: libsymmetrica
> 
> 
> The upstream includes a number of .doc documentation files.  These are
> neither included in a -doc package nor are the included in the library.
> When I downloaded the upstream source, I found the following documentation
> files:
> 
> bar.doc debug.doc intro.doc matrix.doc nc.doc poly.doc sb.doc ta.doc
> bi.doc ff.doc io.doc moddg.doc nu.doc pr.doc sc.doc tfiles.doc boe.doc
> ga.doc kostka.doc monom.doc object.doc rest.doc schur.doc vector.doc
> bruch.doc hiccup.doc list.doc na.doc part.doc rh.doc skew.doc word.doc
> classical.doc integer.doc lo.doc nb.doc perm.doc sab.doc t147.doc zyk.doc
> 
> The package would be much more useful if its documentation were included.
> 
> -- System Information:
> Debian Release: 5.0.4
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores)
> Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
> Shell: /bin/sh linked to /bin/bash
> 
> Versions of packages libsymmetrica-2.0 depends on:
> ii  libc6   2.7-18lenny2 GNU C Library: Shared libraries
> 
> libsymmetrica-2.0 recommends no packages.
> 
> libsymmetrica-2.0 suggests no packages.
> 
> -- 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#577480: [sagemath] Please update! Version 4.3.5 released by now.

[Tim Abbott]

Hello,

I would love to release packing for a current version of sagemath, but it 
is a huge project that I don't expect to be able to do in the near future.

    -Tim Abbott

On Mon, 12 Apr 2010, burgs...@gmx.de wrote:

> Package: sagemath
> Severity: important
> 
> --- Please enter the report below this line. ---
> 
> Many new features and bugfixes are incorporated by the new releases, Cantor 
> has a Sage backend and this package starts to get incompatible with the rest 
> of the distribution.
> There are 25 upstream releases since the version packaged in Debian, it would 
> be great to see an update.
> 
> --- System information. ---
> Architecture: amd64
> Kernel:   Linux 2.6.33.2
> 
> Debian Release: squeeze/sid
>   991 testing ftp.uni-kl.de 
>   990 testing security.debian.org 
>   990 testing ftp.de.debian.org 
>50 unstableftp.uni-kl.de 
>50 unstableftp.de.debian.org 
>50 stable  volatile.debian.org 
>50 stable  security.debian.org 
>50 stable  ftp.uni-kl.de 
>50 stable  ftp.de.debian.org 
>50 experimentalftp.uni-kl.de 
>50 experimentalftp.de.debian.org 
> 
> --- Package information. ---
> Depends   (Version) | Installed
> ===-+-===
> libatlas3gf-base| 
>  OR libatlas.so.3gf | 
> libc6  (>= 2.3) | 2.10.2-6
> libecm0 | 
> libflint-1.011  | 
> libfplll0   | 
> libgcc1(>= 1:4.1.1) | 1:4.4.2-9
> libgivaro0  | 
> libgmp3c2   | 2:4.3.2+dfsg-1
> libgmpxx4ldbl   | 2:4.3.2+dfsg-1
> libgsl0ldbl(>= 1.9) | 1.14+dfsg-1
> libiml0  (>= 1.0.3) | 
> liblinbox0  | 
> libm4ri-0.0.20080521| 
> libmpfi0| 
> libmpfr1ldbl| 2.4.2-3
> libntl-5.4.2| 
> libpari2-gmp   (>= 2.3.4-1) | 
> libpolybori-0.5.0-0 | 
> libqd2c2a   | 
> libreadline5   (>= 5.2) | 5.2-7
> libsingular-3-0-4-3 | 
> libstdc++6   (>= 4.2.1) | 4.4.2-9
> libsymmetrica-2.0   | 
> libzn-poly-0.8  | 
> python (<< 2.6) | 2.5.4-9
> python (>= 2.5) | 2.5.4-9
> python-central  (>= 0.6.11) | 0.6.14+nmu2
> python2.5   | 2.5.5-2
> gap | 
> singular| 
> maxima-share| 
> genus2reduction | 
> lcalc   | 
> sympow  | 
> python-matplotlib   | 
> gfan| 
> python-gd   | 
> mercurial   | 
> python-twisted  | 
> python-numpy| 1:1.3.0-3+b1
> python-crypto   | 
> python-moinmoin | 
> sqlite3 | 
> palp| 
> ipython | 
> python-gnutls   | 
> python-scipy| 
> python-cvxopt   | 
> scons   | 
> r-base  | 
> gfortran| 
> python-sqlalchemy   | 
> gmp-ecm | 
> python-sympy| 
> python-networkx | 
> python-pexpect  | 
> cython  | 
> python-twisted-web2 | 
> pari-gp | 
> pari-extra  | 
> tachyon | 
> python-rpy  | 
> gap-guava   | 
> python-processing   | 
> python-polybori | 
> libcdd-test | 
> libjs-jquery| 1.4.2-2
> libsingular-dev | 
> time| 1.7-23
>

Bug#573538: Please remove the sagemath package

[Tim Abbott]

Hi Florent,

I was planning to discuss this with upstream during the weekend when I 
have some time to think about Sage, but I should give some quick thoughts 
here.

Is the issue upstream is having actually that people are installing the 
sagemath package on Debian unstable systems and being confused?

My guess is that your actual problem is that the sagemath package made it 
into Ubuntu Karmic (despite it having release-critical bugs designed to 
prevent it from making it into any Debian release) and lots of people are 
having a bad experience there.  I'd be happy to help with trying to get it 
removed from Ubuntu Karmic -- I ask what's involved in doing that.

    -Tim Abbott

On Thu, 11 Mar 2010, Florent Hivert wrote:

> Package: sagemath
> Version: 3.0.5dfsg-5.1
> Severity: Grave
> 
> Hi, the sagemath deb package is very outdated and we get reports on a regular
> base that it is not working. We do not have the manpower to release a new
> package, but it is very easy to install a prebuilt binary. Still, many install
> it via the repository and think that it is crap. We do not know who removes
> packages from the Debian repository, but it would be very good if it would
> happen. Here is one of our recent discussions about that:
> 
> http://groups.google.com/group/sage-devel/browse_thread/thread/29ee9e1d4efdeda2/
> 
> Cheers,
> 
> Florent Hivert
> 
> 
> 



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

Bug#535357: I sent this upstream

[Tim Abbott]

Updating sage all the way to 4.3.4 is a huge project, so I'll probably 
just backport the patches for now.

    -Tim Abbott

On Thu, 4 Mar 2010, Sandro Tosi wrote:

> On Mon, Oct 19, 2009 at 00:49, Tim Abbott  wrote:
> > After some investigation, I sent this issue to upstream; since they've
> > already converted to Python 2.6 only, this should be an easy transition
> > for them to do.
> 
> Finally upstream fixed it, as reported in
> http://trac.sagemath.org/sage_trac/ticket/6503 .
> 
> The fix is targetted for 4.3.4, and I don't know for what date is
> scheduled to be released. You may want to contact upstream asking for
> a release "asap" in order to update sage for squeeze (currently is
> un-installable and doesn't work) or backport the patches.
> 
> Regards,
> -- 
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
> 
> 
> 



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

Bug#567997: tachyon: New upstream version 0.98.9 available

[Tim Abbott]

Thanks for the notice.

Are you working on packaging VMD for Debian?

-Tim Abbott

On Mon, 1 Feb 2010, Adrian Glaubitz wrote:

> Package: tachyon
> Version: 0.98~beta.dfsg-1
> Severity: normal
> 
> Hi,
> 
> there is a new upstream version of tachyon, 0.98.9, available. It should be 
> packaged because
> there are some other software projects which depend on a more recent version 
> of tachyon, for
> example VMD:
> 
> <http://www.ks.uiuc.edu/Research/vmd/>
> 
> The current version of tachyon can be found here:
> 
> <http://jedi.ks.uiuc.edu/~johns/raytracer/>
> 
> 
> Thanks,
> 
> Adrian
> 
> 
> -- System Information:
> Debian Release: squeeze/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages tachyon depends on:
> ii  libc6   2.10.2-5 Embedded GNU C Library: Shared 
> lib
> ii  libpng12-0  1.2.42-1 PNG library - runtime
> ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime
> 
> tachyon recommends no packages.
> 
> tachyon suggests no packages.
> 
> -- 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#567299: [tex-live] Bug#567299: can you remove a package from TeXLive?

[Tim Abbott]

On Thu, 28 Jan 2010, George N. White III wrote:

> 2010/1/28 Rogério Brito :
> > Package: sagemath
> > Severity: normal
> > X-Debbugs-CC: tex-l...@tug.org, Dan Drake 
> >
> > Hi, there.
> >
> > Sorry to be late on this.
> >
> > On 01/25/2010 09:52 PM, Robin Fairbairns wrote:
> >>
> >> Dan Drake  wrote:
> >>>
> >>> The version of Sage in Debian/Ubuntu is hopelessly outdated and right
> >>> now no one is working on getting new packages prepared. SageTeX will be
> >>> included in the next Sage released, and we can switch links and so on to
> >>> the Sage documentation.
> >>
> >> i.e., there's a .deb containing an outdated sage system?  or there's
> >> no-one working to update sagetex to current ctan standards?  (we know
> >> that's false.)
> >
> > I can't speak about sagetex, but sage in Debian is uninstallable in Debian's
> > sid distribution. I'm CC'ing the maintainer, via a new bug filed with
> > bugs.debian.org.
> >
> > I tried to install sagemath on my computer, since I needed to do some
> > lenghty calculations. :-(
> >
> > To be fair, it seems that the package needs some work upstream:
> >
> > http://bugs.debian.org/535357
> >
> > I don't know if the newer sources fix the problem there, but it would be
> > really nice to have this fixed before the new releases of Debian/Ubuntu.
> 
> I have sagemath installed from packages under Ubuntu-9.10 and the basics
> are working.  The build system seems to be reliable on mainstream
> platforms, but I'm starting to encounter python packages that won't run on
> 32-bit hardware, so I guess mainstream now means "core 2 duo".  Now
> that sagetex is removed from TL, I have been installing sagetex using the
> commandline.  This works, but puts everything in one directory:
> 
> $ sudo sage -i sagetex-2.2.1
> [...]
> creating /usr/share/texmf/tex/generic
> creating /usr/share/texmf/tex/generic/sagetex
> copying example.pdf -> /usr/share/texmf/tex/generic/sagetex
> copying example.tex -> /usr/share/texmf/tex/generic/sagetex
> copying extractsagecode.py -> /usr/share/texmf/tex/generic/sagetex
> copying makestatic.py -> /usr/share/texmf/tex/generic/sagetex
> copying scripts.dtx -> /usr/share/texmf/tex/generic/sagetex
> copying remote-sagetex.dtx -> /usr/share/texmf/tex/generic/sagetex
> copying remote-sagetex.py -> /usr/share/texmf/tex/generic/sagetex
> copying py-and-sty.dtx -> /usr/share/texmf/tex/generic/sagetex
> copying sagetexpackage.dtx -> /usr/share/texmf/tex/generic/sagetex
> copying sagetexpackage.ins -> /usr/share/texmf/tex/generic/sagetex
> copying sagetexpackage.pdf -> /usr/share/texmf/tex/generic/sagetex
> copying sagetexparse.py -> /usr/share/texmf/tex/generic/sagetex
> copying sagetex.sty -> /usr/share/texmf/tex/generic/sagetex
> 
> It would be better if the docs ended up under /usr/share/texmf/doc (or
> wherever debian thinks the doc subtree belongs.   I would like
> "texdoc sagetex" to work for users.
> 
> I also have sagemath installed from sources on other machines -- I
> prefer this as everything is contained in one top-level directory rather
> than getting spread around.  There are so many irregularly maintained
> scientific Python packages these days, each insisting on different
> versions of scipy, etc. that a distro package manager can't cope.

Well, the challenges of keeping sagemath up to date actually have little 
to do with scipy; that package in particular hasn't been a problem for me.  
Instead it has been dealing with a few Python packages lagging in Python 
2.6 support and making sure we have a new enough version of all the 
necessary libraries.

-Tim Abbott

Bug#557293: polybori: diff for NMU version 0.5~rc1-2.1

[Tim Abbott]

Jakub,

Your patch looks good, so I'll let the NMU go through.

Thanks for the preparing an NMU; I've been too busy the last few weeks.

    -Tim Abbott

On Sun, 10 Jan 2010, Jakub Wilk wrote:

> tags 557293 + pending
> thanks
> 
> Dear maintainer,
> 
> I've prepared an NMU for polybori (versioned as 0.5~rc1-2.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if
> I should delay it longer.
> 
> -- 
> Jakub Wilk
> 



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

Bug#559790: Fix uploaded

[Tim Abbott]

Your change looks correct, so I'll probably just let the NMU go through as 
the next few days are quite busy for me.

Thanks,

    -Tim Abbott

On Mon, 7 Dec 2009, Steve M. Robbins wrote:

> Hi,
> 
> Yesterday, I uploaded NMUs to delayed/5 queue for sagemath and
> python-visual.  The change is to build with unversioned
> Boost -dev libraries.
> 
> -Steve
> 



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

Bug#530182: I've sent this upstream

[Tim Abbott]

tags 530182 +upstream
thanks

The spkg/install part of this has been fixed upstream, the dokchitser part 
I've reported upstream.  This issue is not particularly important for 
Debian because neither of these scripts are actually run as part of Sage's 
normal runtime.

<http://trac.sagemath.org/sage_trac/ticket/7243>

So I expect this will get fixed when sagemath is upgraded to a non-ancient 
version, which should with any luck be before squeeze freezes.

    -Tim Abbott



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

Bug#535357: I sent this upstream

[Tim Abbott]

tags 535357 +upstream
thanks

After some investigation, I sent this issue to upstream; since they've 
already converted to Python 2.6 only, this should be an easy transition 
for them to do.

    -Tim Abbott



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

Bug#545608: Bug #545608: intent to NMU polybori

[Tim Abbott]

On Thu, 17 Sep 2009, Luca Falavigna wrote:

> Hi Tim,
> 
> your package is FTBFSing due to changes in boost1.39, as described here:
> http://svn.debian.org/viewsvn/pkg-boost/boost/trunk/debian/NEWS.Debian?r1=14443&r2=14478
> 
> Fix consists in removing 01-fix-ftbfs-with-new-boost.diff.
> 
> I plan to prepare a NMU in the next few days and upload to the DELAYED
> queue as per devref §5.11.1, please inform me if you want me to wait.

Hi Luca,

I have no problem with your NMUing that change (I agree that all that is 
needed is to remove the patch from last time).  That said, I was probably 
going to get around to doing such an upload on Saturday, so if you have a 
lot of these to take care of, I'd be happy to deal with this one.

    Best regards,
-Tim Abbott

Bug#545588: linbox: FTBFS: configure.in:19: error: possibly undefined macro: AM_ACLOCAL_INCLUDE

[Tim Abbott]

This issue is quite similar to the iml issue (#545598); I should have a 
fix uploaded soon.

Regards,
-Tim Abbott

On Tue, 8 Sep 2009, Lucas Nussbaum wrote:

> Package: linbox
> Version: 1.1.6~rc0-3
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20090907 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part:
> > libtoolize: putting auxiliary files in `.'.
> > libtoolize: copying file `./ltmain.sh'
> > libtoolize: You should add the contents of the following files to 
> > `aclocal.m4':
> > libtoolize:   `/usr/share/aclocal/libtool.m4'
> > libtoolize:   `/usr/share/aclocal/ltoptions.m4'
> > libtoolize:   `/usr/share/aclocal/ltversion.m4'
> > libtoolize:   `/usr/share/aclocal/ltsugar.m4'
> > libtoolize:   `/usr/share/aclocal/lt~obsolete.m4'
> > libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
> > libtoolize: rerunning libtoolize, to keep the correct libtool macros 
> > in-tree.
> > libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
> > cd . && aclocal-1.10 
> > configure.in:19: warning: macro `AM_ACLOCAL_INCLUDE' not found in library
> > if [ -e ./configure.ac ] || [ -e ./configure.in ]; then cd . && `which 
> > autoconf2.50 || which autoconf`; fi
> > configure.in:19: error: possibly undefined macro: AM_ACLOCAL_INCLUDE
> >   If this token and others are legitimate, please use m4_pattern_allow.
> >   See the Autoconf documentation.
> > make: *** [debian/stamp-autotools-files] Error 1
> 
> The full build log is available from:
>
> http://people.debian.org/~lucas/logs/2009/09/07/linbox_1.1.6~rc0-3_lsid64.buildlog
> 
> A list of current common problems and possible solutions is available at 
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> About the archive rebuild: The rebuild was done on about 50 AMD64 nodes
> of the Grid'5000 platform, using a clean chroot.  Internet was not
> accessible from the build systems.
> 
> -- 
> | Lucas Nussbaum
> | lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
> | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |
> 
> 
> 



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

Bug#545598: iml: FTBFS: configure.ac:50: error: possibly undefined macro: AC_MSG_ERROR

[Tim Abbott]

Thanks for the report.  It looks like CDBS's API for handling autotools 
was improved since the package was last built -- I have a fixed package 
and expect it to be uploaded soon.

Regards,
    -Tim Abbott

On Tue, 8 Sep 2009, Lucas Nussbaum wrote:

> Package: iml
> Version: 1.0.3-3
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20090907 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part:
> > libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `config'.
> > libtoolize: copying file `config/ltmain.sh'
> > libtoolize: You should add the contents of the following files to 
> > `aclocal.m4':
> > libtoolize:   `/usr/share/aclocal/libtool.m4'
> > libtoolize:   `/usr/share/aclocal/ltoptions.m4'
> > libtoolize:   `/usr/share/aclocal/ltversion.m4'
> > libtoolize:   `/usr/share/aclocal/ltsugar.m4'
> > libtoolize:   `/usr/share/aclocal/lt~obsolete.m4'
> > libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
> > libtoolize: rerunning libtoolize, to keep the correct libtool macros 
> > in-tree.
> > libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
> > cd . && aclocal-1.10 
> > if [ -e ./configure.ac ] || [ -e ./configure.in ]; then cd . && `which 
> > autoconf2.50 || which autoconf`; fi
> > configure.ac:50: error: possibly undefined macro: AC_MSG_ERROR
> >   If this token and others are legitimate, please use m4_pattern_allow.
> >   See the Autoconf documentation.
> > make: *** [debian/stamp-autotools-files] Error 1
> 
> The full build log is available from:
>http://people.debian.org/~lucas/logs/2009/09/07/iml_1.0.3-3_lsid64.buildlog
> 
> A list of current common problems and possible solutions is available at 
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> About the archive rebuild: The rebuild was done on about 50 AMD64 nodes
> of the Grid'5000 platform, using a clean chroot.  Internet was not
> accessible from the build systems.
> 
> -- 
> | Lucas Nussbaum
> | lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
> | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |
> 
> 
> 



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

Bug#544809: autoconf: bad interaction between AC_CHECK_LIB and AC_SEARCH_LIBS

[Tim Abbott]

package: autoconf
version: 2.64-2
severity: normal

The new autoconf in squeeze generates configure scripts that error out 
with:

checking for socket... ./configure: line 1399: ac_fn_c_try_link: command not 
found

when you write code of the form:

AC_CHECK_FUNC([socket], :, AC_CHECK_LIB([socket], [socket]))

followed eventually by

AC_SEARCH_LIBS([socket], [socket])

I've attached a sample configure.in script that reproduces the problem; a 
corresponding tarball is available at 
.

-Tim AbbottAC_INIT

AC_PROG_CC
AC_PROG_INSTALL
AC_PROG_RANLIB

AC_CHECK_FUNC([socket], :, AC_CHECK_LIB([socket], [socket]))
AC_SEARCH_LIBS([socket], [socket])

AC_CONFIG_FILES([Makefile])
AC_OUTPUT

Bug#543153: sagemath: has many useless dependencies

[Tim Abbott]

On Sat, 22 Aug 2009, Raphael Geissert wrote:

> Package: sagemath
> Version: 3.0.5dfsg-4
> 
> Hi,
> 
> The binary package depends on many packages that I can't even imagine it 
> actually needs them. Examples: mercurial, scons, gfortran?
> 
> I remember seeing it pull in many many more packages when I tried it some 
> months ago, but I don't see them anymore.

I think it previously erroneously recommended r-recommended rather than 
r-base.

Sage's architecture is built around taking tying together a lot of 
different C libraries; the Sage source distribution ships with the source 
of some 75 or so other packages so that it is possible to install it from 
source.  So you should expect it to have a vast number of dependencies, 
most of which are integrated so that they cannot be removed.

That said, the dependency list is something I've been meaning to clean up.  

More of those packages are needed for some Sage functionality than you 
might think (putting them in Suggests: might be fine if it is the case 
that the problem is clear to the user what they need when an error occurs; 
I'd need to check this).  But given how huge the package's dependency list 
must be anyway, it's not clear there's a lot of gain to be had here.

For example, Sage lets you write inline fortran in your scripts, so 
removing e.g. gfortan will cause its internal test suite to fail, as well 
as removing that functionality.  And scons is required if you want to 
download any of Sage's optional packages (it has a native interface for 
installing certain parts of Sage that are not yet popular or good enough 
to be in mainline).

-Tim Abbott



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

Bug#476328: Here's a patch to split the package

[Tim Abbott]

I've attached a new version of the patch that splits into 
kerneloops-daemon and kerneloops-applet and adds a transitional 
empty 'kerneloops' package.

It probably needs some more testing than I've had time for (in particular, 
the upgrade path).

-Tim Abbott

On Thu, 13 Aug 2009, Tim Abbott wrote:

> On Fri, 7 Aug 2009, Matthew Wilcox wrote:
> 
> > On Fri, Aug 07, 2009 at 04:03:32PM -0400, Tim Abbott wrote:
> > > Hmm.  I think long-term it would be best to have the names be 
> > > kerneloops/kerneloops-applet.  kerneloops-daemon/kerneloops is certainly 
> > > much better than kerneloops-nogui/kerneloops, but I think is still a bit 
> > > confusing.  It may very well be justified by saving the current userbase 
> > > from having things change out from under them.
> > 
> > We can set that as our goal and transition to it.  So we should split
> > the package into kerneloops-applet and kerneloops-daemon.  Then create
> > a new kerneloops dummy package which depends on kerneloops-applet.
> > 
> > In a couple of years, we can rename kerneloops-daemon to kerneloops,
> > and everybody should be happy.
> > 
> > Computer Science Motto: All problems can be solved with an extra layer
> > of abstraction ;-)
> 
> Yeah, that's probably the right thing to do.
> 
> I'll post a new version of the patch that makes kerneloops a transitional 
> package as you describe when I get a chance (probably in a week or two).
> 
>   -Tim Abbott
> 
> 
> 
> 
> 
> -- 
> To unsubscribe, send mail to 476328-unsubscr...@bugs.debian.org.
> From ca3777a7a16310d2a7dae9040c428485b232d0c1 Mon Sep 17 00:00:00 2001
From: Tim Abbott 
Date: Thu, 23 Jul 2009 11:10:05 -0400
Subject: [PATCH] Split the kerneloops package into kerneloops-daemon and kerneloops-applet.

Also add a transitional kerneloops package that depends on
kerneloops-applet.

Signed-off-by: Tim Abbott 
---
 debian/control|   19 +++
 debian/kerneloops-applet.install  |3 ++
 debian/kerneloops-daemon.install  |2 +
 debian/kerneloops-daemon.postinst |   46 +
 debian/kerneloops-daemon.postrm   |   41 +
 debian/postinst   |   46 -
 debian/postrm |   41 -
 debian/rules  |8 --
 8 files changed, 116 insertions(+), 90 deletions(-)
 create mode 100644 debian/kerneloops-applet.install
 create mode 100644 debian/kerneloops-daemon.install
 create mode 100644 debian/kerneloops-daemon.postinst
 create mode 100644 debian/kerneloops-daemon.postrm
 delete mode 100644 debian/postinst
 delete mode 100644 debian/postrm
 mode change 100644 => 100755 debian/rules

diff --git a/debian/control b/debian/control
index 0e93c6a..9b33d40 100644
--- a/debian/control
+++ b/debian/control
@@ -9,8 +9,27 @@ Homepage: http://www.kerneloops.org/
 
 Package: kerneloops
 Architecture: any
+Depends: kerneloops-applet
+Description: kernel oops tracker
+ This is a transitional package for splitting the kerneloops package
+ into the kerneloops-daemon package and the kerneloops-applet package.
+ In the future, the kerneloops package will contain only the
+ kerneloops daemon, and not the applet.  If you want the kerneloops
+ applet, you should explicitly install the kerneloops-applet package.
+
+Package: kerneloops-daemon
+Architecture: any
 Depends: ${shlibs:Depends}, adduser
+Conflicts: kerneloops (<< 0.12+git20090217-2)
 Description: kernel oops tracker
  kerneloops is a daemon that collects kernel crash information and then
  submits the extracted signature to the kerneloops.org website for
  statistical analysis and presentation to the Linux kernel developers.
+
+Package: kerneloops-applet
+Architecture: any
+Depends: ${shlibs:Depends}, kerneloops-daemon
+Description: applet for the kernel oops tracker
+ The kerneloops applet allows the kerneloops crash reporting utility
+ to ask a desktop user for permission before submitting an oops report
+ to the kerneloops.org website.
diff --git a/debian/kerneloops-applet.install b/debian/kerneloops-applet.install
new file mode 100644
index 000..3850712
--- /dev/null
+++ b/debian/kerneloops-applet.install
@@ -0,0 +1,3 @@
+debian/tmp/usr/bin/kerneloops-applet /usr/bin
+debian/tmp/usr/share/kerneloops /usr/share
+debian/tmp/usr/share/locale /usr/share
diff --git a/debian/kerneloops-daemon.install b/debian/kerneloops-daemon.install
new file mode 100644
index 000..cb7f717
--- /dev/null
+++ b/debian/kerneloops-daemon.install
@@ -0,0 +1,2 @@
+debian/tmp/usr/sbin/kerneloops /usr/sbin/
+debian/tmp/usr/share/man/man8/* /usr/share/man/man8/
diff --git a/debian/kerneloops-daemon.postinst b/debian/kerneloops-daemon.postinst
new file mode 10064

Bug#476328: Here's a patch to split the package

[Tim Abbott]

On Fri, 7 Aug 2009, Matthew Wilcox wrote:

> On Fri, Aug 07, 2009 at 04:03:32PM -0400, Tim Abbott wrote:
> > Hmm.  I think long-term it would be best to have the names be 
> > kerneloops/kerneloops-applet.  kerneloops-daemon/kerneloops is certainly 
> > much better than kerneloops-nogui/kerneloops, but I think is still a bit 
> > confusing.  It may very well be justified by saving the current userbase 
> > from having things change out from under them.
> 
> We can set that as our goal and transition to it.  So we should split
> the package into kerneloops-applet and kerneloops-daemon.  Then create
> a new kerneloops dummy package which depends on kerneloops-applet.
> 
> In a couple of years, we can rename kerneloops-daemon to kerneloops,
> and everybody should be happy.
> 
> Computer Science Motto: All problems can be solved with an extra layer
> of abstraction ;-)

Yeah, that's probably the right thing to do.

I'll post a new version of the patch that makes kerneloops a transitional 
package as you describe when I get a chance (probably in a week or two).

-Tim Abbott





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

Bug#526585: This bug is fixed in version 3.2.13-1

[Tim Abbott]

Version 3.2.13 of Givaro contains a libtool update that fixed this build 
failure (I forgot to include the bug closer in the changelog itself).

-Tim Abbott



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

Bug#540684: kerneloops: Init script errors when removed but not purged

[Tim Abbott]

package: kerneloops
severity: normal

When you remove but don't purge kerneloops, the kerneloops init script 
will continue to be run (as update-rc.d is only run in the purge target).  
However, the kerneloops init script doesn't check whether the kerneloops 
program is installed before trying to start the daemon, which causes it to 
print errors to the console during the boot process.

The standard fix to this problem is to add a

[ -x "$exec" ] || exit 0

near the top of the init script.

-Tim Abbott



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

Bug#476328: Here's a patch to split the package

[Tim Abbott]

On Fri, 7 Aug 2009, Matthew Wilcox wrote:

> On Fri, Aug 07, 2009 at 01:48:34PM -0400, Tim Abbott wrote:
> > tag 476328 +patch
> > thanks
> > 
> > I've attached a patch to split the package into a kerneloops package and a 
> > kerneloops-applet package.  The new kerneloops package has just the 
> > daemon, and works as though "allow-submit = ask" were set to "no".  There 
> > may be some migration cost of people who upgrade and lose the GUI, but I 
> > think that this is a substantially better design than having two packages 
> > that both contain indentical copies of the kerneloops daemon, init script, 
> > etc.
> > 
> > Later, we can try to implement an "allow-submit = ask" system for when one 
> > doesn't have a GUI using one of the schemes from this bug report.
> 
> How about we do this the opposite way round, where we have
> a kerneloops-daemon package, and the kerneloops package depends
> on it?  That way, people who upgrade from current kerneloops lose no
> functionality, and new installs who want to get rid of the applet can
> just install kerneloops-daemon?

Hmm.  I think long-term it would be best to have the names be 
kerneloops/kerneloops-applet.  kerneloops-daemon/kerneloops is certainly 
much better than kerneloops-nogui/kerneloops, but I think is still a bit 
confusing.  It may very well be justified by saving the current userbase 
from having things change out from under them.

Of course, the number of users with kerneloops installed in the future 
will be much greater than those at present, since it seems Ubuntu is 
planning to put kerneloops in the default installation for Karmic:

<https://bugs.launchpad.net/ubuntu/+source/kerneloops/+bug/327819>

-Tim Abbott

> 
> > (I also submitted this patch to this Ubuntu bug: 
> > <https://bugs.launchpad.net/ubuntu/+source/kerneloops/+bug/337757>)
> > 
> > -Tim Abbott
> > From 439668b7c0b40ac60455b2cf1989ca29051de8e5 Mon Sep 17 00:00:00 2001
> > From: Tim Abbott 
> > Date: Thu, 23 Jul 2009 11:10:05 -0400
> > Subject: [PATCH] Split the kerneloops package into kerneloops and 
> > kerneloops-applet.
> > 
> > Signed-off-by: Tim Abbott 
> > ---
> >  debian/control   |8 
> >  debian/kerneloops-applet.install |3 +++
> >  debian/kerneloops.install|2 ++
> >  debian/rules |6 --
> >  4 files changed, 17 insertions(+), 2 deletions(-)
> >  create mode 100644 debian/kerneloops-applet.install
> >  create mode 100644 debian/kerneloops.install
> >  mode change 100644 => 100755 debian/rules
> > 
> > diff --git a/debian/control b/debian/control
> > index 0e93c6a..3de12ca 100644
> > --- a/debian/control
> > +++ b/debian/control
> > @@ -14,3 +14,11 @@ Description: kernel oops tracker
> >   kerneloops is a daemon that collects kernel crash information and then
> >   submits the extracted signature to the kerneloops.org website for
> >   statistical analysis and presentation to the Linux kernel developers.
> > +
> > +Package: kerneloops-applet
> > +Architecture: any
> > +Depends: ${shlibs:Depends}, kerneloops
> > +Description: applet for the kernel oops tracker
> > + The kerneloops applet allows the kerneloops crash reporting utility
> > + to ask a desktop user for permission before submitting an oops report
> > + to the kerneloops.org website.
> > diff --git a/debian/kerneloops-applet.install 
> > b/debian/kerneloops-applet.install
> > new file mode 100644
> > index 000..3850712
> > --- /dev/null
> > +++ b/debian/kerneloops-applet.install
> > @@ -0,0 +1,3 @@
> > +debian/tmp/usr/bin/kerneloops-applet /usr/bin
> > +debian/tmp/usr/share/kerneloops /usr/share
> > +debian/tmp/usr/share/locale /usr/share
> > diff --git a/debian/kerneloops.install b/debian/kerneloops.install
> > new file mode 100644
> > index 000..cb7f717
> > --- /dev/null
> > +++ b/debian/kerneloops.install
> > @@ -0,0 +1,2 @@
> > +debian/tmp/usr/sbin/kerneloops /usr/sbin/
> > +debian/tmp/usr/share/man/man8/* /usr/share/man/man8/
> > diff --git a/debian/rules b/debian/rules
> > old mode 100644
> > new mode 100755
> > index dfe7ee3..ebf8678
> > --- a/debian/rules
> > +++ b/debian/rules
> > @@ -27,8 +27,10 @@ install: build
> > dh_installdirs
> >  
> > # Add here commands to install the package into debian/
> > -   $(MAKE) DESTDIR=`pwd`/debian/`dh_listpackages` install
> > +   $(MAKE) DESTDIR=`pwd`/debian/tmp install
> > install -D 

Bug#476328: Here's a patch to split the package

[Tim Abbott]

tag 476328 +patch
thanks

I've attached a patch to split the package into a kerneloops package and a 
kerneloops-applet package.  The new kerneloops package has just the 
daemon, and works as though "allow-submit = ask" were set to "no".  There 
may be some migration cost of people who upgrade and lose the GUI, but I 
think that this is a substantially better design than having two packages 
that both contain indentical copies of the kerneloops daemon, init script, 
etc.

Later, we can try to implement an "allow-submit = ask" system for when one 
doesn't have a GUI using one of the schemes from this bug report.

(I also submitted this patch to this Ubuntu bug: 
<https://bugs.launchpad.net/ubuntu/+source/kerneloops/+bug/337757>)

-Tim AbbottFrom 439668b7c0b40ac60455b2cf1989ca29051de8e5 Mon Sep 17 00:00:00 2001
From: Tim Abbott 
Date: Thu, 23 Jul 2009 11:10:05 -0400
Subject: [PATCH] Split the kerneloops package into kerneloops and kerneloops-applet.

Signed-off-by: Tim Abbott 
---
 debian/control   |8 
 debian/kerneloops-applet.install |3 +++
 debian/kerneloops.install|2 ++
 debian/rules |6 --
 4 files changed, 17 insertions(+), 2 deletions(-)
 create mode 100644 debian/kerneloops-applet.install
 create mode 100644 debian/kerneloops.install
 mode change 100644 => 100755 debian/rules

diff --git a/debian/control b/debian/control
index 0e93c6a..3de12ca 100644
--- a/debian/control
+++ b/debian/control
@@ -14,3 +14,11 @@ Description: kernel oops tracker
  kerneloops is a daemon that collects kernel crash information and then
  submits the extracted signature to the kerneloops.org website for
  statistical analysis and presentation to the Linux kernel developers.
+
+Package: kerneloops-applet
+Architecture: any
+Depends: ${shlibs:Depends}, kerneloops
+Description: applet for the kernel oops tracker
+ The kerneloops applet allows the kerneloops crash reporting utility
+ to ask a desktop user for permission before submitting an oops report
+ to the kerneloops.org website.
diff --git a/debian/kerneloops-applet.install b/debian/kerneloops-applet.install
new file mode 100644
index 000..3850712
--- /dev/null
+++ b/debian/kerneloops-applet.install
@@ -0,0 +1,3 @@
+debian/tmp/usr/bin/kerneloops-applet /usr/bin
+debian/tmp/usr/share/kerneloops /usr/share
+debian/tmp/usr/share/locale /usr/share
diff --git a/debian/kerneloops.install b/debian/kerneloops.install
new file mode 100644
index 000..cb7f717
--- /dev/null
+++ b/debian/kerneloops.install
@@ -0,0 +1,2 @@
+debian/tmp/usr/sbin/kerneloops /usr/sbin/
+debian/tmp/usr/share/man/man8/* /usr/share/man/man8/
diff --git a/debian/rules b/debian/rules
old mode 100644
new mode 100755
index dfe7ee3..ebf8678
--- a/debian/rules
+++ b/debian/rules
@@ -27,8 +27,10 @@ install: build
 	dh_installdirs
 
 	# Add here commands to install the package into debian/
-	$(MAKE) DESTDIR=`pwd`/debian/`dh_listpackages` install
+	$(MAKE) DESTDIR=`pwd`/debian/tmp install
 	install -D -m 0755 kerneloops.init `pwd`/debian/kerneloops/etc/init.d/kerneloops
+	dh_install -pkerneloops
+	dh_install -pkerneloops-applet
 
 # Build architecture-independent files here.
 binary-indep: build install
@@ -41,7 +43,7 @@ binary-arch: build install
 	dh_installchangelogs
 	dh_installdocs
 	dh_installexamples
-	dh_installinit -o
+	dh_installinit -pkerneloops -o
 #	dh_installdebconf	
 #	dh_installman kerneloops.8
 	dh_link
-- 
1.6.3.3

Bug#537376: python-support: Cannot use modules provided by a package in its postinst script

[Tim Abbott]

package: python-support
version: 1.0.3

Consider a package foo that provides both a python module (say, foo.bar) 
and a python program baz that imports foo.bar.  With the current 
python-support implementation, it is not possible to run baz in the 
package's postinst script.  What will happen is that the "import foo.bar" 
line of baz will fail in the postinst script with

ImportError: No module named foo

because /usr/lib/pymodules/python2.5/foo/__init__.py doesn't exist yet. 
(It is created by the python-support trigger that runs after installation 
completes.)

It seems like one could fix this by having python-support create its empty 
__init__.py file when update-python-modules is run, rather than delaying 
until the trigger is processed.

It is quite possible that this problem will also affect situations where 
the package running bar in its postinst script depends on the package 
containing foo.bar and the packages are installed at the same time, but 
I've not tested it.

For now, I've worked around this problem by using python-central.

-Tim Abbott



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

Bug#530478: Needs to link against -lboost_python-mt

[Tim Abbott]

On Thu, 2 Jul 2009, Cyril Brulebois wrote:

> tag 530478 patch pending
> thanks
> 
> Steve M. Robbins  (24/05/2009):
> > Due to the recently-introduced package boost-defaults [1], the
> > unversioned Boost -dev packages changed from Boost version 1.34.1 to
> > version 1.38.0.
> > 
> > You package now fails to build due to that change.  Specifically, you
> > will need to link against "-mt" variants of the boost libraries.
> > 
> > Upstream stopped building separate single- and multi-threaded variants
> > of all libraries and Debian followed suit as of 1.37.0.  The
> > single-threaded variant was named, e.g. "-lboost_regex" while the
> > multi-threaded variant was suffixed with "-mt", i.e. named
> > "-lboost_regex-mt".  Your package needs to change its linker
> > arguments.
> 
> Thanks for these explanations, Steve (I've managed to get boost on
> kfreebsd-* and I wondered a bit why linking failed, and first thought
> our packages were botched somehow). I've prepared a fixed package
> uploaded to DELAYED/3 to fix that. Tim: you can incorporate the changes
> and do an MU in the meanwhile, or ask me to cancel it if you would like
> more time to do that yourself. But given there was no answer on this bug
> report yet, I chose “action by default”. :)

I've looked at your changes and they look fine; so no need to cancel the 
upload.  Thanks for accelerating progress on this bug!

-Tim Abbott

Bug#535357: sagemath: migrate from python-processing to python-multiprocessing

[Tim Abbott]

OK, so there is a bit of work involved as I need to patch all the imports.  
There's a chance I might get to this during the weekend, but I'm really 
busy so it is hard to be sure.

    -Tim Abbott

On Wed, 1 Jul 2009, Sandro Tosi wrote:

> Hi Tim,
> wow thanks for the fast reply! :)
> 
> On Wed, Jul 1, 2009 at 23:42, Tim Abbott wrote:
> > Is just changing the dependency sufficient, or is there anything else that
> > needs to be done for this transition?
> 
> It should be a drop-in replacement, so yes changing dependency *AND*
> import in the code (since now the module is 'multiprocessing' not
> 'processing') should be enough (except corner cases I don't know at
> the moment).
> 
> Cheers,
> -- 
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
> 



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

Bug#535357: sagemath: migrate from python-processing to python-multiprocessing

[Tim Abbott]

Is just changing the dependency sufficient, or is there anything else that 
needs to be done for this transition?

-Tim Abbott

On Wed, 1 Jul 2009, Sandro Tosi wrote:

> Package: sagemath
> Severity: important
> 
> Hello,
> python-multiprocessing is the backport for Python 2.4/2.5 of multiprocessing
> module now available in the standard library in 2.6/3.0.
> 
> python-multiprocessing is an adaptation of python-processing for the standard
> library policy, so the former superseeds the latter.
> 
> Therefore, please migrate the code from python-processing to
> python-multiprocessing, so that we will be able to remove python-processing 
> from
> the archive.
> 
> Thanks,
> Sandrp
> 
> -- System Information:
> Debian Release: squeeze/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 2.6.22-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> 
> Versions of packages sagemath depends on:
> pn  cython (no description available)
> pn  gap(no description available)
> pn  gap-guava  (no description available)
> pn  genus2reduction(no description available)
> pn  gfan   (no description available)
> pn  gfortran   (no description available)
> pn  gmp-ecm(no description available)
> ii  ipython   0.9.1-3enhanced interactive Python shell
> pn  lcalc  (no description available)
> ii  libatlas3gf-base [libatla 3.6.0-24   Automatically Tuned Linear 
> Algebra
> ii  libc6 2.9-4  GNU C Library: Shared libraries
> pn  libcdd-test(no description available)
> pn  libecm0(no description available)
> pn  libflint-1.011 (no description available)
> pn  libfplll0  (no description available)
> ii  libgcc1   1:4.4.0-5  GCC support library
> pn  libgivaro0 (no description available)
> ii  libgmp3c2 2:4.2.4+dfsg-2 Multiprecision arithmetic library
> pn  libgmpxx4ldbl  (no description available)
> ii  libgsl0ldbl   1.12+dfsg-1GNU Scientific Library (GSL) -- 
> li
> pn  libiml0(no description available)
> ii  libjs-jquery  1.3.2-2JavaScript library for dynamic 
> web
> pn  liblinbox0 (no description available)
> pn  libm4ri-0.0.20080521   (no description available)
> pn  libmpfi0   (no description available)
> ii  libmpfr1ldbl  2.4.1-1multiple precision 
> floating-point 
> pn  libntl-5.4.2   (no description available)
> pn  libpari2-gmp   (no description available)
> pn  libpolybori-0.5.0-0(no description available)
> pn  libqd2c2a  (no description available)
> ii  libreadline5  5.2-4  GNU readline and history 
> libraries
> pn  libsingular-3-0-4-3(no description available)
> pn  libsingular-dev(no description available)
> ii  libstdc++64.4.0-5The GNU Standard C++ Library v3
> pn  libsymmetrica-2.0  (no description available)
> pn  libzn-poly-0.8 (no description available)
> pn  maxima-share   (no description available)
> ii  mercurial 1.2-1  scalable distributed version 
> contr
> pn  palp   (no description available)
> pn  pari-extra (no description available)
> pn  pari-gp(no description available)
> ii  python2.5.4-2An interactive high-level 
> object-o
> ii  python-central0.6.11 register and build utility for 
> Pyt
> ii  python-crypto 2.0.1+dfsg1-4  cryptographic algorithms and 
> proto
> pn  python-cvxopt  (no description available)
> pn  python-gd  (no description available)
> ii  python-gnutls 1.1.8-1Python wrapper for the GNUTLS 
> libr
> ii  python-matplotlib 0.98.5.3-1 Python based plotting system in 
> a 
> pn  python-moinmoin(no description available)
> pn  python-networkx(no description available)
> i

Bug#435577: gdebi is supposed to support pre-depends, it is just broken

[Tim Abbott]

tags 435577 + patch
thanks

gdebi actually has code to support Pre-Depends (because of how it installs 
dependencies before trying to install the target package, installing them 
along with depends works fine).

However, for some reason gdebi reads a field called PreDepends, not 
Pre-Depends (perhaps due to confusion related to apt internally having 
something called PreDepends).  Pre-Depends is the thing that appears in 
control files and thus the thing that gdebi should read.

Patch attached.

-Tim AbbottFrom fe3f6249a8658cdccdf0d565e6b7f0df73a5c967 Mon Sep 17 00:00:00 2001
From: Tim Abbott 
Date: Thu, 25 Jun 2009 15:50:24 -0400
Subject: [PATCH] Use the correct name for the Pre-Depends field in control files.

Signed-off-by: Tim Abbott 
---
 GDebi/DebPackage.py |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/GDebi/DebPackage.py b/GDebi/DebPackage.py
index 161edf0..c6f94a8 100755
--- a/GDebi/DebPackage.py
+++ b/GDebi/DebPackage.py
@@ -183,7 +183,7 @@ class DebPackage(object):
 def getDepends(self):
 depends = []
 # find depends
-for key in ["Depends","PreDepends"]:
+for key in ["Depends","Pre-Depends"]:
 if self._sections.has_key(key):
 depends.extend(apt_pkg.ParseDepends(self._sections[key]))
 return depends
-- 
1.6.3.1

Bug#534148: singular: FTBFS on Debian GNU/Hurd [Patch but possibly incomplete]

[Tim Abbott]

On Mon, 22 Jun 2009, Barry deFreese wrote:

> Yes, I realize that but I do get shared objects.  Though, maybe I am not
> getting them all?
> 
> goober:/devel/bdefreese/singular/singular-3-0-4-3.dfsg# find ./ -name *.so
> ./Singular/libsingular-3-0-4-3.so
> ./Singular/libsingular.so
> ./debian/tmp/usr/lib/singular/libsingular-3-0-4-3.so
> ./debian/tmp/usr/lib/singular/libsingular.so
> ./debian/libsingular-dev/usr/lib/libsingular.so
> 
> What I am questioning is why would they end up in tmp/usr/bin even if I wasn't
> getting them?

When building a Debian package with multiple binary packages, the rules 
file normally runs "make install" with a DESTDIR of debian/tmp.

For reasons related to libsingular's weird build process, the files that I 
install to

/usr/lib/singular/p_Procs_FieldGeneral.so
/usr/lib/singular/p_Procs_FieldQ.so
/usr/lib/singular/p_Procs_FieldZp.so
/usr/lib/singular/p_Procs_FieldIndep.so

are put in /usr/bin by "make install" in the Singular package.  These 
p_Procs_Field*.so files are probably what you are missing.

-Tim Abbott





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

Bug#534148: singular: FTBFS on Debian GNU/Hurd [Patch but possibly incomplete]

[Tim Abbott]

debian/tmp is the default DESTDIR when building a source package that 
produces multiple binary packages; so your problem with dh_install is 
probably that the shares objects were not produced at all by the build 
process.

-Tim Abbott

On Sun, 21 Jun 2009, Barry deFreese wrote:

> Package: singular
> Version: 3-0-4-3.dfsg-2
> Severity: normal
> 
> Hi,
> 
> singular currently fails to build on Debian GNU/Hurd.  The attached patch lets
> it build but dh_install is looking for some .so files in debian/tmp/usr/bin
> which don't exist for me.  But it seems a strange path to me anyway so is this
> a Hurd issue or something else?
> 
> Thank you,
> 
> Barry deFreese
> 
> 
> 



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

Bug#528275: libgivaro-dev: examples won't compile out of tree

[Tim Abbott]

> It seems the examples included with libgivaro-dev won't compile out of
> the box because they try to re-run automake. It doesn't seem to do
> that when I build in the givaro source tree.
> 
> host:projects/examples/Rational % make iratrecon
> cd ../.. && make  am--refresh
> make[1]: Entering directory `/home/bremner/projects'
> make[1]: *** No rule to make target `am--refresh'.  Stop.
> make[1]: Leaving directory `/home/bremner/projects'
> make: *** [../../configure] Error 2

It does seem the makefiles included in the givaro library for the examples 
don't like the fact that the rest of the source tree isn't there.  I'm not 
sure what the best solution is here.

As a workaround for now, you can of course compile the examples with e.g. 

g++ -o iratrecon iratrecon.C -lgivaro -lgmp

-Tim Abbott



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

Bug#526585: givaro: FTBFS: libtool errors

[Tim Abbott]

I can confirm this on sid.  I'm been planning to update givaro to a newer 
version soon; I'll fix this when I do that.

    -Tim Abbott

On Fri, 1 May 2009, Daniel Schepler wrote:

> Package: givaro
> Version: 3.2.10-1
> Severity: serious
> 
> From my pbuilder build log:
> 
> ...
> Making all in system
> make[5]: Entering directory `/tmp/buildd/givaro-3.2.10/src/kernel/system'
> /bin/sh ../../../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
> -I../../.. -I../../.. -I../../../src/kernel/memory   -g -O2 -g -Wall -O2 -c 
> -o givbasictype.lo givbasictype.C
> ../../../libtool: line 841: X--tag=CXX: command not found
> ../../../libtool: line 874: libtool: ignoring unknown tag : command not found
> ../../../libtool: line 841: X--mode=compile: command not found
> ../../../libtool: line 1008: *** Warning: inferring the mode of operation is 
> deprecated.: command not found
> ../../../libtool: line 1009: *** Future versions of Libtool will require 
> --mode=MODE be specified.: command not found
> ../../../libtool: line 1152: Xg++: command not found
> ../../../libtool: line 1152: X-DHAVE_CONFIG_H: command not found
> ../../../libtool: line 1152: X-I.: command not found
> ../../../libtool: line 1152: X-I../../..: No such file or directory
> ../../../libtool: line 1152: X-I../../..: No such file or directory
> ../../../libtool: line 1152: X-I../../../src/kernel/memory: No such file or 
> directory
> ../../../libtool: line 1152: X-g: command not found
> ../../../libtool: line 1152: X-O2: command not found
> ../../../libtool: line 1152: X-g: command not found
> ../../../libtool: line 1152: X-Wall: command not found
> ../../../libtool: line 1152: X-O2: command not found
> ../../../libtool: line 1152: X-c: command not found
> ../../../libtool: line 1205: Xgivbasictype.lo: command not found
> ../../../libtool: line 1210: libtool: compile: cannot determine name of 
> library object from `': command not found
> make[5]: *** [givbasictype.lo] Error 1
> make[5]: Leaving directory `/tmp/buildd/givaro-3.2.10/src/kernel/system'
> make[4]: *** [all-recursive] Error 1
> make[4]: Leaving directory `/tmp/buildd/givaro-3.2.10/src/kernel'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory `/tmp/buildd/givaro-3.2.10/src'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/tmp/buildd/givaro-3.2.10'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/tmp/buildd/givaro-3.2.10'
> make: *** [debian/stamp-makefile-build] Error 2
> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
> -- 
> Daniel Schepler
> 
> 
> 
> 



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

Bug#525620: cython: Please package new upstream

[Tim Abbott]

package: cython
version: 0.10.3
severity: wishlist

Cython 0.11 is out (and is needed for the latest version of Sage), so it 
would be great if the Cython in Debian could be upgraded to that version.

-Tim Abbott



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

Bug#523708: Fixes problems with config-package-dev and lintian 2.2.9

[Tim Abbott]

I was about to report that using config-package-dev on sid resulted in 
some incorrect lintian warnings related to adding/removing diversions 
(apparently because of quoting).  I've tested that Raphael's patch fixes 
the issue.

    -Tim Abbott



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

Bug#523986: apt: Confusing "malformed Release file" error for nonexistent repository components

[Tim Abbott]

Package: apt
Severity: normal
Version: 0.7.20.2
Tags: patch

If you have an invalid component name in your sources.list file, e.g. the 
"mainy" in:

deb http://http.us.debian.org/debian/ sid mainy

and then you do an "apt-get update", you get this confusing error message:

W: Failed to fetch http://http.us.debian.org/debian/dists/sid/Release 
Unable to find expected entry mainy/binary-i386/Packages in Meta-index 
file (malformed Release file?)

Suggesting that the problem is (1) "Failed to fetch" and (2) the result of 
a malformed Release file is very confusing here, given that the issue here 
is a problem with the local configuration, not the remote repository (and 
that a typo in sources.list is probably much more common than a malformed 
Release file).

I've looked at the code that generates this error, and it is clear from 
apt-pkg/algorithms.cc that "Failed to fetch" is printed for essentially 
any error in the "apt-get update" process.  This seems simply wrong; the 
best fix for this issue is probably to change the way the error string is 
generated to move the "Failed to fetch" into the individual error messages 
related to fetching, and have some other initial error string for errors 
related to parsing or finding required components.


As a short-term fix, I think it would be desireable to change 
apt-pkg/acquire-item.cc to replace the error message

"Unable to find expected entry  " + (*Target)->MetaKey + " in Meta-index file 
(malformed Release file?)";

with

"Fetched successfully, but expected entry " + (*Target)->MetaKey + " not 
found in Meta-index (misspelled, or Release file malformed?)"

so that the complete error message reads 

"W: Failed to fetch http://http.us.debian.org/debian/dists/sid/Release
Fetched successfully, but expected entry mainy/binary-i386/Packages not found 
in Meta-index (misspelled, or Release file malformed?)"

which I think is at least more clear.  I've attached a patch to do this 
simple improvement (though I'd prefer it if the broader problem were fixed 
instead).

-Tim Abbott=== modified file 'apt-pkg/acquire-item.cc'
--- old/apt-pkg/acquire-item.cc	2008-10-29 17:58:48 +
+++ new/apt-pkg/acquire-item.cc	2009-04-14 05:47:41 +
@@ -1055,8 +1055,8 @@
  if (!Record)
  {
 Status = StatAuthError;
-ErrorText = "Unable to find expected entry  "
-   + (*Target)->MetaKey + " in Meta-index file (malformed Release file?)";
+	ErrorText = "Fetched successfully, but expected entry " 
+   + (*Target)->MetaKey + " not found in Meta-index (misspelled, or Release file malformed?)";
 return;
  }
  ExpectedIndexHash = Record->Hash;

Bug#475777: [PATCH] sbuild: Add support for appending a tag at the end of version numbers

[Tim Abbott]

Looks reasonable.

-Tim Abbott

On Sun, 12 Apr 2009, Roger Leigh wrote:

> On Sat, Apr 11, 2009 at 04:58:41PM -0400, Tim Abbott wrote:
> […]
> 
> Many thanks for the patch.  I applied it verbatim, but followed
> it with the following small change.  This moves the source/append
> version conflict check from the options parser Sbuild::Options to
> Sbuild::Conf so it works if you are driving sbuild without using
> the options parser.
> 
> diff --git a/lib/Sbuild/Conf.pm b/lib/Sbuild/Conf.pm
> index 943b278..a20293a 100644
> --- a/lib/Sbuild/Conf.pm
> +++ b/lib/Sbuild/Conf.pm
> @@ -70,6 +70,18 @@ sub init_allowed_keys {
>   if !-d $directory;
>  };
>  
> +my $validate_append_version = sub {
> + my $self = shift;
> + my $entry = shift;
> +
> + if (defined($self->get('APPEND_TO_VERSION')) &&
> + $self->get('APPEND_TO_VERSION') &&
> + $self->get('BUILD_SOURCE') != 0) {
> + # See <http://bugs.debian.org/475777> for details
> + die "The --append-to-version option is incompatible with a source 
> upload\n";
> + }
> +};
> +
>  my $HOME = $self->get('HOME');
>  
>  my %sbuild_keys = (
> @@ -408,7 +420,8 @@ sub init_allowed_keys {
>   DEFAULT => []
>   },
>   'BUILD_SOURCE'  => {
> - DEFAULT => 0
> + DEFAULT => 0,
> + CHECK => $validate_append_version,
>   },
>   'ARCHIVE'   => {
>   DEFAULT => undef
> @@ -420,7 +433,8 @@ sub init_allowed_keys {
>   DEFAULT => undef
>   },
>   'APPEND_TO_VERSION' => {
> - DEFAULT => undef
> + DEFAULT => undef,
> + CHECK => $validate_append_version,
>   },
>   'GCC_SNAPSHOT'  => {
>   DEFAULT => 0
> diff --git a/lib/Sbuild/Options.pm b/lib/Sbuild/Options.pm
> index 8ee63db..02f8ca8 100644
> --- a/lib/Sbuild/Options.pm
> +++ b/lib/Sbuild/Options.pm
> @@ -184,11 +184,6 @@ sub parse_options {
>  },
>   );
>  
> -if (defined($self->get_conf('APPEND_TO_VERSION')) &&
> - $self->get_conf('BUILD_SOURCE') != 0) {
> - # See <http://bugs.debian.org/475777> for details
> - die "The --append-to-version option is incompatible with a source 
> upload\n";
> -}
>  return $ret;
>  }
> 
>  
> Regards,
> Roger
> 
> -- 
>   .''`.  Roger Leigh
>  : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
>  `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
>`-GPG Public Key: 0x25BFB848   Please GPG sign your mail.
> 

Bug#475777: [PATCH] sbuild: Add support for appending a tag at the end of version numbers

[Tim Abbott]

Signed-off-by: Tim Abbott 
---
 lib/Sbuild.pm |   14 +++---
 lib/Sbuild/Build.pm   |   23 ---
 lib/Sbuild/Conf.pm|3 +++
 lib/Sbuild/Options.pm |   12 +++-
 man/sbuild.1.in   |6 ++
 5 files changed, 47 insertions(+), 11 deletions(-)

diff --git a/lib/Sbuild.pm b/lib/Sbuild.pm
index ecc2138..1b54a8e 100644
--- a/lib/Sbuild.pm
+++ b/lib/Sbuild.pm
@@ -61,7 +61,7 @@ sub do_version_cmp ($$);
 sub order ($);
 sub version_cmp_single ($$);
 sub split_version ($);
-sub binNMU_version ($$);
+sub binNMU_version ($$$);
 sub parse_date ($);
 sub isin ($@);
 sub copy ($);
@@ -211,11 +211,19 @@ sub split_version ($) {
return( $epoch, $vers, $revision );
 }
 
-sub binNMU_version ($$) {
+sub binNMU_version ($$$) {
my $v = shift;
my $binNMUver = shift;
+   my $append_to_version = shift;
 
-   return "$v+b$binNMUver";
+   my $ver = $v;
+   if (defined($append_to_version) && $append_to_version) {
+   $ver .= $append_to_version;
+   }
+   if (defined($binNMUver) && $binNMUver) {
+   $ver .= "+b$binNMUver";
+   }
+   return $ver;
 }
 
 my %monname = ('jan', 0, 'feb', 1, 'mar', 2, 'apr', 3, 'may', 4, 'jun', 5,
diff --git a/lib/Sbuild/Build.pm b/lib/Sbuild/Build.pm
index 0ec6065..9e52789 100644
--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -148,8 +148,9 @@ sub set_version {
 my $oversion = $version; # Original version (no binNMU addition)
 
 # Add binNMU to version if needed.
-if ($self->get_conf('BIN_NMU')) {
-   $version = binNMU_version($version, $self->get_conf('BIN_NMU_VERSION'));
+if ($self->get_conf('BIN_NMU') || $self->get_conf('APPEND_TO_VERSION')) {
+   $version = binNMU_version($version, $self->get_conf('BIN_NMU_VERSION'),
+   $self->get_conf('APPEND_TO_VERSION'));
 }
 
 (my $sversion = $version) =~ s/^\d+://; # Strip epoch
@@ -638,7 +639,7 @@ sub build {
}
 }
 
-if ($self->get_conf('BIN_NMU')) {
+if ($self->get_conf('BIN_NMU') || $self->get_conf('APPEND_TO_VERSION')) {
$self->log_subsubsection("Hack binNMU version");
$self->set('Pkg Fail Stage', "hack-binNMU");
if (open( F, "<$dscdir/debian/changelog" )) {
@@ -656,12 +657,20 @@ sub build {
return 0;
}
$dists = $self->get_conf('DISTRIBUTION');
+
print F "$name ($NMUversion) $dists; urgency=low\n\n";
-   print F "  * Binary-only non-maintainer upload for $arch; ",
-   "no source changes.\n";
-   print F "  * ", join( "", split( "\n", 
$self->get_conf('BIN_NMU') )), "\n\n";
-   print F " -- " . $self->get_conf('MAINTAINER_NAME') . "  $date\n\n";
+   if ($self->get_conf('APPEND_TO_VERSION')) {
+   print F "  * Append ", $self->get_conf('APPEND_TO_VERSION'),
+   " to version number; no source changes\n";
+   }
+   if ($self->get_conf('BIN_NMU')) {
+   print F "  * Binary-only non-maintainer upload for $arch; ",
+   "no source changes.\n";
+   print F "  * ", join( "", split( "\n", 
$self->get_conf('BIN_NMU') )), "\n";
+   }
+   print F "\n";
 
+   print F " -- " . $self->get_conf('MAINTAINER_NAME') . "  $date\n\n";
print F $firstline, $text;
close( F );
$self->log("*** Created changelog entry for bin-NMU version 
$NMUversion\n");
diff --git a/lib/Sbuild/Conf.pm b/lib/Sbuild/Conf.pm
index 7c4a14a..943b278 100644
--- a/lib/Sbuild/Conf.pm
+++ b/lib/Sbuild/Conf.pm
@@ -419,6 +419,9 @@ sub init_allowed_keys {
'BIN_NMU_VERSION'   => {
DEFAULT => undef
},
+   'APPEND_TO_VERSION' => {
+   DEFAULT => undef
+   },
'GCC_SNAPSHOT'  => {
DEFAULT => 0
},
diff --git a/lib/Sbuild/Options.pm b/lib/Sbuild/Options.pm
index 8273191..8ee63db 100644
--- a/lib/Sbuild/Options.pm
+++ b/lib/Sbuild/Options.pm
@@ -56,7 +56,7 @@ sub new {
 sub parse_options {
 my $self = shift;
 
-return GetOptions ("h|help" => sub { help_text("1", "sbuild"); },
+my $ret = GetOptions ("h|help" => sub { help_text("1", &q

Bug#523670: sbuild: --help and --version options don't work if not in group sbuild

[Tim Abbott]

package: sbuild
version: 0.57-7.1
severity: minor

If you haven't configured sbuild on a machine, and you try to look at the 
built-in help documentation, you get an error:

$ sbuild --help
User tabbott is not a member of group sbuild
See "User Setup" in sbuild-setup(7)

Probably options like --help, --version, etc. should work even if you're 
not in group sbuild.

-Tim Abbott



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

Bug#475777: sbuild: Add support for appending a tag to version numbers

[Tim Abbott]

Roger,

Does my proposed fix for the problem you had using my patch (namely, 
making -s and --append-to-version conflict) seem acceptable to you?  I 
don't see a way to avoid the conflict and they don't seem like a pair of 
options one would want to use simultaneously anyway.

If so, I'll post a new version with those options set up to conflict on 
top of current sbuild master.

Regards,
-Tim Abbott



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

Bug#495000: please consider making libatlas-base-dev optional

[Tim Abbott]

On Tue, 10 Feb 2009, Riku Voipio wrote:

> On Mon, Feb 09, 2009 at 09:45:02PM -0500, Tim Abbott wrote:
> > > Any news on this? It is blocking arrival of sagemath on several 
> > > architectures
> > > (alpha, arm*)
> 
> > I hope you'll understand that I prioritized getting sagemath into Debian 
> > over getting its dependencies working on all architectures.
> 
> Ok, I just wanted to know if there were any issues that were blocking solving
> this bug.

Just a quick update on this; I've confirmed with upstream that they'd be 
happy to take a patch that modified iml to just require any blas 
implementation.  Unfortunately, I've been quite busy and so I've not had 
time to rewrite their m4 yet.

-Tim Abbott



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

Bug#450703: I think this is actually a bug in gcl

[Tim Abbott]

clone 450703 -1
reassign -1 gcl
retitle -1 gcl: crash after ctrl-C
thanks

recipe:

(1) start gcl
(2) hit  and then 

causes a crash (shown below).  Since maxima is built from gcl (and 
building maxima against clisp seems to not have these problems), it seems 
likely that this is a gcl bug.

I get the same "out of memory allocating N bytes after a total of M bytes" 
error frequently when trying to use maxima via Sage's pexpect interface, 
so I suspect that this is a relatively easy to reproduce instance of a 
more serious problem with gcl's memory management.

(Cloning the bug rather than just reassigning, since once it is fixed is 
gcl, Maxima will need a rebuild to fix it bug there).

-Tim Abbott

[tabb...@coset ~$] gcl
GCL (GNU Common Lisp)  2.6.7 CLtL1Sep  1 2008 14:01:57
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/

>

Correctable error: Console interrupt.
Signalled by READ.
If continued: Type :r to resume execution, or :q to quit to top level.
Broken at SYSTEM:TERMINAL-INTERRUPT.  Type :H for Help.
>>
out of memory allocating 3 bytes after a total of 83211840 bytes




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

Bug#519887: sagemath: dsage doesn't work with python-twisted 8.2.0

[Tim Abbott]

package: sagemath
severity: normal

It seems the new version of python-twisted (8.2.0) breaks dsage; it's easy 
to reproduce as dsage runs first in "sage -testall"

-Tim Abbott



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

Bug#519753: sagemath: unnecessary dependency on libsingular-dev

[Tim Abbott]

package: sagemath
severity: normal

The symlink /usr/lib/sagemath/local/lib/libsingular.so should be moved to 
point to a particular version of libsingular, rather than the generic 
symlink.  This should fix potential problems if the wrong version of 
singular is installed and also allow us to remove libsingular-dev as a 
runtime dependency.

-Tim Abbott



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

Bug#518565: emacs22: tex-dvi-print-command should not default to "lpr -d"

[Tim Abbott]

package: emacs22
severity: minor
version: 22.2+2-5

Currently, tex-dvi-print-command defaults to "lpr -d".  This option is 
deprecated in lprng and doesn't exist in CUPS.  It should probably be 
changed to something like:

(setq tex-dvi-print-command "dvips -f * | lpr")

-Tim Abbott



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

Bug#518559: finger: Doesn't work with a non-iterable nsswitch source

[Tim Abbott]

Package: finger
Severity: normal
Tags: patch

Currently, "finger tabbott" works by iterating through the list of users 
on the system using getpwent and checking if any of them match "tabbott".  

Some nsswitch backends (including Hesiod and LDAP[1]) do not support 
iterating through the complete list of users.  These nsswitch backends 
instead only fully support looking up a user's information by username or 
uid.

So, if tabbott is a user whose nsswitch information comes from LDAP, then 
"finger tabbott" will incorrectly report "finger: tabbott: no such user."  
"finger -m tabbott" does work correctly, however, because it looks up the 
matching username using getpwnam.


A fix for this is to always look up an argument to finger for a username 
match, and having -m only control whether finger searches the entire user 
database for real name matches.  Patch attached.

This patch has the advantageous side effect that if there are some real 
name matches and a username match, finger will always display the username 
match first (rather than in some random place in the list).

-Tim Abbott

[1] with LDAP, it is typically the case that one can iterate through only 
the first 100 results from a query.commit ab0b4e09b1281a11587fd0f9797e612cfb08ef57
Author: Timothy G Abbott 
Date:   Fri Mar 6 22:30:00 2009 -0500

Add support for non-iterable nsswitch sources.

Signed-off-by: Timothy G Abbott 

diff --git a/finger/finger.c b/finger/finger.c
index 7b96d3c..5737782 100644
--- a/finger/finger.c
+++ b/finger/finger.c
@@ -241,28 +241,35 @@ static void do_local(int argc, char *argv[], int *used) {
 	int i;
 	struct passwd *pw;
 
+	for (i = 0; i < argc; i++) {
+		if (used[i] >= 0 && (pw = getpwnam(argv[i]))) {
+			if (!check_nofinger(pw)) {
+enter_person(pw);
+used[i] = 1;
+			}
+		}
+	}
 	/*
-	 * traverse the list of possible login names and check the login name
-	 * and real name against the name specified by the user.
+	 * Traverse the list of users and check the real name against
+	 * the name specified by the user.
+	 *
+	 * Since we've already entered users whose usernames match,
+	 * ignore them when doing real name matching.
 	 */
-	if (mflag) {
-		for (i = 0; i < argc; i++)
-			if (used[i] >= 0 && (pw = getpwnam(argv[i]))) {
-if (!check_nofinger(pw)) {
-	enter_person(pw);
-	used[i] = 1;
-}
-			}
-	} else for (pw = getpwent(); pw; pw = getpwent())
-		for (i = 0; i < argc; i++)
-			if (used[i] >= 0 &&
-			(!strcasecmp(pw->pw_name, argv[i]) ||
-			match(pw, argv[i]))) {
-if (!check_nofinger(pw)) {
-	enter_person(pw);
-	used[i] = 1;
+	if (!mflag) {
+		for (pw = getpwent(); pw; pw = getpwent()) {
+			for (i = 0; i < argc; i++) {
+if (used[i] >= 0 &&
+strcasecmp(pw->pw_name, argv[i]) &&
+match(pw, argv[i])) {
+	if (!check_nofinger(pw)) {
+		enter_person(pw);
+		used[i] = 1;
+	}
 }
 			}
+		}
+	}
 
 	/* list errors */
 	for (i = 0; i < argc; i++)

Bug#514648: [sagemath] "x+x" produces EOF: End Of File (EOF) in read_nonblocking().

[Tim Abbott]

> maxima| 5.17.1-1

The issue indeed seems to be that Maxima 5.17 is incompatible with Sage 
3.0.5.  If you downgrade maxima and maxima-share to the version in lenny, 
this crash seems to go away in my testing (it also seems I need to add a 
dependency on maxima-share).

    -Tim Abbott





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

Bug#514785: These bug reports represent the same problem

[Tim Abbott]

severity 513819 serious
merge 513819 514785
thanks

These two bugs reports are redundant (as the package has never built on 
mips).  Since mips is a supported architecture, I think serious is the 
correct severity for them.

-Tim Abbott



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

Bug#515052:

[Tim Abbott]

On Fri, 13 Feb 2009, Kushal Koolwal wrote:

> Yes, it somehow got compiled with "Quoth..." when I was trying different 
> thing - like re-compiling kernel with default config file when my 
> previous attempt to use ksplice-create failed as mentioned before.
> 
> So in order to distinguish the process I deleted the source (2.6.26) in 
> which "Quoth.." was compiled and I downloaded the a fresh copy of source 
> again and this time I slightly modified the patch from the example to 
> replace "Quoth" with "Quote" so that I know if the process worked or 
> not. I guess may be this is too much confusingsorry about that.

Right, well the problem is that Ksplice requires that you give it 
precisely the running kernel source, and you gave it the running kernel 
source without the "Quoth" patch applied.  So, one of Ksplice's safety 
checks aborted the upgrade.

It should work if you were to use the correct running kernel source and 
have your patch change "Quoth" to "Quote".

> Should I just start fresh and see what happens?

That might be easiest.

-Tim Abbott



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

Bug#515052:

[Tim Abbott]

From looking at the debugging output, I'm guessing that the 2.6.26-ksplice 
kernel that you compiled was compiled with the "Quoth the kernel" example 
patch already applied.  

You should be able to confirm this fairly easily by seeing whether "Quoth 
the kernel" appears in the output of "dmesg".  

-Tim Abbott

On Fri, 13 Feb 2009, Kushal Koolwal wrote:

> 
> Hi Tim,
> 
> > Are you running the kernel 2.6.26-ksplice as well as using it to be build
> > your update against?
> Yes, I was running 2.6.26-ksplice while doing ksplice-create and 
> ksplice-apply process. Sorry I forgot to mentioned that in the steps 
> previously listed.
> 
> > If you send me the data stored in the debugging file when your run
> > ksplice-apply with debugging enabled
> Not sure where the debug output is stored, but I am attaching the debug 
> messages from "dmesg" when I gave the command ksplice-apply --debug 
> ./ksplice-kkda1whi.tar.gz
> 
> Please see the attachment.
> 
> Thank you once again for your prompt response.
> 
> Kushal Koolwal
> 
> I do blog at http://blogs.koolwal.net/
> _
> Windows Live™: E-mail. Chat. Share. Get more ways to connect. 
> http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_allup_howitworks_022009

Bug#515052:

[Tim Abbott]

Hi Kushal,

Are you running the kernel 2.6.26-ksplice as well as using it to be build 
your update against?

If you send me the data stored in the debugging file when your run 
ksplice-apply with debugging enabled

ksplice-apply --debug ./ksplice-kkda1whi.tar.gz

I can take a look at it.

-Tim Abbott

On Fri, 13 Feb 2009, Kushal Koolwal wrote:

> 
> Hi Tim,
> 
> So I made some progress after downloading the latest 0.9.6 version as 
> suggested by you. But now I got stuck at the ksplice-apply command. Here is 
> what I get:
> 
> 
> make: Entering directory `/usr/src/linux-headers-2.6.26-ksplice'
>   INSTALL /tmp/ksplice-tmp-Q5Yl6u/kmodsrc/ksplice-kkda1whi.ko
>   INSTALL /tmp/ksplice-tmp-Q5Yl6u/kmodsrc/ksplice-kkda1whi_vmlinux-helper.ko
>   INSTALL /tmp/ksplice-tmp-Q5Yl6u/kmodsrc/ksplice-kkda1whi_vmlinux.ko
> make: Leaving directory `/usr/src/linux-headers-2.6.26-ksplice'
> Ksplice update tarball written to ksplice-kkda1whi.tar.gz
> 
> debian-sid:/usr/src/linux-source-2.6.26/kernel# ksplice-apply 
> ./ksplice-kkda1whi.tar.gz 
> Error applying Ksplice update kkda1whi:
> Ksplice has aborted the upgrade because Ksplice has been unable to match the
> object code produced by your current compiler and assembler against the 
> running
> kernel's object code.  If you provided the exact kernel source to the running
> kernel, then it appears that your current compiler and/or assembler are
> behaving differently from the compiler and assembler used to build the running
> kernel.  If possible, please use the exact compiler and assembler that were
> used to build the running kernel.  If you are using exactly the same compiler
> and assembler, consider reporting a bug to de...@ksplice.com.
> 
> Died at /usr/local/sbin/ksplice-apply line 131.
> debian-sid:/usr/src/linux-source-2.6.26/kernel#
> 
> Now the ksplice-create commands is able to successfully create the 
> tarball file. I am pretty sure that the kernel that I am using 
> (2.6.26-ksplice) is compiled with the same gcc version on my system. 
> Here is what I did to ensure that:
> 0. apt-get update; apt-get upgrade
> 1. I just downloaded the linux-source-2.6.26 from Debian Sid.
> 2. Copied my default /boot/config-2.6.26-1-686 to the sources 
> linux-source-2.6.26
> 3. Compiled a new kernel called 2.6.26-ksplice (make-kpkg way)
> 
> And then I followed the instructions as mentioned in my original bug report.
> 
> Not sure if I missed any step or there is still some bug.
> 
> Kushal Koolwal
> 
> I do blog at http://blogs.koolwal.net/
> 
> 
> 
> 
> _
> Windows Live™: E-mail. Chat. Share. Get more ways to connect. 
> http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_AE_Faster_022009
> 
> 
> 

Bug#515052: ksplice-create fails to create tarball

[Tim Abbott]

Hello,

This problem is caused by a bug in Ksplice 0.9.5 that was fixed in the 
Ksplice 0.9.6 upstream release.

-Tim Abbott



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

Bug#495000: please consider making libatlas-base-dev optional

[Tim Abbott]

On Mon, 9 Feb 2009, Riku Voipio wrote:

> user debian-...@lists.debian.org
> usertag 495000 eabi
> thanks
> 
> Any news on this? It is blocking arrival of sagemath on several architectures
> (alpha, arm*)

I hope you'll understand that I prioritized getting sagemath into Debian 
over getting its dependencies working on all architectures.

Now that Sage is in Debian, I will try to get this (and the analogous bug 
on linbox) fixed relatively soon.

Thanks,

-Tim Abbott




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

Bug#514522: cddlib: cdbs warning: remove config.{guess,sub}

[Tim Abbott]

Hi Martin,

Thanks for the bug report.  I am aware of this problem and am planning on 
fixing it the next time I update the upstream version of cddlib.

-Tim Abbott

On Sun, 8 Feb 2009, Martin Koeppe wrote:

> 
> Package: cddlib
> Version: 094b.dfsg-4
> Severity: normal
> 
> When building cddlib a warning is printed:
> 
> /usr/share/cdbs/1/rules/patchsys-quilt.mk:92: WARNING:  The following patches
> are modifying auto-updated files.  This can result in serious trouble:
> /build/buildd/cddlib-094b.dfsg/debian/patches/cddlib-shared-library.patch:src/config.guess
> /build/buildd/cddlib-094b.dfsg/debian/patches/cddlib-shared-library.patch:src/config.sub
> 
> See any buildd log for verification.
> 
> So probably config.{guess,sub} are not necessary in the patch and cdbs can
> update them while building.
> 
> As the *.orig.tar.gz seems to be modified anyway, these files/dirs should be
> removed also:
> 
> autom4te.cache/
> aclocal.m4~
> config.log
> config.status
> 
> 
> Thanks for consideration
> 
> Martin
> 
> 
> 



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

Bug#513853: [sagemath] sage segfaults

[Tim Abbott]

I'm familiar with that problem, which I'm also planning to fix this 
weekend.  sagemath should depend on libiml0 >= 1.0.3, instead of the 
current libiml0 >= 1.0.2 (which is in lenny).  If you grab libiml0 from 
sid, that should fix this for you.

    -Tim Abbott

On Fri, 6 Feb 2009, Martin Ziegler wrote:

> Hi,
> 
> after I installed libsingular-dev sage stopped segfaulting,
> but produced the following errormessage:
> 
> --
> | SAGE Version 3.0.5, Release Date: 2008-07-11 |
> | Type notebook() for the GUI, and license() for information.|
> --
> 
> Exception exceptions.ImportError:
> '/usr/lib/python2.5/site-packages/sage/matrix/matrix_integer_dense.so:
> undefined symbol: nullspaceMP' in
> 'sage.rings.polynomial.polynomial_element.Polynomial_generic_dense.__normalize'
> ignored
> Exception exceptions.ImportError:
> '/usr/lib/python2.5/site-packages/sage/matrix/matrix_integer_dense.so:
> undefined symbol: nullspaceMP' in
> 'sage.rings.polynomial.polynomial_element.Polynomial_generic_dense.__normalize'
> ignored
> ERROR: An unexpected error occurred while tokenizing input
> The following traceback may be corrupted or invalid
> The error message is: ('EOF in multi-line statement', (145, 0))
> 
> (The traceback followed)
> 
> Regards,
> 
> 
> (Martin Ziegler)
> 
> 
> 



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

Bug#476103: ghmm in Debian

[Tim Abbott]

On Mon, 2 Feb 2009, Sebastian Dröge wrote:

> No, I don't plan to package it anymore as I stopped using it. Feel free
> to take the ITP yourself :)

OK, I probably will do that.  Thanks for the quick response.

    -Tim Abbott

Bug#513853: [sagemath] sage segfaults

[Tim Abbott]

I've confirmed that indeed the problem is in libsingular.so being in 
libsingular-dev.  Expect a fix sometime this weekend.

    -Tim Abbott



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

Bug#513819: Package FTBFS on mips

[Tim Abbott]

Okay, so the actual problem is that sqrtl is not defined on mips, because 
mips has the whole no long doubles thing:


gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g 
-O2 -g -Wall -O2 -fPIC -I/build/buildd/sagemath-3.0.5dfsg/local//include 
-I/build/buildd/sagemath-3.0.5dfsg/local//include/csage 
-I/build/buildd/sagemath-3.0.5dfsg/devel//sage/sage/ext -I/usr/include 
-I/usr/include/numpy -I/usr/include/FLINT -I/usr/include/givaro 
-I/usr/include/gsl -I/usr/include/fplll -I/usr/include/eclib 
-I/usr/include/gmp++ -I/usr/include/linbox -I/usr/include/NTL 
-I/usr/include/pari -I/usr/include/qd -I/usr/include/singular 
-I/usr/include/singular/singular -I/usr/include/symmetrica 
-I/usr/include/polybori -I/usr/include/cudd -I/usr/include/polybori/groebner 
-I/usr/include/zn_poly -I/usr/include/python2.5 -c 
sage/combinat/partitions_c.cc -o 
build/temp.linux-mips-2.5/sage/combinat/partitions_c.o -w -w
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
Ada/C/ObjC but not for C++
sage/combinat/partitions_c.cc: In function 'void initialize_constants(unsigned 
int, unsigned int)':
sage/combinat/partitions_c.cc:788: error: 'sqrtl' was not declared in this scope
error: command 'gcc' failed with exit status 1
sage: There was an error installing modified sage library code.

sage/combinat/partitions_c.cc seems to be the only file affected, so this 
should be relatively simple.  Is there a standard fix for this problem?


-Tim Abbott

On Sun, 1 Feb 2009, Peter De Schrijver (p2) wrote:


Package: sagemath
Version: 3.0.5dfsg-1
Severity: important
Justification: fails to build from source

Package FTBFS on mips. See attached logfile.

-- System Information:
Debian Release: 4.0
 APT prefers stable
 APT policy: (500, 'stable')
Architecture: mips (mips64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.25-rc3-0-g84d8498-dirty
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)





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

Bug#513873: sagemath: FTBFS on amd64

[Tim Abbott]

Hi Ben,

It appears that the package did build on amd64 on the Debian buildd 
system:


<http://buildd.debian.org/build.php?&pkg=sagemath&ver=3.0.5dfsg-1&arch=amd64>

I guess this means that the amd64 buildd machines have time installed.

I'll add the missing build dependency on my next upload, probably this 
weekend (it's probably also a missing runtime dependency ...).


-Tim Abbott

On Sun, 1 Feb 2009, Ben Goodrich wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: sagemath
Version: 3.0.5dfsg-1
Severity: serious
Justification: no longer builds from source

Hi Tim,

William Stein pointed out to me that I needed the time program to build
sagemath. For the build failure log, see

http://groups.google.com/group/debian-sage/t/4ffb6039a82cd0ec

Thanks,
Ben


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

Kernel: Linux 2.6.28-2.slh.2-sidux-amd64 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages sagemath depends on:
ii  cython   0.10.2-1C-Extensions for Python
ii  gap  4r4p10-2Groups, Algorithms and
Programming
ii  gap-guava3.6-2   Coding theory library for GAP
ii  genus2reduction  0.3-2   Conductor and Reduction
Types for
ii  gfan 0.3dfsg-1   Program for computing with
Groebne
ii  gfortran 4:4.3.2-2   The GNU Fortran 95 compiler
ii  gmp-ecm  6.2-1   Factor integers using the
Elliptic
ii  ipython  0.8.4-1 enhanced interactive Python
shell
ii  lcalc0.0.20080205-1  a program for calculating
with L-f
hi  libatlas3gf-base 3.6.0-22Automatically Tuned Linear
Algebra
ii  libc62.7-18  GNU C Library: Shared libraries
ii  libcdd-test  094b.dfsg-4 Test programs for libcdd-dev
ii  libecm0  6.2-1   Factor integers using the
Elliptic
ii  libflint-1.011   1.011-2 C library for number
theory, share
ii  libfplll02.1.6+20071129-2A library for LLL-reduction
of Euc
ii  libgcc1  1:4.3.3-1   GCC support library
ii  libgivaro0   3.2.10-1Givaro, a library for
arithmetic a
ii  libgmp3c22:4.2.2+dfsg-3  Multiprecision arithmetic
library
ii  libgmpxx4ldbl2:4.2.2+dfsg-3  Multiprecision arithmetic
library
ii  libgsl0ldbl  1.12+dfsg-1 GNU Scientific Library
(GSL) -- li
ii  libiml0  1.0.3-3 Integer Matrix Library,
runtime fi
ii  libjs-jquery 1.2.6-2 JavaScript library for
dynamic web
ii  liblinbox0   1.1.6~rc0-3 Library for exact linear
algebra,
ii  libm4ri-0.0.2008 0.0.20080521-2  Method of the Four Russians
Invers
ii  libmpfi0 1.3.4~rc4~cvs20080519-1 multiple precision
floating-point
ii  libmpfr1ldbl 2.3.2.dfsg.1-1  multiple precision
floating-point
ii  libntl-5.4.2 5.4.2-4 Number Theory Library,
shared libr
ii  libpari2-gmp 2.3.4-1 PARI/GP Computer Algebra
System sh
ii  libpolybori-0.5. 0.5~rc1-1   Polynomials over Boolean
Rings, sh
ii  libqd2c2a2.3.7-1 Double-double and quad
double type
ii  libreadline5 5.2-3.1 GNU readline and history
libraries
ii  libsingular-3-0- 3-0-4-3.dfsg-2  Library for commutative
algebra, s
ii  libstdc++6   4.3.3-1 The GNU Standard C++ Library v3
ii  libsymmetrica-2. 2.0-1   A library for
combinatorics, share
ii  libzn-poly-0.8   0.8-1   A library for polynomial
arithmeti
ii  maxima   5.17.0-1A computer algebra system
- -- base
ii  mercurial1.1.2-2 scalable distributed
version contr
ii  palp 1.1-1   A Package for Analyzing
Lattice Po
ii  pari-extra   2.1-1   PARI/GP Computer Algebra
System ex
ii  pari-gp  2.3.4-1 PARI/GP Computer Algebra
System bi
ii  python   2.5.2-3 An interactive high-level
object-o
ii  python-central   0.6.8   register and build utility
for Pyt
ii  python-crypto2.0.1+dfsg1-2.3 cryptographic algorithms
and proto
ii  python-cvxopt1.1-1   Python package for convex
optimiza
ii  python-gd0.52debian-3.1  Python module wrapper for libgd
ii  python-gnutls1.1.6-1 Python wrapper for the
GNUTLS libr
ii  python-matplotli 0.98.3-5Python based plotting
system in a
ii  python-moinmoin  1.8.1-1.1   Python clone of WikiWiki -
library
ii  python-networkx  0.36-2  tool t

Bug#513853: [sagemath] the i386 sage segfaults

[Tim Abbott]

Hi Ondrej,

I certainly am not surprised that it doesn't work given how long it has 
had to bitrot in the NEW queue, but I just upgraded my i386 test machine 
to the latest sid and installed from sid, and it did work:


I'll try to reproduce again in a clean environment this weekend.

    -Tim Abbott

On Sun, 1 Feb 2009, Ondrej Certik wrote:


Package: sagemath
Version: 3.0.5dfsg-1
Severity: grave

--- Please enter the report below this line. ---

Hi,

Tim, first let me congratulate you for getting sagemath to Debian, great job!

Currently the i386 package segfaults on my system:

$ sage
--
| SAGE Version 3.0.5, Release Date: 2008-07-11   |
| Type notebook() for the GUI, and license() for information.|
--




Unhandled SIGSEGV: A segmentation fault occured in SAGE.
This probably occured because a *compiled* component
of SAGE has a bug in it (typically accessing invalid memory)
or is not properly wrapped with _sig_on, _sig_off.
You might want to run SAGE under gdb with 'sage -gdb' to debug this.
SAGE will now terminate (sorry).


/usr/lib/sagemath/local/bin/sage-sage: line 216:  5137 Segmentation
fault  sage-ipython "$@" -i -c "$SAGE_STARTUP_COMMAND;"


But I suspect it's just because the sagemath in Debian is old, so
packaging new upstream should fix it.

Ondrej

--- System information. ---
Architecture: i386
Kernel:   Linux 2.6.26-1-686

Debian Release: 5.0
500 unstablemirrors1.kernel.org

--- Package information. ---
Depends (Version) | Installed
=-+-=
libatlas3gf-base  | 3.6.0-22
OR libatlas.so.3gf   |
libc6  (>= 2.7-1) | 2.7-18
libecm0   | 6.2-1
libflint-1.011| 1.011-2
libfplll0 | 2.1.6+20071129-2
libgcc1  (>= 1:4.1.1) | 1:4.3.3-2
libgivaro0| 3.2.10-1
libgmp3c2 | 2:4.2.2+dfsg-3
libgmpxx4ldbl | 2:4.2.2+dfsg-3
libgsl0ldbl  (>= 1.9) | 1.12+dfsg-1
libiml0   | 1.0.3-3
liblinbox0| 1.1.6~rc0-3
libm4ri-0.0.20080521  | 0.0.20080521-2
libmpfi0  | 1.3.4~rc4~cvs20080519-1
libmpfr1ldbl  | 2.3.2.dfsg.1-1
libntl-5.4.2  | 5.4.2-4
libpari2-gmp (>= 2.3.4-1) | 2.3.4-1
libpolybori-0.5.0-0   | 0.5~rc1-1
libqd2c2a | 2.3.7-1
libreadline5 (>= 5.2) | 5.2-3.1
libsingular-3-0-4-3   | 3-0-4-3.dfsg-2
libstdc++6 (>= 4.2.1) | 4.3.3-2
libsymmetrica-2.0 | 2.0-1
libzn-poly-0.8| 0.8-1
python   (<< 2.6) | 2.5.2-3
python   (>= 2.5) | 2.5.2-3
python-central (>= 0.6.7) | 0.6.8
python2.5 | 2.5.2-15
gap   | 4r4p10-2
singular  | 3-0-4-3.dfsg-2
maxima| 5.17.0-1
genus2reduction   | 0.3-2
lcalc | 0.0.20080205-1
sympow| 1.019-4
python-matplotlib | 0.98.3-5
gfan  | 0.3dfsg-1
python-gd | 0.52debian-3.1
mercurial | 1.1.2-2
python-twisted| 8.1.0-4
python-numpy  | 1:1.1.1-2
python-crypto | 2.0.1+dfsg1-2.3
python-moinmoin   | 1.8.1-1.1
sqlite3   | 3.5.9-6
palp  | 1.1-1
ipython   | 0.8.4-1
python-gnutls | 1.1.6-1
python-scipy  | 0.6.0-12
python-cvxopt | 1.1-1
scons | 1.0.0-1
r-base| 2.8.1-2
gfortran  | 4:4.3.2-2
python-sqlalchemy | 0.4.8-1
gmp-ecm   | 6.2-1
python-sympy  | 0.6.3-1
python-networkx   | 0.36-2
python-pexpect| 2.3-1
cython| 0.10.2-1
python-twisted-web2   | 8.1.0-1
pari-gp   | 2.3.4-1
pari-extra| 2.1-1
tachyon   |

Bug#476103: ghmm in Debian

[Tim Abbott]

Hello Sebastian,

Are you still planning on packaging ghmm for Debian?

The latest version of Sage (http://sagemath.org) requires it, and so I was 
about to begin work on packaging it when I found your ITP report.


-Tim Abbott



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

Bug#513838: sagemath: contains embedded cython

[Tim Abbott]

Package: sagemath
severity: serious

The sagemath package contains an embedded copy of the cython package, 
which is problematic for managing security support.  This should be fixed 
before it enters testing.


-Tim Abbott



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

Bug#513837: sagemath: contains embedded jsmath package

[Tim Abbott]

Package: sagemath
Severity: serious

The sagemath package currently contains a copy of the jsmath package 
contained in it, which is problematic for security support.  This should 
be fixed before it enters testing.


-Tim Abbott



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

Bug#512636: please fix Gürkan's name in the control file

[Tim Abbott]

Hello Gürkan,

Sorry about this.  I will fix it the next time that I upload a new NTL 
version (I may do a release just for this, but I'm currently swamped, so 
it may be a couple of weeks).


    -Tim Abbott

On Fri, 23 Jan 2009, gurkan wrote:



Personally I take extra care how *I* write my name. And that's consistent.

Regards,
Gürkan

Bug#513307: schroot: Should ignore ~ files in /etc/schroot/chroot.d

[Tim Abbott]

package: schroot
version: 1.2.1
severity: normal

Hello,

If one is editing files in /etc/schroot/chroot.d using editors that leave 
backup files, it ends up breaking things:


tabb...@ksplice:~$ schroot -c sarge-2-6-8-i386
E: /etc/schroot/chroot.d/tabbott~: line 1 [tabbott]: A chroot or alias 
‘tabbott’ already exists with this name
I: Duplicate names are not allowed

The right thing to do is what run-parts and a number of other tools with 
.d directories do, which is ignore files whose names contain weird 
characters such as #, ~, etc.  I'm aware of other projects copying logic 
from run-parts, so that might be a good place to look for reasonably 
well-tested logic for this purpose.


    -Tim Abbott

Bug#510355: config-package-dev: DEB_TRANSFORM_FILES doesn't work with multiple binary packages from one source package

[Tim Abbott]

Package: config-package-dev
Version: 4.8
Severity: important

config-package-dev 4.8's DEB_TRANSFORM_FILES feature doesn't work with 
multiple binary packages built from one source package.


    -Tim Abbott



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

Bug#507191: libm4ri: Should use DEB_AUTO_UPDATE_LIBTOOL = pre

[Tim Abbott]

Thanks for the report.  I'll fix this in my next upload.

    -Tim Abbott

On Fri, 28 Nov 2008, James Westby wrote:


Package: libm4ri
Version: 0.0.20080521-1
Severity: normal
Tags: patch
User: [EMAIL PROTECTED]
Usertags: origin-ubuntu jaunty ubuntu-patch

Hi,

You're package uses DEB_AUTO_UPDATE_LIBTOOL to run libtoolize at build
time. However, it uses a value of "1" which doesn't run libtoolize. The
values that will are "pre" and "post" and your package should use "pre".
Attached is a patch to do this, please consider attaching it.

Thanks,

James





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

Bug#506507: cddlib: Should use DEB_AUTO_UPDATE_LIBTOOL = pre

[Tim Abbott]

I'll make this change on my next upload.

    -Tim Abbott

On Sat, 22 Nov 2008, James Westby wrote:


Source: cddlib
Version: 094b.dfsg-3
Severity: normal
User: [EMAIL PROTECTED]
Usertags: origin-ubuntu jaunty

Hi,

Your package currently uses "DEB_AUTO_UPDATE_LIBTOOL = 1", but
cdbs only triggers libtool if the value is "pre" or "post". This
caused a build failure on Ubuntu:

 
http://launchpadlibrarian.net/19657107/buildlog_ubuntu-jaunty-i386.cddlib_094b.dfsg-3_FAILEDTOBUILD.txt.gz

I fixed this by changing "1" to "pre".

Please consider making the change.

Thanks,

James










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

Bug#505142: FTBFS with GCC 4.4: missing #include

[Tim Abbott]

Thanks for the patch.  I'll apply it in my next upload, and am submitting 
it upstream as well.


By the way, it'd be nice if you could generate your patches so that they 
were based at the root of the package (quilt edit makes this no more 
difficult than making the changes directly).  Obviously not a big deal, 
but as I imagine you're going to be submitting a lot of these bug reports, 
making it convenient for maintainers to take the patches is probably 
worthwhile.


Thanks again,

-Tim Abbott

On Sun, 9 Nov 2008, Martin Michlmayr wrote:


Package: ntl
Version: 5.4.2-2
User: [EMAIL PROTECTED]
Usertags: ftbfs-gcc-4.4
Tags: patch

Your package fails to build with the upcoming GCC 4.4.  Version 4.4
has not been released yet but I'm building with a snapshot in order
to find errors and give people an advance warning.

GCC 4.4 cleaned up some more C++ headers.  You always have to #include
headers directly and cannot rely for things to be included indirectly.

You can reproduce this problem with gcc-snapshot from unstable.


Automatic build of ntl_5.4.2-2 on em64t by sbuild/amd64 0.53

...

g++ -I../include -I.  -g -O2 -g -Wall -O2  -c ZZ_pX.c
g++ -I../include -I.  -g -O2 -g -Wall -O2  -c ZZ_pX1.c
ZZ_pX1.c: In function 'std::istream& NTL::operator>>(std::istream&, 
NTL::vec_ZZ_pX&)':
ZZ_pX1.c:902: error: 'EOF' was not declared in this scope
ZZ_pX1.c:902: error: 'EOF' was not declared in this scope
make[3]: *** [ZZ_pX1.o] Error 1
make[3]: Leaving directory `/build/tbm/ntl-5.4.2/src/small/src'


--- vec_GF2.c~  2008-11-09 19:40:06.0 +
+++ vec_GF2.c   2008-11-09 19:40:11.0 +
@@ -3,6 +3,8 @@

#include 

+#include 
+
NTL_START_IMPL

void vec_GF2::SetLength(long n)
--- tools.c~2008-11-09 19:40:14.0 +
+++ tools.c 2008-11-09 19:40:19.0 +
@@ -1,6 +1,7 @@

#include 

+#include 
#include 

#include 
--- WordVector.c~   2008-11-09 19:40:28.0 +
+++ WordVector.c2008-11-09 19:40:34.0 +
@@ -3,6 +3,8 @@

#include 

+#include 
+
NTL_START_IMPL


--- GF2X.c~ 2008-11-09 19:40:39.0 +
+++ GF2X.c  2008-11-09 19:40:45.0 +
@@ -4,6 +4,8 @@

#include 

+#include 
+
NTL_START_IMPL

long GF2X::HexOutput = 0;

--
Martin Michlmayr
http://www.cyrius.com/







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

Bug#499877: flint - FTBFS: error: '__gmpn_udiv_w_sdiv' was not declared in this scope

[Tim Abbott]

Because flint is linking against gmp, the short-term solution is probably 
to just add a prototype for __gmpn_udiv_w_sdiv in the relevant section of 
longlong.h.  The flint developers plan to implement a better solution when 
they switch from gmp to mpir (a fork of gmp currently under development).


I've implemented the short-term fix in 
<http://web.mit.edu/tabbott/Public/flint_1.011-2.dsc>.


I don't have access to an s390 machine to do a test build on.  I'd 
appreciate it if you would do a build on on s390 to see if this is 
sufficient to fix the problem.


-Tim Abbott

On Tue, 23 Sep 2008, Tim Abbott wrote:

It does link the library; the code being copied is an internal header that 
defines macros giving a platform-independent interface to efficient 
implementations of various arithmetic operations.


I think the impression that the flint developers think that the definitions 
in longlong.h should be part of the public GMP API.


-Tim Abbott

On Tue, 23 Sep 2008, Bastian Blank wrote:


On Tue, Sep 23, 2008 at 11:58:39AM -0400, Tim Abbott wrote:

I've traced the problem to flint having copied longlong.h from GMP
without also copying udiv_w_sdiv.c from GMP, which defines (after some
macro magic) __gmpn_udiv_w_sdiv.


Why does it copy code from GMP and not link the lib?

Bastian

--
Witch!  Witch!  They'll burn ya!
-- Hag, "Tomorrow is Yesterday", stardate unknown











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

Bug#499877: flint - FTBFS: error: '__gmpn_udiv_w_sdiv' was not declared in this scope

[Tim Abbott]

It does link the library; the code being copied is an internal header that 
defines macros giving a platform-independent interface to efficient 
implementations of various arithmetic operations.


I think the impression that the flint developers think that the 
definitions in longlong.h should be part of the public GMP API.


-Tim Abbott

On Tue, 23 Sep 2008, Bastian Blank wrote:


On Tue, Sep 23, 2008 at 11:58:39AM -0400, Tim Abbott wrote:

I've traced the problem to flint having copied longlong.h from GMP
without also copying udiv_w_sdiv.c from GMP, which defines (after some
macro magic) __gmpn_udiv_w_sdiv.


Why does it copy code from GMP and not link the lib?

Bastian

--
Witch!  Witch!  They'll burn ya!
-- Hag, "Tomorrow is Yesterday", stardate unknown







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

Bug#499877: flint - FTBFS: error: '__gmpn_udiv_w_sdiv' was not declared in this scope

[Tim Abbott]

I've traced the problem to flint having copied longlong.h from GMP without 
also copying udiv_w_sdiv.c from GMP, which defines (after some macro 
magic) __gmpn_udiv_w_sdiv.


    -Tim Abbott

On Tue, 23 Sep 2008, Bastian Blank wrote:


Package: flint
Version: 1.011-1
Severity: serious

There was an error while trying to autobuild your package:


Automatic build of flint_1.011-1 on debian-31.osdl.marist.edu by sbuild/s390 98

[...]

g++ -fPIC  -g -O2 -g -Wall -O2 -funroll-loops -I/usr/include -I/usr/include/NTL 
-c NTL-interface.cpp -o NTL-interface.o
In file included from fmpz.h:38,
 from NTL-interface.cpp:38:
long_extras.h: In function 'int z_issquare(long int)':
long_extras.h:220: warning: comparison between signed and unsigned integer 
expressions
In file included from NTL-interface.cpp:38:
fmpz.h: In function 'int fmpz_equal(mp_limb_t*, mp_limb_t*)':
fmpz.h:151: warning: comparison between signed and unsigned integer expressions
In file included from fmpz_poly.h:38,
 from NTL-interface.cpp:39:
mpn_extras.h: In function 'mp_limb_t F_mpn_precompute_inverse(mp_limb_t)':
mpn_extras.h:46: error: '__gmpn_udiv_w_sdiv' was not declared in this scope
mpn_extras.h: In function 'void F_mpn_copy_forward(mp_limb_t*, const 
mp_limb_t*, long unsigned int)':
mpn_extras.h:104: warning: comparison between signed and unsigned integer 
expressions
In file included from NTL-interface.cpp:39:
fmpz_poly.h: In function 'void _fmpz_poly_set_coeff_mpz(fmpz_poly_struct*, long 
unsigned int, const __mpz_struct*)':
fmpz_poly.h:396: warning: comparison between signed and unsigned integer 
expressions
fmpz_poly.h: In function 'void fmpz_poly_set_coeff_fmpz(fmpz_poly_struct*, long 
unsigned int, mp_limb_t*)':
fmpz_poly.h:799: warning: comparison between signed and unsigned integer 
expressions
fmpz_poly.h: In function 'void fmpz_poly_set_coeff(fmpz_poly_struct*, long 
unsigned int, const mp_limb_t*, long int, long unsigned int)':
fmpz_poly.h:828: warning: comparison between signed and unsigned integer 
expressions
fmpz_poly.h: In function 'void fmpz_poly_set_coeff_si(fmpz_poly_struct*, long 
unsigned int, long int)':
fmpz_poly.h:845: warning: comparison between signed and unsigned integer 
expressions
fmpz_poly.h: In function 'void fmpz_poly_set_coeff_ui(fmpz_poly_struct*, long 
unsigned int, long unsigned int)':
fmpz_poly.h:862: warning: comparison between signed and unsigned integer 
expressions
make[1]: *** [NTL-interface.o] Error 1
make[1]: Leaving directory `/build/buildd/flint-1.011'
make: *** [debian/stamp-makefile-build] Error 2
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
**
Build finished at 20080921-1456
FAILED [dpkg-buildpackage died]








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

Bug#464959: gmp-ecm: Please build library package

[Tim Abbott]

Package: gmp-ecm
Version: 6.1.2-1
Severity: wishlist

I'm packaging SAGE for Debian (currently, in a separate apt repository as 
a staging area before submitting it and its N dependencies for inclusion 
in Debian) and it depends on gmp-ecm; it would thus be useful if the 
gmp-ecm package included the library version of the package.  Thanks,


    -Tim Abbott



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

Bug#464783: qd: please package new upstream

[Tim Abbott]

Package: qd
Severity: wishlist

It would be nice to have a newer version of qd available in lenny; the 
current seems to be 2.3.  At the moment, there's no version of qd in lenny 
at all (it seems it is currently blocked by bug #430295)


    -Tim Abbott



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

Bug#464479: base-files: does not include md5sums file

[Tim Abbott]

Package: base-files
Version: 4.0.2
Severity: minor

The base-files package in Lenny does not include md5sums for its 
non-conffiles.


-Tim Abbott



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

Bug#464474: mstmp: In sendmail compatability mode, ignores Resent-* headers

[Tim Abbott]

Package: msmtp
Version: 1.4.13-1
Severity: normal

When in sendmail compatability mode (msmtp -t, where msmtp is reading mail 
from standard input and parsing the headers), msmtp ignores the Resent-*, 
which are supposed to supercede the corresponding non-Resent headers (i.e. 
Resent-To overrides To, etc.).


This causes Pine's "bounce" feature to simply send emails to the listed 
To, rather than the target of the "bounce".


-Tim Abbott



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

Bug#463880: adduser: /etc/adduser.conf not marked as a conffile

[Tim Abbott]

Package: adduser
Version: 3.105

The adduser package fails to mark its configuration file /etc/adduser.conf 
as a conffile.  Oddly, it does mark /etc/deluser.conf as a conffile.


-Tim Abbott



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

Bug#462741: lprng: No longer supports kerberos5 authtype

[Tim Abbott]

On Sun, 27 Jan 2008, Bernhard R. Link wrote:


I think the following patch (which I applied to cvs already) should restore
the functionaly. Given I lack kerberos infrastructure to test it I'd be
eager to hear if it works, too.


It works.  Thanks for the quick turnaround,

    -Tim Abbott





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

Bug#462743: ITP: wmkrb -- a Kerberos ticket tracking dockapp for WindowMaker

[Tim Abbott]

Package: wnpp
Severity: wishlist

The upstream author is Reid Barton <[EMAIL PROTECTED]>.  The upstream 
source is available at <http://numenor.mit.edu/~rwbarton/>.  The license 
is GPL.


My draft packaging for it is available at 
<http://debathena.mit.edu/packages/contrib/wmkrb/>.


    -Tim Abbott



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

Bug#462741: lprng: No longer supports kerberos5 authtype

[Tim Abbott]

Package: lprng
Version: 3.8.A~rc2-1
Tags: patch

In versions of lprng before the kerberos4 authtype was deprecated, 
authtypes of the form "kerberos*" for * different from 4 were handled as 
the standard "kerberos" authtype; below is part of the diff between the 
current Lenny and Sid versions in common/user_auth.c:


 # if defined(MIT_KERBEROS4)
{ "kerberos4", "kerberos", IP_SOCKET_ONLY, Send_krb4_auth, 0,0,0 },
 # endif
-   { "kerberos*", "kerberos", IP_SOCKET_ONLY, 0,   Krb5_send, 0, 
Krb5_receive },
+   { "kerberos", "kerberos", IP_SOCKET_ONLY, 0,   Krb5_send, 0, 
Krb5_receive },
+   { "kerberos5", "kerberos", IP_SOCKET_ONLY, 0,   Krb5_send, 0, 
Krb5_receive },
+   { "k5conn", "kerberos", IP_SOCKET_ONLY, 0,   Krb5_send_nocrypt, 
0, Krb5_receive_nocrypt },
 #endif

{ "test",  "test", 0,  0,   Test_send, 0, 
Test_receive },

This change breals printcap entries that specify authtype "kerberos5", 
which used to work and was a reasonable parallel to the now-deprecated 
authtype "kerberos4".


Attached is a small patch to cause authtype "kerberos5" to restore support 
for the "kerberos5" authtype.


-Tim Abbottdiff -ur lprng-3.8.A~rc2-orig/src/common/user_auth.c 
lprng-3.8.A~rc2/src/common/user_auth.c
--- lprng-3.8.A~rc2-orig/src/common/user_auth.c 2008-01-17 06:16:27.0 
-0500
+++ lprng-3.8.A~rc2/src/common/user_auth.c  2008-01-27 01:01:11.0 
-0500
@@ -1797,6 +1797,7 @@
{ "kerberos4", "kerberos", IP_SOCKET_ONLY, Send_krb4_auth, 0,0,0 },
 # endif
{ "kerberos", "kerberos", IP_SOCKET_ONLY, 0,   Krb5_send, 0, 
Krb5_receive },
+   { "kerberos5", "kerberos", IP_SOCKET_ONLY, 0,   Krb5_send, 0, 
Krb5_receive },
{ "k5conn", "kerberos", IP_SOCKET_ONLY, 0,   Krb5_send_nocrypt, 
0, Krb5_receive_nocrypt },
 #endif
 

Bug#460336: elinks: creates named pipe in $HOME/.elinks

[Tim Abbott]

Package: elinks
Version: 0.11.1-1.2etch1
Severity: normal

elinks attempts to use a named pipe in $ELINKS_CONFDIR, defaulting to 
$HOME/.elinks.  If $HOME is in a networked filesystem not supporting named 
pipes, then when elinks is started, it prints


ERROR at ../../../src/main/interlink.c:329: The call to bind() failed: 1 
(Operation not permitted)

and delays for a second 5 times.

Ideally, elinks should place its named pipe in /tmp (as many other 
programs do), rather than in its configuration directory.


-Tim Abbott



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

Bug#448459: /etc/init.d/zhm

[Tim Abbott]

Package: zephyr-clients
Version: 2.1.20070719.SNAPSHOT-1
Tags: patch

The zephyr-clients init script /etc/init.d/zhm calls start-stop-daemon 
using --exec when stopping zhm, which fails to actually stop the zhm 
process.


-Tim Abbottdiff -ur zephyr-2.1.20070719.SNAPSHOT.orig/debian/zephyr-clients.init zephyr-2.1.20070719.SNAPSHOT/debian/zephyr-clients.init
--- zephyr-2.1.20070719.SNAPSHOT.orig/debian/zephyr-clients.init	2007-10-29 08:48:06.0 +
+++ zephyr-2.1.20070719.SNAPSHOT/debian/zephyr-clients.init	2007-10-29 08:49:11.398043033 +
@@ -35,7 +35,7 @@
   stop)
 	echo -n "Stopping $DESC: "
 	start-stop-daemon --oknodo --stop --quiet --pidfile /var/run/$NAME.pid \
-		--exec $DAEMON
+		--name $NAME
 	echo "$NAME."
 	;;
   restart|force-reload)
@@ -46,7 +46,7 @@
 	#
 	echo -n "Restarting $DESC: "
 	start-stop-daemon --oknodo --stop --retry 5 --quiet --pidfile \
-		/var/run/$NAME.pid --exec $DAEMON
+		/var/run/$NAME.pid --name $NAME
 	start-stop-daemon --start --quiet --pidfile \
 		/var/run/$NAME.pid --exec $DAEMON -- -N $zhm_args
 	echo "$NAME."

Bug#439058: GSSAPICleanupCredentials doesn't work for root

[Tim Abbott]

Package: openssh-server
Version: 4.3p2-9
Severity: important

GSSAPICleanupCredentials is not deleting Kerberos tickets created if one 
forwards credentials (using GSSAPIDelegate Credentials) to root.


Further investigation reveals that the GSSAPI client store's filename 
field is being overwritten with 0 sometime between being set in 
gss-serv-krb5.c and being checked during cleanup in gss-serv.c.


The behavior of overwriting data structures with 0s seems very similar to 
a bug I reported a year ago in ssh-krb5 3.8.1 on sarge:


#372680: ssh-krb5: pam_close_session is not being called

While #372680 does not seem to be a general problem in ssh 4.3p2-9, I do 
notice that pam_close_session is also not being called for root in 
4.3p2-9.


    -Tim Abbott


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

Bug#376774: coreutils: groups does not work with OpenAFS PAGs

[Tim Abbott]

Package: coreutils
Version: 5.2.1-2
Severity: normal
Tags: patch

When using OpenAFS PAGs, which store information as two fake gids, the
groups program complains that it cannot find names for those ids, and
causes groups to return an error.  

[EMAIL PROTECTED]:~$ groups
users id: cannot find name for group ID 34182
34182 id: cannot find name for group ID 45415
45415 dialout cdrom floppy audio video fuse

It seems that these error messages are useless since the information
that it could not find names for those groups is already clear from
them being displayed as numbers.  Furthermore, the error message is
confusing, and the nonzero exit status is problematic for things like
pscp from Windows.

Below is a patch to id.c to remove this behaviour.  


--- coreutils-5.2.1/src/id.c.orig   2004-01-21 17:27:02.0 -0500
+++ coreutils-5.2.1/src/id.c2006-07-04 18:27:05.0 -0400
@@ -230,11 +230,6 @@
   if (use_name)
 {
   grp = getgrgid (gid);
-  if (grp == NULL)
-   {
- error (0, 0, _("cannot find name for group ID %u"), gid);
- problems = 1;
-   }
 }
 
   if (grp == NULL)


-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.16.11-grsec
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages coreutils depends on:
ii  libacl1   2.2.23-1   Access control list shared library
ii  libc6 2.3.6-7GNU C Library: Shared libraries

-- no debconf information


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

Bug#372680: ssh-krb5: pam_close_session is not being called

[Tim Abbott]

Package: ssh-krb5
Version: 3.8.1p1-10
Severity: important


The pam close session modules are not being called, despite code in
auth-pam.c that seems like it should call them.  After I added some
print statements to the code (having made no other changes), the
variable sshpam_session_open appears a small number of times in the
code:

% grep -R sshpam_session_open .
auth-pam.c:static int sshpam_session_open = 0;
auth-pam.c: logit("Variable is before check %d", sshpam_session_open);
auth-pam.c: if (sshpam_session_open) {
(the pam_close_session call is inside this if statement)
auth-pam.c: sshpam_session_open = 0;
auth-pam.c: logit("Variable is before being set %d", sshpam_session_open);
auth-pam.c: sshpam_session_open = 1;
auth-pam.c: logit("Variable is after being set %d", sshpam_session_open);

Running the sshd built from this and then logging in and then out
gives the following output in my auth.log, where the 4-second delay
was the length of my login session:

Jun 10 20:33:21 vinegar-pot sshd[9715]: Variable is before being set 0
Jun 10 20:33:21 vinegar-pot sshd[9715]: Variable is after being set 1
Jun 10 20:33:25 vinegar-pot sshd[23685]: Variable is before check 0

Thus, sshpam_session_open is somehow changing from 1 to 0 between
being set and being checked, causing the close session modules to not
be executed.  


-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.16.11-grsec
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages ssh-krb5 depends on:
ii  adduser   3.63   Add and remove users and groups
ii  debconf [debconf-2.0] 1.4.30.13  Debian configuration management sy
ii  libc6 2.3.6-7GNU C Library: Shared libraries
ii  libpam-runtime0.76-22Runtime support for the PAM librar
ii  libpam0g  0.76-22Pluggable Authentication Modules l
ii  libwrap0  7.6.dbs-8  Wietse Venema's TCP wrappers libra

-- debconf information:
* ssh/privsep_tell:
  ssh/insecure_rshd:
* ssh/privsep_ask: true
  ssh/ssh2_keys_merged:
  ssh/user_environment_tell:
* ssh/forward_warning:
  ssh/insecure_telnetd:
* ssh/new_config: true
* ssh/use_old_init_script: true
* ssh/protocol2_only: true
  ssh/encrypted_host_key_but_no_keygen:
* ssh/run_sshd: true
* ssh/SUID_client: false


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