Bug#1002956: Remote RCE in rabbitmq-server
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
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
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
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
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
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
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
Sounds good to me! -Tim Abbott On Tue, Apr 15, 2014 at 2:12 AM, Tobias Hansen than...@debian.org 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
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 p...@debian.org 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
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
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
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
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?
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: packagename -- RoM; reasons 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
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
On Sat, 7 Aug 2010, William Stein wrote: On Sat, Aug 7, 2010 at 10:49 AM, tabb...@ksplice.com 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
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?
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
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.
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 python-zodb (= 1:3.6.0-3) | Recommends(Version) | Installed ===-+-=== imagemagick | 7:6.6.0.4-2 r-recommended | gap-character-tables| python-gnuplot | python-openssl | Suggests (Version) | Installed ===-+-=== valgrind| 1:3.5.0-3 gdb
Bug#573538: Please remove the sagemath package
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
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 tabb...@mit.edu 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
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?
On Thu, 28 Jan 2010, George N. White III wrote: 2010/1/28 Rogério Brito rbr...@ime.usp.br: Package: sagemath Severity: normal X-Debbugs-CC: tex-l...@tug.org, Dan Drake dr...@kaist.edu Hi, there. Sorry to be late on this. On 01/25/2010 09:52 PM, Robin Fairbairns wrote: Dan Drake dr...@kaist.edu 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
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
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#535357: I sent this upstream
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#530182: I've sent this upstream
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#545608: Bug #545608: intent to NMU polybori
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=14443r2=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#545598: iml: FTBFS: configure.ac:50: error: possibly undefined macro: AC_MSG_ERROR
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#545588: linbox: FTBFS: configure.in:19: error: possibly undefined macro: AM_ACLOCAL_INCLUDE
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#544809: autoconf: bad interaction between AC_CHECK_LIB and AC_SEARCH_LIBS
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 http://web.mit.edu/tabbott/Public/actest.tgz. -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
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
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 tabb...@ksplice.com
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 tabb...@ksplice.com
---
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 100644
index 000..53106e7
--- /dev/null
+++ b/debian/kerneloops-daemon.postinst
@@ -0,0 +1,46 @@
+#!/bin/sh
+# postinst script for kerneloops-daemon
+#
+# see: dh_installdeb(1)
+
+set -e
+
+# summary of how this script can
Bug#476328: Here's a patch to split the package
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
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
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
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 tabb...@ksplice.com
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 tabb...@ksplice.com
---
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/packagename
- $(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#476328: Here's a patch to split the package
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 tabb...@ksplice.com
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 tabb...@ksplice.com
---
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/packagename
- $(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
--
Matthew WilcoxIntel Open Source Technology
Centre
Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't
Bug#537376: python-support: Cannot use modules provided by a package in its postinst script
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
On Thu, 2 Jul 2009, Cyril Brulebois wrote: tag 530478 patch pending thanks Steve M. Robbins s...@debian.org (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
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 cythonnone (no description available) pn gap none (no description available) pn gap-guava none (no description available) pn genus2reduction none (no description available) pn gfan none (no description available) pn gfortran none (no description available) pn gmp-ecm none (no description available) ii ipython 0.9.1-3enhanced interactive Python shell pn lcalc none (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 none (no description available) pn libecm0 none (no description available) pn libflint-1.011none (no description available) pn libfplll0 none (no description available) ii libgcc1 1:4.4.0-5 GCC support library pn libgivaro0none (no description available) ii libgmp3c2 2:4.2.4+dfsg-2 Multiprecision arithmetic library pn libgmpxx4ldbl none (no description available) ii libgsl0ldbl 1.12+dfsg-1GNU Scientific Library (GSL) -- li pn libiml0 none (no description available) ii libjs-jquery 1.3.2-2JavaScript library for dynamic web pn liblinbox0none (no description available) pn libm4ri-0.0.20080521 none (no description available) pn libmpfi0 none (no description available) ii libmpfr1ldbl 2.4.1-1multiple precision floating-point pn libntl-5.4.2 none (no description available) pn libpari2-gmp none (no description available) pn libpolybori-0.5.0-0 none (no description available) pn libqd2c2a none (no description available) ii libreadline5 5.2-4 GNU readline and history libraries pn libsingular-3-0-4-3 none (no description available) pn libsingular-dev none (no description available) ii libstdc++64.4.0-5The GNU Standard C++ Library v3 pn libsymmetrica-2.0 none (no description available) pn libzn-poly-0.8none (no description available) pn maxima-share none (no description available) ii mercurial 1.2-1 scalable distributed version contr pn palp none (no description available) pn pari-extranone (no description available) pn pari-gp none (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 none (no description available) pn python-gd none (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 none (no description available) pn python-networkx none (no description available) ii python-numpy 1:1.2.1-1 Numerical Python adds a fast array ii python-pexpect2.3-1 Python module for automating inter pn python-polybori none (no description available) ii python
Bug#535357: sagemath: migrate from python-processing to python-multiprocessing
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 Abbotttabb...@mit.edu 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#435577: gdebi is supposed to support pre-depends, it is just broken
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 tabb...@ksplice.com 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 tabb...@ksplice.com --- 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]
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#534148: singular: FTBFS on Debian GNU/Hurd [Patch but possibly incomplete]
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#528275: libgivaro-dev: examples won't compile out of tree
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
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
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
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
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
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#523670: sbuild: --help and --version options don't work if not in group sbuild
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: [PATCH] sbuild: Add support for appending a tag at the end of version numbers
Signed-off-by: Tim Abbott tabb...@mit.edu
---
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, sbuild); },
V|version = sub {version_text(sbuild); },
arch=s = sub {
$self-set_conf('ARCH', $_[1]);
@@ -107,6 +107,9 @@ sub parse_options {
binNMU=i = sub {
$self-set_conf('BIN_NMU_VERSION', $_[1]);
},
+ append-to-version=s = sub {
+ $self-set_conf('APPEND_TO_VERSION', $_[1]);
+ },
c|chroot=s = sub {
$self-set_conf('CHROOT', $_[1]);
},
@@ -180,6 +183,13 @@ sub parse_options {
if $self-get_conf('VERBOSE');
},
);
+
+if (defined
Bug#475777: sbuild: Add support for appending a tag to version numbers
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
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#519887: sagemath: dsage doesn't work with python-twisted 8.2.0
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#450703: I think this is actually a bug in gcl
clone 450703 -1 reassign -1 gcl retitle -1 gcl: crash after ctrl-C thanks recipe: (1) start gcl (2) hit ctrl-C and then enter 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#519753: sagemath: unnecessary dependency on libsingular-dev
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#518559: finger: Doesn't work with a non-iterable nsswitch source
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 tabb...@mit.edu
Date: Fri Mar 6 22:30:00 2009 -0500
Add support for non-iterable nsswitch sources.
Signed-off-by: Timothy G Abbott tabb...@mit.edu
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#518565: emacs22: tex-dvi-print-command should not default to lpr -d
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#514785: These bug reports represent the same problem
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#514648: [sagemath] x+x produces EOF: End Of File (EOF) in read_nonblocking().
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#515052:
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:
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:
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: ksplice-create fails to create tarball
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#514522: cddlib: cdbs warning: remove config.{guess,sub}
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#495000: please consider making libatlas-base-dev optional
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#513853: [sagemath] sage segfaults
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#476103: ghmm in Debian
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
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#513837: sagemath: contains embedded jsmath package
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#513838: sagemath: contains embedded cython
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#513853: [sagemath] the i386 sage segfaults
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 | 0.98~beta.dfsg-1 python-rpy| 1.0.3-6 gap-guava
Bug#476103: ghmm in Debian
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#513873: sagemath: FTBFS on amd64
Hi Ben, It appears that the package did build on amd64 on the Debian buildd system: http://buildd.debian.org/build.php?pkg=sagemathver=3.0.5dfsg-1arch=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 to manipulate and study more ii python-numpy
Bug#513819: Package FTBFS on mips
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#512636: please fix Gürkan's name in the control file
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
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
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
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
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
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 NTL/new.h +#include cstdio + 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 NTL/tools.h +#include cstdio #include ctype.h #include NTL/new.h --- WordVector.c~ 2008-11-09 19:40:28.0 + +++ WordVector.c2008-11-09 19:40:34.0 + @@ -3,6 +3,8 @@ #include NTL/new.h +#include cstdio + 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 NTL/new.h +#include cstdio + 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
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#499877: flint - FTBFS: error: '__gmpn_udiv_w_sdiv' was not declared in this scope
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
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#464959: gmp-ecm: Please build library package
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
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#464474: mstmp: In sendmail compatability mode, ignores Resent-* headers
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#464479: base-files: does not include md5sums file
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#463880: adduser: /etc/adduser.conf not marked as a conffile
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
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#462741: lprng: No longer supports kerberos5 authtype
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#462743: ITP: wmkrb -- a Kerberos ticket tracking dockapp for WindowMaker
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#460336: elinks: creates named pipe in $HOME/.elinks
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
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
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
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
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]
