Bug#828231: alpine: FTBFS with openssl 1.1.0
Hi! Thanks! I'll schedule some time to look into this on Tuesday this week; hopefully that will work out, and I'll keep this bug up to date with my progress.
Bug#744097: stdeb: pypi-install broken due to python.org URL change
Package: python-stdeb Version: 0.6.0+20100620-2 Severity: grave File: stdeb Currently, due to a website reorganization within python.org, the find_tar_gz() function crashes with: File /usr/lib/python2.7/xmlrpclib.py, line 1312, in single_request response.msg, xmlrpclib.ProtocolError: https://github.com/astraw/stdeb/pull/72 (patch there) addresses the problem by using the canonical URL of PyPI. -- System Information: Debian Release: squeeze/sid APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores) 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 python-stdeb depends on: ii debhelper 9.20120419~bpo60+1 helper programs for debian/rules ii python2.7.5-5interactive high-level object-orie ii python-setuptools 0.6.49-2 Python Distutils Enhancements (set ii python2.6 2.6.6-8+b1 An interactive high-level object-o ii python2.7 2.7.5-8Interactive high-level object-orie Versions of packages python-stdeb recommends: ii apt-file 2.5.1 search for files within Debian pac ii dpkg-dev 1.16.10Debian package development tools ii python-all2.7.5-5package depending on all supported Versions of packages python-stdeb suggests: pn python-all-devnone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687398: Now FTBFS...?
I just tried to build my debdiff and do an NMU, and it ends with this message: Finished tests in 0.001844s, 2711.3306 tests/s, 15725.7175 assertions/s. 5 tests, 29 assertions, 0 failures, 0 errors, 0 skips make[1]: Leaving directory `/tmp/buildd/rhash-1.2.9/bindings' /usr/bin/make -C bindings build LIBRHASH_INC=-I/tmp/buildd/rhash-1.2.9/debian/tmp LIBRHASH_LD=-Wl,--as-needed -L/tmp/buildd/rhash-1.2.9/debian/tmp BINDINGS=mono make[1]: Entering directory `/tmp/buildd/rhash-1.2.9/bindings' make -C mono make[2]: Entering directory `/tmp/buildd/rhash-1.2.9/bindings/mono' gmcs -target:library -define:UNIX -out:RHash.dll -debug -keyfile:RHash.snk AssemblyInfo.cs Bindings.cs Hasher.cs HashType.cs make[2]: gmcs: Command not found make[2]: *** [RHash.dll] Error 127 make[2]: Leaving directory `/tmp/buildd/rhash-1.2.9/bindings/mono' make[1]: *** [build-mono] Error 2 make[1]: Leaving directory `/tmp/buildd/rhash-1.2.9/bindings' make: *** [build-indep] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 E: Failed autobuilding of package I: unmounting dev/pts filesystem I: unmounting proc filesystem I: cleaning the build env I: removing directory /var/cache/pbuilder/build//16252 and its subdirectories ...why is gmcs not findable in my pbuilder chroot? I checked, and mono-gmcs is still a dependency. Not sure. Heading to bed for now. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687398: More information on how to reproduce the `dlopen' issue
On Wed, 24 Oct 2012, gregor herrmann wrote: The debdiff arrived some minutes later, but I don't see an upload. What's the status? Oh, snap, I neglected to upload the actual NMU. I will do that tonight, unless someone (gregoa?) beats me to it. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631758: Why I consider this 'serious'
Hi Holger and all, This bug makes alpine in the package maintainer's... opinion, unsuitable for release, as per http://www.debian.org/Bugs/Developer#severities (I will say I'm open to discussion on the topic.) The first thing that every new alpine user will see is an enthusiastic message which, upon execution, leads to an error in their inbox in short order. That's just absurd. I'm working on untangling my changes in VCS from the NMU that recently took place, and will then bring this up to the release team. Other thoughts welcome! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687398: More information on how to reproduce the `dlopen' issue
wRAR, thank you for your excellent detective work. Here's how you reproduce this build issue without even enabling parallel build. (Sadly I can't actually reproduce the brokenness from within dpkg-buildpackage by setting parallel build options; maybe my machine doesn't have as many cores as the EC2 machines. But the fix described below does clarify the build process which should take care of the problem.) $ (rhash-1.2.9) rm rhash $ (rhash-1.2.9) make rhash gcc calc_sums.o hash_print.o common_func.o hash_update.o file_mask.o file_set.o find_file.o hash_check.o output.o parse_cmdline.o rhash_main.o win_utils.o -o rhash -Llibrhash -lrhash librhash/librhash.a(plug_openssl.o): In function `load_openssl_runtime': /tmp/rhash-1.2.9/librhash/plug_openssl.c:141: undefined reference to `dlopen' /tmp/rhash-1.2.9/librhash/plug_openssl.c:148: undefined reference to `dlsym' /tmp/rhash-1.2.9/librhash/plug_openssl.c:148: undefined reference to `dlsym' /tmp/rhash-1.2.9/librhash/plug_openssl.c:148: undefined reference to `dlsym' /tmp/rhash-1.2.9/librhash/plug_openssl.c:149: undefined reference to `dlsym' /tmp/rhash-1.2.9/librhash/plug_openssl.c:149: undefined reference to `dlsym' librhash/librhash.a(plug_openssl.o):/tmp/rhash-1.2.9/librhash/plug_openssl.c:149: more undefined references to `dlsym' follow librhash/librhash.a(plug_openssl.o): In function `load_openssl_runtime': /tmp/rhash-1.2.9/librhash/plug_openssl.c:142: undefined reference to `dlopen' /tmp/rhash-1.2.9/librhash/plug_openssl.c:143: undefined reference to `dlopen' collect2: error: ld returned 1 exit status make: *** [rhash] Error 1 When SHARED_TRG is just 'rhash', then the build gets confused in parallel mode, I suppose. In principle, it's within its right to be confused; you're asking it to do 'make rhash', after all. So what I'm going to do is: * Adjust debian/rules to *not* specify SHARED_TRG * Right after rhash_shared is built, use 'mv' to rename it to 'rhash' That's all it should take to fix this, I believe. I'll prepare a 1-day delayed NMU for that. Maintainer, please feel free to remove it; I don't mean to step on your toes, just to move this bug along. I'll attach the debdiff here before doing the upload. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687398: (no subject)
debdiff attached, as promised!diff -Nru rhash-1.2.9/debian/changelog rhash-1.2.9/debian/changelog --- rhash-1.2.9/debian/changelog2012-06-17 05:11:36.0 -0700 +++ rhash-1.2.9/debian/changelog2012-09-30 15:18:59.0 -0700 @@ -1,3 +1,14 @@ +rhash (1.2.9-7.1) unstable; urgency=medium + + * Non-maintainer upload. + * Slight simplification of debian/rules that aims to fix +parallel builds. In particular, we used to build a dynamically +linked rhash binary as 'rhash'; now, we build it as 'rhash-shared' +like the default of the upstream build system, and later rename it +to 'rhash' as needed. (Closes: #687398) + + -- Asheesh Laroia ashe...@asheesh.org Sun, 30 Sep 2012 15:16:28 -0700 + rhash (1.2.9-7) unstable; urgency=low * Fixed dependencies of ruby-rhash diff -Nru rhash-1.2.9/debian/rules rhash-1.2.9/debian/rules --- rhash-1.2.9/debian/rules2012-06-15 21:54:00.0 -0700 +++ rhash-1.2.9/debian/rules2012-09-30 15:20:21.0 -0700 @@ -63,7 +63,10 @@ build-rhash: # Compile static/shared libraries and the program. +$(MAKE) lib-static lib-shared rhash-shared CFLAGS=$(CFLAGS) LDFLAGS=$(LDFLAGS) \ - LIBCFLAGS=$(LIBCFLAGS) LIBLDFLAGS=$(LIBLDFLAGS) SHARED_TRG=rhash + LIBCFLAGS=$(LIBCFLAGS) LIBLDFLAGS=$(LIBLDFLAGS) + # Move the rhash_shared binary to be called rhash, so that the tests use that + # (and also since that is the binary name we will install into /usr/bin) + mv rhash_shared rhash # Compile language bindings. mkdir -p $(DESTDIR) ln -fs $(CURDIR)/librhash $(DESTDIR)/rhash ln -fs $(CURDIR)/librhash/librhash.so.0 $(DESTDIR)/ ln -fs $(DESTDIR)/librhash.so.0 $(DESTDIR)/librhash.so
Bug#687931: JPEG 2000, signed ints, and C
I can reproduce the crash. Note that openjpeg-tools does not crash on this file. Demonstration: Run these: sudo apt-get install openjpeg-tools wget http://bugs.debian.org/cgi-bin/bugreport.cgi\?msg\=5\;filename\=jas_image_readcmpt2_SIGABRT.j2k\;att\=1\;bug\=687931 -O bugreport.j2k Then when you run this command: j2k_to_image -i bugreport.j2k -o rofl.tif You get this output: [INFO] tile 1 of 1 [INFO] - tiers-1 took 0.076004 s [INFO] - dwt took 0.004001 s [INFO] - tile decoded in 0.080005 s Generated Outfile rofl.tif rofl.tif is all black, 888x458 pixels. (Roland, is that what you were expecting?) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666176: Suggesting disabling tracker-miner-evolution
Hey all, Given the lack of movement by upstream on this issue, and the fact that they acknowledge the bug, and that https://bugzilla.redhat.com/show_bug.cgi?id=733523 has been open for about a year with no evidence of resolution coming soon, I would suggest simply not building the (known-bad) tracker-miner-evolution binary package. One day, when that code works again, we can enable it. (Alternately, a testing-proposed-updates version of src:tracker could disable the binary package, and then sid could keep it enabled awaiting the day that it works again.) I would suggest just disabling it in sid, though. Michael, is that a resolution you'd be willing to accept? Thanks! -- Asheesh. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657046: alpine: diff for NMU version 2.02+dfsg-1.1
On Sat, 8 Sep 2012, Ulrich Dangel wrote: Dear maintainer, I've prepared an NMU for alpine (versioned as 2.02+dfsg-1.1). The diff is attached to this message. Hi Ulrich, and Jonathan, Thank you for improving this package, and sorry I didn't do this yet! I will be working on requesting a freeze exception for this shortly. I'm honored that you have improved Debian, and sorry if my own latency has delayed that. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657046: (no subject)
Thanks for this bug report! I can confirm the issue, and I believe this is very important. Upstream has a patch that fixes it, but we should try to get the updated version into the upcoming release of Debian. I will work on that. Thank you again for the report. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669451: liblicense: FTBFS: gsf.c:105:1: error: conflicting types for 'clone'
Thanks for reporting this bug! Will handle shortly.
Bug#641479: Ping: alpine: Contains non-free code
On Sat, 3 Mar 2012, Edward Allcutt wrote: This is RC and appears to need a maintainer upload with a repacked upstream tarball, regardless of whether upstream will accept patches. Are any of the maintainers planning to handle this soon? You're right that in the near term, a fresh upload is required. I will work on that soon. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655004: liblicense: broken binary-indep target
I ACK this bug. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655006: python-liblicense: doesn't depend on python
I ACK this bug. Thanks for filing it! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653238: alpine vulnerable to CVE-2008-5514
Thanks for reporting this. I will investigate shortly and work with the appropriate security teams to ship an update as needed. -- Please excuse my brevity. Jonathan Sailor jsai...@cs.brown.edu wrote: Package: alpine Version: 2.00+dfsg-6 Severity: grave Tags: security Justification: user security hole The alpine package does not include a fix for CVE-2008-5514. Vulnerable: lenny lenny-backports squeeze Fixed in upstream: wheezy sid The patch is available at [1]. Note since that version is written for uw-imap, the path to rfc822.c is imap/src/c-client/rfc822.c. [1] http://people.debian.org/~nion/nmu-diff/uw-imap-2007b~dfsg-1_2007b~dfsg-1.1.patch ~jon. -- System Information: Debian Release: 6.0.3 APT prefers stable APT policy: (750, 'stable'), (70, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-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 alpine depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libgssapi-krb5-2 1.8.3+dfsg-4squeeze2 MIT Kerberos runtime libraries - k ii libkrb5-3 1.8.3+dfsg-4squeeze2 MIT Kerberos runtime libraries ii libldap-2.4-2 2.4.23-7.2 OpenLDAP libraries ii libncurses5 5.7+20100313-5 shared libraries for terminal hand ii libpam0g 1.1.1-6.1+squeeze1 Pluggable Authentication Modules l ii libssl0.9.8 0.9.8o-4squeeze4 SSL shared libraries alpine recommends no packages. Versions of packages alpine suggests: ii aspell 0.60.6-4 GNU Aspell spell-checker ii postfix [mail-transport 2.7.1-1+squeeze1 High-performance mail transport ag -- debconf-show failed
Bug#643349: alpine: FTBFS: flocklnx.c:60:7: error: format not a string literal and no format arguments [-Werror=format-security]
Thanks for filing this bug. I will take a look and see what the best fix is. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625177: Uploaded to DELAYED/5
On Mon, 22 Aug 2011, Sven Mueller wrote: On Mon, August 22, 2011 3:25 am, Asheesh Laroia wrote: Tag: fixed I uploaded this patched package to DELAYED/5! Maintainer, please feel free to beat the upload if you like. I currently don't have time and also (more importantly) no access to my build machine including my gpg key. Patch looks good to me, too. Feel free to upload directly (non-delayed). Cool, glad to hear it. For now I'll stick to DELAYED since there's no hurry. -- Asheesh. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565000: The patch looks good, but we should also make sure the code hunk is upstream
Tags: pending I'll upload this to a DELAYED queue shortly as it is a release-critical bug. Thanks for the fix! I can't find an upstream bug tracking system, but we should make sure to share this. It's interesting that you made a real code fix because -Werror found the problem. Goes to show how useful -Werror is. -- Asheesh. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565000: Uploaded to DELAYED/7
Tag: fixed I've tested it, and uploaded this fix to DELAYED/7. The new upstream release also probably fixes this, so if the maintainers here want to just upload a new upstream release that'd be neat. (-: Ciao for now, -- Asheesh. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625177: Feedback on your patch
Tag: patch Hi Noah, Your patch looks good. It's customary to use plain text email, rather than HTML, and also to add a tag to the bug indicating that there is a patch. http://www.debian.org/Bugs/Developer#tags explains about tags. I'm testing now, and will upload to DELAYED/1 if it passes muster. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625177: Uploaded to DELAYED/5
Tag: fixed I uploaded this patched package to DELAYED/5! Maintainer, please feel free to beat the upload if you like. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590147: Repost here test case for akregator
All I really did was rephrase the akregator issue in terms of the upstream dump command. If you look at the upstream tarball for metakit, it builds a binary (command) called dump. If you run it against one of the metakit database files from http://www.file-upload.net/download-2910539/Archive_old.tar.gz.html , you will find that it segfaults. -- Asheesh. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591193: Replacing the bundled .swf files with source-available ones
Hi! Pardon the late reply. More comments inline: On Wed, 17 Nov 2010, Cameron Simpson wrote: On 15Nov2010 20:52, Asheesh Laroia paulprot...@debian.org wrote: | There's a bug filed in Debian against adzapper because the SWF files | in the source tarball you ship don't have source code available. I'm | emailing you to explain the problem in further detail, and to | explain to you that we have a solution. | | Take a look at | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591193 , in | particular the comment toward the top by Gerfried Fuchs (Rhonda) | that explains what it means to have source for SWF files. | | Do you happen to have the .FLA or .AS files that were used to | generate the SWF files you have in the adzapper package? Alas, no. They were donated. I could find the author. I think... If you could, then it'd be cool to get the original files' source. If not (see below)... | It's actually quite okay if not -- the extraordinary Chris Butler | submitted a patch to the adzapper package (toward the bottom of the | discussion) that uses a Perl library to generate the SWF files. So | if you want, you can use that recipe to regenerate the SWF files you | ship in your tarball. | | The reason I bring all this up is that since Debian is committed to | only shipping software compliant with the Debian Free Software | Guidelines, it's considered a release-critical bug if we package and | distribute things for which we do not have source code. So I wonder: | | Is this something where you'd be willing to do a new release that | uses SWF files generated by Chris Butler's code? Absolutely. As long as they closely resemble what's there now it's all good. It seems that Debian has packaged a version already that uses Chris Butler's code. (Further discussioh sits at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591193 ) | If you're willing to do that soon, then Debian will likely ship that | version in squeeze, the upcoming release. If not, then Debian will | likely carry a patch to use Chris's SWF files instead of the ones | that you distribute in the tarball. | | Hope you're well, and thanks for making and sharing adzapper! Sahll I grab his patch from the bug and update my sources? I think that would be great. BTW, how are you staying up to date with this? I ask because SourceForge broke my rsync-to-adzapper.sf.net and I haven't yet found a way to update that page that doesn't involve a manual password entry for the ssh:-( In a pinch, you could try using 'expect' to automate typing the password, but that's a pretty sad situatiohn. In consequence the web page is somewhat out of date and I need to fix that. I can punt you the latest zapper by hand if you want it, also. That'd be useful, but I'm not the primary maintainer of adzapper. You should get in touch with that person, but if that doesn't work, I can step in as a last resort. (-: I think that covers everything. Thanks for replying quickly! -- Asheesh. -- Lay on, MacDuff, and curs'd be him who first cries, Hold, enough!. -- Shakespeare -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584653: Ghostscript 9.0 does not seem to have the problem
On Tue, 16 Nov 2010, Jonas Smedegaard wrote: Version: 9.00~dfsg-1 On Mon, Nov 15, 2010 at 11:38:30PM -0500, Asheesh Laroia wrote: I used the doh recipe to reproduce the bug on sid. That works fine. I just installed ghostscript 9.0 from Jonas's repositories. That recipe no longer reproduces the bug. This is great news. Thanks a lot for your help testing this! For completeness sake, could you please tell on which version of Debian (squeeze, sid) you tested this? sid, for what it's worth! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601030: Fixing the RC bug by requesting a freeze exception
On Tue, 16 Nov 2010, Jari Aalto wrote: 2010-11-16 05:38 Asheesh Laroia ashe...@asheesh.org: Hello Jari! I noticed this bug in the RC bugs list. I also notice that it's fixed in sid. Are you going to request a freeze exception so that the fixed package can get into sid? Let me (and the bug) know! If you want to, but aren't sure how, I can help you there, too. The release team seems busy; the offer was turned down. http://lists.debian.org/debian-release/2010/11/msg00726.html Jari It seems like they object to the packaging changes -- the change to debhelper 8. That's why Julien Cristau quoted that part. What if you re-do the changes without the parts Julien quoted? (Maybe ask the release team first, to avoid you doing a lot of work and then them saying no.) -- Asheesh. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591193: Replacing the bundled .swf files with source-available ones
Hello Cameron, There's a bug filed in Debian against adzapper because the SWF files in the source tarball you ship don't have source code available. I'm emailing you to explain the problem in further detail, and to explain to you that we have a solution. Take a look at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591193 , in particular the comment toward the top by Gerfried Fuchs (Rhonda) that explains what it means to have source for SWF files. Do you happen to have the .FLA or .AS files that were used to generate the SWF files you have in the adzapper package? It's actually quite okay if not -- the extraordinary Chris Butler submitted a patch to the adzapper package (toward the bottom of the discussion) that uses a Perl library to generate the SWF files. So if you want, you can use that recipe to regenerate the SWF files you ship in your tarball. The reason I bring all this up is that since Debian is committed to only shipping software compliant with the Debian Free Software Guidelines, it's considered a release-critical bug if we package and distribute things for which we do not have source code. So I wonder: Is this something where you'd be willing to do a new release that uses SWF files generated by Chris Butler's code? If you're willing to do that soon, then Debian will likely ship that version in squeeze, the upcoming release. If not, then Debian will likely carry a patch to use Chris's SWF files instead of the ones that you distribute in the tarball. Hope you're well, and thanks for making and sharing adzapper! -- Asheesh. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593700: The package has a generic C version of this function
Take a look at line 35 of source/snd_qf/snd_mix.c. There is (what appears to be) a portable C version of the S_WriteLinearBlastStereo16 function. Now to take a look at what guides the choices at compile time -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602250: On what is enough to be considered a relicensing
Hi Christian, It seems that Geoff thinks that an MIT license would be okay to apply to qtobject. But he didn't quite so far as to say it. Here is what I suggest: Ask him to email the bug report saying: I am Geoff Stearns, the author of qtobject, and I permit its use under the MIT License. And then ask him to write a copy of the MIT license into that email (you can grab a copy from http://www.opensource.org/licenses/mit-license.php ). I think that an email submitted to a Debian bug should count as adequate for licensing matters. I am not an ftpmaster, but that is my pretty firm opinion. Can you ask for that? (A change on the web page is good, too, but if that's too much trouble, an email would be fine, I think.) -- Asheesh. -- You will contract a rare disease. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601161: Some links, and some thoughts
Here are some thoughts about synce-serial: The package is pretty out of date with regard to upstream. Perhaps this is because the version in Debian works well enough. http://www.synce.org/moin/ ppp in GNU/kFree BSD should be a possible thing, but this package probably needs testing with it. It looks like the FreeBSD-brand ppp is what should be used. http://www.mail-archive.com/debian-...@lists.debian.org/msg05954.html I would say the most reasonable next step is to make synce-serial not build on GNU/kFreeBSD since ppp isn't available there. The same should probably be done to the ppp package. CC:ing Anarcat in case he has related thoughts. -- Asheesh. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601622: Did this ever work? (-:
nautilus-phatch ships this one file: /usr/share/phatch/phatch/lib/linux/nautilusExtension.py It's a metaprogram that generates Python code. It then seems that it tries to install it to my $HOME. That might be okay if it actually did that, but it never seems to. I'm pretty confused. I can't get the nautilusExtension.py code to ever execute. Dear maintainers -- is this what happens for you, too? (Sorry if I'm just being dense.) The README shipped in /usr/share/doc/phatch-nautilus/README doesn't explain what I should expect to see in Nautilus. -- Asheesh. -- After all, all he did was string together a lot of old, well-known quotations. -- H. L. Mencken, on Shakespeare -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601030: Fixing the RC bug by requesting a freeze exception
Hello Jari! I noticed this bug in the RC bugs list. I also notice that it's fixed in sid. Are you going to request a freeze exception so that the fixed package can get into sid? Let me (and the bug) know! If you want to, but aren't sure how, I can help you there, too. -- Asheesh. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590147: I can reproduce the issue; metakit is to blame; bug filed
metakit is a library bundled with Akregator. It is the source of the crash. I can reproduce this crash quite readily using the Archive directory from http://www.file-upload.net/download-2910539/Archive_old.tar.gz.html I minimized the details necessary to reproduce the bug and posted on upstream's bug tracker forum at http://www.equi4.com/fff/506 . In that post, I refer to dump -- this is a program from the upstream metakit tarball. As for what to do now: if someone wants to take a stab at *fixing* metakit's crash bug, that would be the next step! -- Asheesh. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584653: Ghostscript 9.0 does not seem to have the problem
I used the doh recipe to reproduce the bug on sid. That works fine. I just installed ghostscript 9.0 from Jonas's repositories. That recipe no longer reproduces the bug. -- Asheesh. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584759: POX believes a new upstream release is imminent
For that reason, I'm not going to do further work on this bug. He writes on #pocoo IRC. POX paulproteus: mitsuhiko will release new zine soon, don't worry about it, it will make it into Squeeze -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591761: New upstream release -- Didier, will you try packaging it?
I'm looking at the RC bugs currently open, and I see that this one is fixed by a new upstream release. I know there's a freeze on, but it seems like we ought to be able to slip this new upstream version in. Didier, will you try packaging it soon? If not, do you want someone else (e.g., me) to give it a go? -- Asheesh. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566562: liblicense: diff for NMU version 0.8-2.1
On Tue, 23 Feb 2010, gregor herrmann wrote: tags 566562 + patch pending thanks Dear maintainer, I've prepared an NMU for liblicense (versioned as 0.8-2.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Thanks for the NMU. 2 days is fine, and I'm happy you've done this work. -- Asheesh. -- It is better never to have been born. But who among us has such luck? One in a million, perhaps. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566562: liblicense-dev: patch provided: needed Depends: hicolor-icon-theme
On Sat, 30 Jan 2010, Dennis Sheil wrote: Package: liblicense-dev Severity: normal The post-installation script of liblicense-dev touches /usr/share/icons/hicolor so as to regenerate GNOME's icon cache. The hicolor-icon-theme package is not a dependency though so liblicense-dev fails when it is not aready installed. Hi! You rule. Fixing shortly. Ping me in 3 days if it's not uploaded by then. -- Asheesh. -- Option Paralysis: The tendency, when given unlimited choices, to make none. -- Douglas Coupland, Generation X: Tales for an Accelerated Culture -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562974: quassel-client: Quassl client segfaults on first run
Thanks, will try this shortly. -- Asheesh. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566562: fails to install
On Sat, 23 Jan 2010, Holger Levsen wrote: Package: liblicense-dev Version: 0.8-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts piuparts.d.o Hi, during a test with piuparts I noticed your package failed to install. From the attached log (scroll to the bottom...): Selecting previously deselected package liblicense-dev. (Reading database ... 7357 files and directories currently installed.) Unpacking liblicense-dev (from .../liblicense-dev_0.8-2_amd64.deb) ... Setting up liblicense-dev (0.8-2) ... touch: cannot touch `/usr/share/icons/hicolor': No such file or directory dpkg: error processing liblicense-dev (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: liblicense-dev E: Sub-process /usr/bin/dpkg returned an error code (1) Eek. I'll look into this. Thanks for the report. -- Asheesh. -- I put up my thumb... and it blotted out the planet Earth. -- Neil Armstrong -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562974: Re-built with WITH_DBUS=OFF, crash is gone
On Mon, 11 Jan 2010, Thomas Müller wrote: Sorry for the late reply - have been busy . Am Dienstag, 29. Dezember 2009 schrieb Asheesh Laroia: I added -DWITH_DBUS=OFF to debian/rules's DEB_CMAKE_EXTRA_FLAGS and now quasselclient runs just fine. With -DWITH_DBUS=OFF the faulting code ist not executed. Looking at the segfault, also, it's probably libQtDBus.so.4's crash, unless it's libQtCore.so.4's problem. -- Asheesh. I'll contact upstream to get some input. Great, thanks! I can also do more diagnostics if you/upstream tell me what to do. -- Asheesh. -- Leave no stone unturned. -- Euripides
Bug#562974: quassel-client: Quassl client segfaults on first run
Package: quassel-client Version: 0.5.1-1 Severity: grave Justification: renders package unusable When I install quassel-client from Debian sid and run it on my system, I get the following output: Quassel IRC: 0.5.1 7cae1afb038dd318da11c3bce23c9240eed0 # 0 quasselclient0x082af322 Quassel::logBacktrace(QString const) # 1 quasselclient0x08297f58 Quassel::handleSignal(int) # 2 0x00e7e400 __kernel_sigreturn # 3 libQtCore.so.4 0x00276750 QVariant::QVariant(QVariant const) # 4 libQtDBus.so.4 0x005ae6a0 QDBusPendingReplyData::argumentAt(int) const # 5 quasselclient0x080f7137 DesktopNotificationBackend::DesktopNotificationBackend(QObject*) # 6 quasselclient0x080dc17a MainWin::init() # 7 quasselclient0x080d0806 QtUiApplication::init() # 8 quasselclient0x080ce296 main # 9 libc.so.60x00730b35 __libc_start_main # 10 quasselclient0x080cd731 0x It seems to be segfaulting. Do you have any suggestions? Does it work for others? If so, maybe there's something environmental on my system it's allergic to, and we can get a fix upstreamed. (I'm happy to let the maintainer or other Quassel developers log in to my machine to try things.) -- Asheesh. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.30-8-generic (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages quassel-client depends on: ii dbus-x11 1.2.14-3 simple interprocess messaging syst ii libc6 2.10.1-7 GNU C Library: Shared libraries ii libgcc1 1:4.4.0-6 GCC support library ii libqt4-dbus 4:4.5.3-4 Qt 4 D-Bus module ii libqt4-network4:4.5.3-4 Qt 4 network module ii libqt4-webkit 4:4.5.3-4 Qt 4 WebKit module ii libqtcore44:4.5.3-4 Qt 4 core module ii libqtgui4 4:4.5.3-4 Qt 4 GUI module ii libstdc++64.4.0-6The GNU Standard C++ Library v3 ii quassel-data 0.5.1-1distributed IRC client using a cen Versions of packages quassel-client recommends: pn quassel-core none (no description available) quassel-client suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562974: Re-built with WITH_DBUS=OFF, crash is gone
I added -DWITH_DBUS=OFF to debian/rules's DEB_CMAKE_EXTRA_FLAGS and now quasselclient runs just fine. Looking at the segfault, also, it's probably libQtDBus.so.4's crash, unless it's libQtCore.so.4's problem. -- Asheesh. -- BOFH excuse #263: It's stuck in the Web. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#446332: Update on this bug
On Sun, 13 Dec 2009, Luk Claes wrote: I think it's wrong to leave non-regressions unfixed. Though this bug might qualify for a downgrade of the severity to important. I leave it up to you to dowgrade the severity if you thinks that's justified. I agree with you, Luk. I'll be working on fixing this bug because this bug is important. I'll mark it that way. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#446332: Update on this bug
Hey Luk, Tim, and others, This is bug in the c-client IMAP core that sits inside UW IMAP. The bug here seems to be, When alpine notifies you that it has gone read-only, it still allows you to make changes it will throw away. The appropriate simple resolution seems to be, Modify the alpine UI so that if it notifies a user that it has gone read-only, don't accept changes. In a few weeks, I will sit down with a friend and see if we can solve this. This bug in alpine has existed since lenny. However, right now, I notice a user filed http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551900 wondering where alpine I would like to ask you, Luk, if it would be okay to let alpine pass to testing in this state. The problem isn't that it has new release-critical bug, but that an old bug (as the package was released in lenny) has the same release-critical bug. What do you think, Luk? Can we let alpine pass to testing? -- Asheesh. -- I must follow the people. Am I not their leader? -Benjamin Disraeli -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524237: Fixing now
Hi Daniel, Sorry about the really long delay in my handling this bug - I had some unexpected life changes right around when you reported this. FTFBS are serious! Thank you for noticing and reporting this. I'll be uploading a fixed version to the archive shortly. -- Asheesh. -- Losing your drivers' license is just God's way of saying BOOGA, BOOGA! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#446332: control flags etc lost in concurrent access
On Tue, 16 Jun 2009, Tim Connors wrote: severity 446332 grave thanks In trying to track down why imap accounts at work (using UW-imapd, which uses c-client, which alpine uses), are getting screwed up when being accessed multiple times, I got reminded of this ancient bug that still exists. To reproduce, open up pine on your inbox, open up another pine on your inbox, and try to mark something as deleted in the first pine session which is now readonly. It will succeed. If you're lucky, the status line at top will say readonly, but it will still succeed to look like it has deleted a mail. But the changes won't be reflected on disk. In pine, the requested action (anything other than appending to a mailbox, which uses a different locking method, at least in the case of MBOX files) should just be refused. In imap, again the action should be NAKed. It should *never* be made to look like it succeeded. Agreed. Are you willing to take the matter upstream? (Is upstream still alive for UW-IMAP? I know it's barely limping along for alpine.) And in my case at home using plain old MBOX access, this is not even on an nfs store - just plain old local filesystems, which should not be hard to get right (hah! Have you ever traced through the c-client locking code? Furrfu! At work, it also fails, but of course that's on nfs, which makes things more tricky especially given the farcical locking code in c-client). You might think that not getting your deleted (and new, and read, and important, etc) flags updated is hardly dataloss, but the CEO is breathing down my boss's back because his secretary keeps on trying to delete 800 mails at a time only to have them come back and haunt her when she restarts her imap mail client in the morning, due to a new phone system we have which always wants to be connected to the IMAP store. The user should not be expected to understand that they can only connect one imap client at a time, especially when that isn't visibly enforced! Now, we use a different version of imapd at work, but in tracing the code, I'm pretty sure the debian package suffers from the same bug (since the mbox pine bug definitely exists on debian, pine just uses c-client, and imap also uses c-client, it would make sense for this all to be just the same bug in c-client), and it'd be nice to at least have it fixed somewhere (maybe I can win an argument for putting debian on our mail server at work). I have to say, you'll win that argument more easily if you don't use the UW IMAPd. Cyrus or Dovecot are more actively-maintained. I'll look into these issues in the near term, but that's my advice for this moment. -- Asheesh. -- If rash develops, discontinue use. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529832: roundup: 1.4.4-4+lenny1 breaks user creation
Package: roundup Version: 1.4.4-4+lenny1 Severity: grave Justification: renders package unusable With roundup 1.4.4-4 installed, the following use case works: * Create a new roundup * Log in as admin * Go to http://example.com/issues/us...@template=item (where /issues/ is served by Roundup) ** The page has HTML title New User - Roundup issue tracker * Enter a login name and email address and password and hit Submit new entry * Hit submit, and a user gets created; you get redirected to that user's edit user info page With roundup 1.4.4-4lenny1, the user does not get created and no error message results. (As a result, I've reverted back to 1.4.4-4 on my production install) -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-6-vserver-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523516: Haven't tested patch yet
Howdy bug and Sebastian, I don't have enough issues on my production Roundup (I'm no longer an admin on the Roundup I was testing on before) to test the patch. I will let you know shortly, though. -- Asheesh. -- A man with one watch knows what time it is. A man with two watches is never quite sure. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523516: Upgrading to roundup 1.4.4-4+lenny1 breaks pagination entirely
Package: roundup Version: 1.4.4-4+lenny1 Severity: grave Howdy! I just upgraded to 1.4.4-4+lenny1 to fix the security issues. However, it broke pagination entirely; when going to queries like http://code.creativecommons.org/issues/issue?status=-1,1,2,3,4,5,6,7@sort=-activity@search_text=@dispname=Show%20All@filter=status@group=priority@columns=id,activity,title,creator,assignedto,status@pagesize=50@startwith=0assignedto=5 , Roundup would only show me seven results. I created a local 1.4.4-4+lenny1.1 that removes 19_bogus_pagination_request.dpatch from debian/patches/00list and rebuilt the package, and now pagination works properly for me. I have to run for now, but I think that some quick experimentation should allow you to reproduce this. I have a hunch that the problem is that this code is suspect: -self.pagesize = int(self.form[name].value) +try: +self.pagesize = int(self.form.getfirst(name)) should it not be: -self.pagesize = int(self.form[name].value) +try: +self.pagesize = int(self.form[name].value) ? Anyway, upstream's bug tracker is down so I can't check. But this security package introduced some pretty tragic breakage! -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 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 roundup depends on: ii adduser 3.110 add and remove users and groups ii python2.5.2-3An interactive high-level object-o ii python-central0.6.8 register and build utility for Pyt roundup recommends no packages. Versions of packages roundup suggests: ii libapache2-mod-python 3.3.1-7 Python-embedding module for Apache ii python-gdbm2.5.2-1 GNU dbm database support for Pytho ii python-mysqldb 1.2.2-7 A Python interface to MySQL ii python-openssl 0.7-2 Python wrapper around the OpenSSL ii python-psycopg22.0.7-4 Python module for PostgreSQL ii python-pyme0.8.1+clean-1 Python interface to the GPGME GnuP ii python-sqlite 1.0.1-7 python interface to SQLite 2 ii python-tz 2008c-2 Python version of the Olson timezo ii python-xapian 1.0.7-3.1 Xapian search engine interface for ii runit 2.0.0-1 a UNIX init scheme with service su -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496334: Yo, I think we can close this
On Mon, 5 Jan 2009, Cyril Brulebois wrote: Asheesh Laroia ashe...@asheesh.org (03/01/2009): I think this is closed: testing has the fixed version on all architectures. Do you agree? I don't think so, he reopened the bug, and marked it not fixed in this version: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=77;bug=496334. Martin, I hate to second-guess you, but can you explain why it was roepened? -- Asheesh. -- Fine day for friends. So-so day for you. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496334: Yo, I think we can close this
Hey madduck, I think this is closed: testing has the fixed version on all architectures. Do you agree? -- Asheesh. -- Always do right. This will gratify some people and astonish the rest. -- Mark Twain -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508565: Testing against 20061008-3
On Sat, 3 Jan 2009, Evgeni Golov wrote: On Tue, 16 Dec 2008 10:30:56 + (GMT) Juan Carlos Suarez wrote: /home/jcsuarez/Boulot/Oscilcodes/Filou/juan24filou structure input model type: CESAM5.* fmt: read unexpected character apparent state: unit 37 named inputfiletest.osc last format: (4i10) lately reading sequential formatted external IO ./filou: line 42: 3849 Aborted filou_exe evg...@yidhra:~/debian$ uname -m x86_64 evg...@yidhra:~/debian$ ./filou_exe structure input model type: CESAM5.* Does this output look better? :) Now I just need to understand how to make this uploadable (a sed in debian/rules on f2c.h sucks :)) Great! By all means work on a Debian release, but can you possibly contribute the fixes upstream? Hopefully they can sanity-check them and help you avoid sed. (-: -- Asheesh. -- Plaese porrf raed. -- Prof. Michael O'Longhlin, S.U.N.Y. Purchase -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: the gs-common problem
On Tue, 23 Dec 2008, Thomas Viehmann wrote: Niko Tyni wrote: On Tue, Dec 23, 2008 at 02:15:22PM +0100, Thomas Viehmann wrote: immediately after I sent the last mail, Sune Vuorela pointed me to apache2's fix for #390823: They simply remove the problematic maintainer script. The question then is where to do this in so it is reliably done before stuff happens. In one of the perl packages (because the upgrade of perl triggers this) is probably too ugly, maybe the configure script of ghostscript? I think it's too late to do it inside ghostscript, it would have to go in perl-modules. Maybe configure script is badly worded: It's most blatant abuse, but I'd just stick it into a /var/lib/dpkg/info/ghostscript.config unless there are apt-get-lookalikes that don't call that at the beginning of an upgrade. If the user produces the bad situation with dpkg by himself, well, who cares. I think this is the best strategy. Better to hack related packages. An alternative is to to add gs-common being added to apt's 01autoremove, but I think that the /var/lib/dpkg/info/ghostscript.config change is a better choice; it limits the number of source packages affected. I left some more notes on the bug, but this is the crux of it. -- Asheesh. -- You never know how many friends you have until you rent a house on the beach. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#501114: Upstream
Have you discussed this with upstream? It's a relief that the 1.8 branch appears not to have this problem; perhaps a simple fix can be backported. -- Asheesh. -- Q: Why does Washington have the most lawyers per capita and New Jersey the most toxic waste dumps? A: God gave New Jersey first choice. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508397: Not fixed on ia64?
This has been the reason for an older bug against util-vserver. You can see the FTBFS on ia64 with an error like this: .../src/exec-remount.c:110: undefined reference to `umount2' build log: http://buildd.debian.org/fetch.cgi?pkg=util-vserverver=0.30.216~r2772-6arch=ia64stamp=1229143992file=log Therefore, it seems to me that this bug is not quite fixed. Micah, if you agree, we should probably reopen this and give it a second look. P.S. If this email sounds less coherent than usual, please excuse me. (-: Regardless, happy Boxing Day! -- Asheesh. -- You have an unusual equipment for success. Be sure to use it properly. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: Hack gs-common into shape
This bug 503712 discusses an issue with gs-common sometimes interfering in an upgrade to Lenny. One suggestion is to hack apt to not autoremove gs-common. Another is to, since gs-common is a transition package now, just remove (etch) gs-common's prerm script by (lenny) ghostscript's .config script. I think that is far better. Thomas, are you going to submit that as an NMU? (Merry Christmas!) If not, I could. If you take more than three days to reply, I'll submit one. -- Asheesh. -- You will never know hunger. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: FYI
On Wed, 24 Dec 2008, Asheesh Laroia wrote:
On Wed, 24 Dec 2008, Asheesh Laroia wrote:
Right now, I'm going to try testing if listing gs-common in
/etc/apt/apt.conf.d/01autoremove helps.
I can't come up with a recipe for reproducing this that uses apt (apt-get OR
aptitude), not just dpkg --unpack. So I'm at a roadbloack; I can't do the
experiment because I don't have a control.
I just created a Xen guest for testing this to ensure a good simulation
(rather than a chroot). I created a fresh Etch install on amd64, used
tasksel to enable Desktop, Web server, and SQL server, and waited for them
to successfully finish.
Then I did:
* (Switch sources.list to lenny)
* aptitude install apt aptitude dpkg
* aptitude install xserver-xorg-video-all
So far, so good, just like the original message in the bug.
Then I did:
$ aptitude dist-upgrade
Unfortunately this downloaded ca. 1000 packages and seemed to work fine
for me. One of the first things that happens is gs-common gets removed.
Because this happens before perl-modules is changed, there is no chance to
tickle the broken prerm script from gs-common.
Therefore I still see no way to test for this issue with apt(itude) which
would test the apt-related fix. I don't know of a way to influence the
ordering to encourage apt to partially upgrade perl-modules first, which
is the problematic scenario.
SCENARIO 1
APT removes gs-common in the dist-upgrade. This can cause a bad race
between the broken maintainer script of gs-common and perl-modules, if
perl-modules is partially upgraded at the time that gs-common gets
removed.
SCENARIO 2
I can verify that adding gs-common to /etc/apt/apt.conf.d/01autoremove
causes APT to download one extra file:
Get:1 http://mirrors.acm.jhu.edu lenny/main gs-common 8.62.dfsg.1-3.1 [28.4kB]
In this scenario, gs-common is upgraded rather than removed, removing the
possibility of this race, because the broken etch gs-common maintainer
prerm script is never run.
MY CONCLUSION
Given these two scenarios, I believe we are best-off by modifying
aptitude's 01autoremove to avoid autoremoving gs-common.
I have attached a patch to *apt* from lenny (with NMU-style changelog, but
it's just an explanation of what I suggest; I don't plan to personally
upload that modified package yet!).
I believe that adding the change this change would adequately fix the
issue.
ALTERNATIVE
As suggested, we could hack the ghostscript.config script to forcefully
remove the prerm of gs-common. I'll email this bug with a suggested NMU
that implements that strategy.
-- Asheesh.
--
You have a reputation for being thoroughly reliable and trustworthy.
A pity that it's totally undeserved.
diff -urN apt-0.7.19/debian/apt.conf.autoremove
apt-0.7.20/debian/apt.conf.autoremove
--- apt-0.7.19/debian/apt.conf.autoremove 2008-06-09 17:10:09.0
-0400
+++ apt-0.7.20/debian/apt.conf.autoremove 2008-12-25 19:20:00.0
-0500
@@ -4,5 +4,6 @@
{
^linux-image.*;
^linux-restricted-modules.*;
+ ^gs-common$;
};
};
diff -urN apt-0.7.19/debian/changelog apt-0.7.20/debian/changelog
--- apt-0.7.19/debian/changelog 2008-11-24 04:35:21.0 -0500
+++ apt-0.7.20/debian/changelog 2008-12-25 20:04:41.0 -0500
@@ -1,3 +1,12 @@
+apt (0.7.19+nmu1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * apt.conf.autoremove: Add gs-common to list of packages not to be
+autoremoved. This works around a bad bug in the etch gs-common prerm
+where it fails to execute while perl is partially unpacked in an upgrade.
+
+ -- Asheesh Laroia ashe...@asheesh.org Thu, 25 Dec 2008 19:31:28 -0500
+
apt (0.7.19) unstable; urgency=low
[ Eugene V. Lyubimkin ]
Bug#503907: Works on i386
I can't reproduce the bug on i386. I'll try on amd64 now. -- Asheesh. -- It may or may not be worthwhile, but it still has to be done. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503907: diffstat
I just did a diffstat on the two libwebkit-1.0-1 source packages in question. $ debdiff webkit_1.0.1-4.dsc webkit_1.0.2~pre.svn37878-1.dsc | diffstat [...] 3832 files changed, 193186 insertions(+), 1006263 deletions(-) Egad, that's a lot of differences. I have a feeling that the libwebkit currently in sid and lenny is pretty broken, from the looks of this bug. Dear Debian-Releasers, Is there any way that this library can be permitted to enter testing with all these changes? Perhaps the webkit maintainers can offer an explanation for all these changes, but with the changes so numerous, I imagine that would be difficult. If not, and the Debian Releasers insist that this can't flow into Lenny without that explanation, I believe the maintainers have three choices: * Find the fix for this issue and backport it on top of 1.0.1-4 * Remove libwebkit-1.0-1 from lenny * Simply allow lenny to release with 1.0.1-4 that is this broken. The last one is a real option, as I understand things, and one could offer a newer libwebkit e.g. in backports once Lenny ships. Dear maintainers, what is your plan? At least if you say Choice 3 we'll stop bothering you. Removing libwebkit-1.0-1 from lenny is also somewhat reasonable, if somewhat tragic. Finding the patch and backporting it is best, but it's an open question as to if that's worth doing. -- Asheesh. -- You have had a long-term stimulation relative to business. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: FYI
Right now, I'm going to try testing if listing gs-common in /etc/apt/apt.conf.d/01autoremove helps. -- Asheesh. -- You like to form new friendships and make new acquaintances. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503712: FYI
On Wed, 24 Dec 2008, Asheesh Laroia wrote: Right now, I'm going to try testing if listing gs-common in /etc/apt/apt.conf.d/01autoremove helps. I can't come up with a recipe for reproducing this that uses apt (apt-get OR aptitude), not just dpkg --unpack. So I'm at a roadbloack; I can't do the experiment because I don't have a control. To be specific, in my minimal etch chroot, after setting sources.list to lenny, doing aptitude dist-upgrade does not trigger the failure, nor does aptitude install perl-modules ghostscript. I'll sleep on it and see if I can come up with a way to reproduce it that could test the proposed 01autoremove fix. -- Asheesh. -- Your temporary financial embarrassment will be relieved in a surprising manner. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508565: Testing against 20061008-3
On Tue, 16 Dec 2008, Juan Carlos Suarez wrote: Dear Asheesh and Evgeni, I have tested the most recent version of f2c with my code. Unfortunately it still crashes showing the same error messages: Can you try downloading and compiling ftp://netlib.bell-labs.com:21/netlib/f2c/src.tar and seeing if that version, which is two years newer than the one in Debian, still has this issue? http://www.netlib.org/f2c/ is the homepage for the program. You could also try emailing the author; feel free to keep me and this bug CC:d if you do that. His email address is dmg at acm.org http://www.netlib.org/f2c/README. Thanks! -- Asheesh. -- They can't stop us... we're on a mission from God! -- The Blues Brothers -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508114: jack-a-c-k: Patch not a total fix
On Sat, 13 Dec 2008, Sebastian Andrzej Siewior wrote: So you should check for one of them IMHO. So in that case I was in the wrong line an passing va_list to next function is valid (I was wondering here a little...). Got it. So this patch fixes the FTBFS on alpha. Now that it compiles, the semantics are the same on any architecture. Upstream seems slow to answer if the patch is good, even for the previous patch which was not. So let's see if we can sanity-check this without upstream's help. Can you test this patch on non-alpha, then? If it doesn't hurt non-alpha, and it fixes the FTBFS, then we should ship it. (It's not some massive patch whose meaning is hard to understand, and it's not a security-sensitive issue.) As I understand it, the only reason we haven't put this into the jack-audio-connection-kit source package is that you want to be more confident of the effect on non-alpha machines. Therefore, let's try to be more confident of that so we can unblock this for testing so we can get another couple of RC bugs closed that depend on this. (-: -- Asheesh. -- Q: How much does it cost to ride the Unibus? A: 2 bits. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508565: Testing against 20061008-3
Dear Juan Carlos Suarez, We should find out if this affects the most recent version of f2c in Debian. If you can't test it, that's okay; can you attach your bcoeff_rot_nadl_juan.f and oscillations.c and I can test them? Thanks! -- Asheesh. -- A banker is a fellow who lends you his umbrella when the sun is shining and wants it back the minute it begins to rain. -- Mark Twain -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508114: jack-a-c-k: Patch not a total fix
On Sun, 14 Dec 2008, Asheesh Laroia wrote: On Sat, 13 Dec 2008, Sebastian Andrzej Siewior wrote: So you should check for one of them IMHO. So in that case I was in the wrong line an passing va_list to next function is valid (I was wondering here a little...). Got it. So this patch fixes the FTBFS on alpha. Now that it compiles, the semantics are the same on any architecture. Upstream seems slow to answer if the patch is good Upstream committed this patch: torbenh3 20:47 droncho New news from jacktimeline: Changeset [3205]: Fix alpha compilation error. Debian Bug #508114. So that's that! I'm attaching an NMU-style debdiff as a proposal for what should go into Lenny. This way you have a ready-made changelog entry to use if you like. -- Asheesh. -- Go to a movie tonight. Darkness becomes you.diff -urN jack-audio-connection-kit-0.115.6.orig/debian/changelog jack-audio-connection-kit-0.115.6/debian/changelog --- jack-audio-connection-kit-0.115.6.orig/debian/changelog 2008-12-14 12:07:19.0 -0800 +++ jack-audio-connection-kit-0.115.6/debian/changelog 2008-12-14 12:13:23.0 -0800 @@ -1,3 +1,12 @@ +jack-audio-connection-kit (0.115.6-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Add patch to fix alpha build failure by using var args correctly +(earlier versions of Jack improperly passed the va_list around). +The issue is fixed in upstream svn r3205. (Closes: #508114) + + -- Asheesh Laroia ashe...@asheesh.org Sun, 14 Dec 2008 12:09:16 -0800 + jack-audio-connection-kit (0.115.6-1) unstable; urgency=low * New Upstream Version diff -urN jack-audio-connection-kit-0.115.6.orig/libjack/client.c jack-audio-connection-kit-0.115.6/libjack/client.c --- jack-audio-connection-kit-0.115.6.orig/libjack/client.c 2008-11-23 06:27:20.0 -0800 +++ jack-audio-connection-kit-0.115.6/libjack/client.c 2008-12-14 12:09:11.0 -0800 @@ -969,7 +969,7 @@ } /* parse variable arguments */ - if (ap) + if (options (JackServerName | JackLoadName | JackLoadInit)) jack_varargs_parse(options, ap, va); else jack_varargs_init(va); @@ -1117,7 +1117,7 @@ jack_options_t options = JackUseExactName; if (getenv(JACK_START_SERVER) == NULL) options |= JackNoStartServer; - return jack_client_open_aux (client_name, options, NULL, NULL); + return jack_client_open (client_name, options, NULL); } char *
Bug#508114: jack-audio-connection-kit: Uploading new version to fix alpha FTBFS
On Sun, 14 Dec 2008, Asheesh Laroia wrote: attached as debdiff.patch against -1 Actually attached this time. Pardon the noise! -- Asheesh. -- Don't plan any hasty moves. You'll be evicted soon anyway.diff -urN jack-audio-connection-kit-0.115.6-1/debian/changelog jack-audio-connection-kit-0.115.6-1.1/debian/changelog --- jack-audio-connection-kit-0.115.6-1/debian/changelog 2008-12-14 19:41:31.0 -0800 +++ jack-audio-connection-kit-0.115.6-1.1/debian/changelog 2008-12-14 19:46:33.0 -0800 @@ -1,3 +1,13 @@ +jack-audio-connection-kit (0.115.6-1.1) unstable; urgency=low + + * Non-maintainer upload. + * 11_fix_varargs_to_fix_ftbfs_on_alpha.patch: Add patch to fix alpha +build failure by using var args correctly (earlier versions of Jack +improperly passed the va_list around). The issue is fixed in upstream +svn r3205. (Closes: #508114) + + -- Asheesh Laroia ashe...@asheesh.org Sun, 14 Dec 2008 12:09:16 -0800 + jack-audio-connection-kit (0.115.6-1) unstable; urgency=low * New Upstream Version diff -urN jack-audio-connection-kit-0.115.6-1/debian/patches/11_fix_varargs_to_fix_ftbfs_on_alpha.patch jack-audio-connection-kit-0.115.6-1.1/debian/patches/11_fix_varargs_to_fix_ftbfs_on_alpha.patch --- jack-audio-connection-kit-0.115.6-1/debian/patches/11_fix_varargs_to_fix_ftbfs_on_alpha.patch 1969-12-31 16:00:00.0 -0800 +++ jack-audio-connection-kit-0.115.6-1.1/debian/patches/11_fix_varargs_to_fix_ftbfs_on_alpha.patch 2008-12-14 19:46:34.0 -0800 @@ -0,0 +1,28 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run +## 11_fix_varargs_to_fix_ftbfs_on_alpha.patch.dpatch by ashe...@asheesh.org +## +## All lines beginning with `## DP:' are a description of the patch. +## DP: No description. + +...@dpatch@ +diff -urNad jack-audio-connection-kit-0.115.6~/libjack/client.c jack-audio-connection-kit-0.115.6/libjack/client.c +--- jack-audio-connection-kit-0.115.6~/libjack/client.c 2008-11-23 06:27:20.0 -0800 jack-audio-connection-kit-0.115.6/libjack/client.c 2008-12-14 18:47:32.0 -0800 +@@ -969,7 +969,7 @@ + } + + /* parse variable arguments */ +- if (ap) ++ if (options (JackServerName | JackLoadName | JackLoadInit)) + jack_varargs_parse(options, ap, va); + else + jack_varargs_init(va); +@@ -1117,7 +1117,7 @@ + jack_options_t options = JackUseExactName; + if (getenv(JACK_START_SERVER) == NULL) + options |= JackNoStartServer; +- return jack_client_open_aux (client_name, options, NULL, NULL); ++ return jack_client_open (client_name, options, NULL); + } + + char *
Bug#508114: jack-audio-connection-kit: Uploading new version to fix alpha FTBFS
(freee - see below) Dear debian-release, jack-audio-connection-kit has a FTBFS bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508114 Fixing this bug and allowing the resulting jack-audio-connection-kit to flow into Lenny would close this Lenny RC bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500540 - you can see at http://buildd.debian.org/pkg.cgi?pkg=kdebase that kdebase is ready to be installed into testing if only there is a libjack-dev that meets the desired criteria. I have prepared an NMU (attached as debdiff.patch against -1; also .dsc at http://mentors.debian.net/debian/pool/main/j/jack-audio-connection-kit/jack-audio-connection-kit_0.115.6-1.1.dsc ). Either the maintainer of jack-a-c-k should upload it, or someone should do the NMU. Dear Free Ekanayaka (CC:d), My initial NMU post to the bug didn't take into account that you use dpatch. I have written a fresh patch (attached) in NMU format that addresses that issue. It's an NMU format so I could write a changelog entry to describe the patch. It also creates a debian/patches file for the compile fix for this bug. Since you were the most recent uploader of jack-a-c-k, would you upload a new jack-a-c-k containing the patch in my NMU this? Feel free to just change the name on it and upload it yourself as -2. If not, is it okay if I do an NMU? Thanks all! -- Asheesh. -- The abuse of greatness is when it disjoins remorse from power. -- William Shakespeare, Julius Caesar -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506681: Stacktrace
When I run the tests in gdb, I get this stacktrace: (gdb) bt #0 0x40d5cfd4 in system__secondary_stack__ss_mark () from /usr/lib/libgnat-4.3.so.1 #1 0x40be1790 in ada__exceptions__exception_traces__notify_exceptionXn () from /usr/lib/libgnat-4.3.so.1 #2 0x40be19c0 in __gnat_notify_unhandled_exception () from /usr/lib/libgnat-4.3.so.1 #3 0x40be16b4 in ada__exceptions__exception_propagation__propagate_exceptionXn () from /usr/lib/libgnat-4.3.so.1 #4 0x40be2584 in __gnat_raise_nodefer_with_msg () from /usr/lib/libgnat-4.3.so.1 #5 0x40be2634 in __gnat_raise_exception () from /usr/lib/libgnat-4.3.so.1 #6 0x40d60f44 in _gnat_stack_check () from /usr/lib/libgnat-4.3.so.1 #7 0x00020288 in main (argc=1, argv=(system.address) 0x1, envp=(system.address) 0x40fb4fb8) at /home/paulproteus/alog/libalog-0.1/obj/b~runner.adb:524 #8 0x40e975a4 in __libc_start_main () from /lib/libc.so.6 #9 0x0001f358 in _start () (gdb) This looks to me like a libgnat-4.3.so.1 bug. -- Asheesh. -- Q: What do monsters eat? A: Things. Q: What do monsters drink? A: Coke. (Because Things go better with Coke.) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506264: [PATCH] trivial backport against the Lenny package
gnunet has an RC bug in lenny that is fixed in sid: #506264 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506264 This bug is fixed by a simple change to a postinst script, as in the attached patch. I'm CC:ing my AM, to make sure he knows what I'm up to, and Adeodato, with whom I discussed this on #debian-release. I believe this is a sensible thing to put into t-p-u and into testing. I'm not entirely sure of the package version number and changelog entry; I'd appreciate Adeodato's input on that. -- Asheesh. -- If you refuse to accept anything but the best you very often get it.diff -urN gnunet-0.8.0/debian/changelog gnunet-0.8.0.asheesh/debian/changelog --- gnunet-0.8.0/debian/changelog 2008-12-13 05:11:41.0 -0800 +++ gnunet-0.8.0.asheesh/debian/changelog 2008-12-13 05:16:29.0 -0800 @@ -1,3 +1,13 @@ +gnunet (0.8.0-2.1) lenny; urgency=low + + * Non-maintainer update. + * Lenny backport of a change in sid: Adding '|| true' to +gnunet-update call; this way a hanging gnunet-update can be aborted +in a(n almost) sane way. See also upstream bug +https://gnunet.org/mantis/view.php?id=1349 . (Closes: #506264) + + -- Asheesh Laroia ashe...@asheesh.org Sat, 13 Dec 2008 05:14:37 -0800 + gnunet (0.8.0-2) unstable; urgency=low * Creating /var/run/gnunetd in initscript in case /var/run is on a tmpfs. diff -urN gnunet-0.8.0/debian/gnunet-server.postinst gnunet-0.8.0.asheesh/debian/gnunet-server.postinst --- gnunet-0.8.0/debian/gnunet-server.postinst 2008-12-13 05:11:41.0 -0800 +++ gnunet-0.8.0.asheesh/debian/gnunet-server.postinst 2008-12-13 05:14:29.0 -0800 @@ -94,7 +94,7 @@ # This is need to migrate data from 0.6.1b or later echo -n Migrating previous GNUnet data (gnunet-update): - gnunet-update + gnunet-update || true echo done. # Cleaning
Bug#506264: [PATCH] trivial backport against the Lenny package
On Sat, 13 Dec 2008, Daniel Baumann wrote: Asheesh Laroia wrote: This bug is fixed by a simple change to a postinst script, as in the attached patch. do *NOT* upload that nmu; the version from sid needs to be unblocked in order to fix another rc bug, which is what i'm (preparing to) discussing with luk. Sounds good, thanks for the update! -- Asheesh. -- Truly great madness can not be achieved without significant intelligence. -- Henrik Tikkanen -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507021: Update? re: Lenny
Hey pabs, I think the best thing to do is to follow the advice of Ben Hutchings and let a 32-bit version of helpdeco be distributed with lenny. I could prepare a patch and try to find a sponsor for the upload, or you could do it. I'm fine either way. Removing it from Lenny seems sad. I'm CC:ing my AM in an attempt to flood him with mail (I mean, keep him aware of my activities). Either way, the decision is up to you; just decide and we'll have one fewer RC bug in Lenny! -- Asheesh. -- A paranoid is a man who knows a little of what's going on. -- William S. Burroughs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506264: [PATCH] trivial backport against the Lenny package
On Sat, 13 Dec 2008, Daniel Baumann wrote: Asheesh Laroia wrote: Sounds good, thanks for the update! and for the record.. i brought this up 13 weeks ago already. however, what sucks is: unfortunately, upstream did re-run the autofoo stuff (20 files for config.* updates; 80 files for Makefile updates, 19 files for m4 updates) and libltdl (the later makes 53 files changing; but which is not a problem, 0.8.0b has been build flawlessly on all arches).. excately 140 files have dos-line break now, but are otherwise identical. in diff, they show up as completely replaced files. and theres a dozen or two which got new line-wrappings (after 80 chars, instead of over-long lines). which is a pita to prepare manually a cleaned up diff for 0.8.0 - 0.8.0b to have luk review it. Wouldn't adding -b to the diff arguments be enough? Or even --strip-trailing-cr. Just thinking aloud. -- Asheesh. -- I am a deeply superficial person. -- Andy Warhol -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508114: jack-a-c-k: Patch not a total fix
Hi. The sun is rising where I am, and I am tired, so I will be a little brief. I tested your alpha patch, and it does not fix all the problems. Line 972 of client.c still has the same problem for me: if(ap) is still a va_list that is being treated improperly. I'm CC:ing my AM (Steffen) so he knows what I'm up to! Is it adequate, do you think, to test if ap == NULL? I am falling asleep so take it as a senseless suggestion. I'm borrowing an Alpha shell from friendly folks on #gentoo-alpha so I can test there. Here is the compile log to show it: /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I..-I../config -I.. -I.. -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -g -O2 -g -Wall -O2 -DJACK_LOCATION=\/usr/bin\ -I../config -I.. -I.. -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -g -O2 -g -Wall -O2 -c -o libjack_la-client.lo `test -f 'client.c' || echo './'`client.c cc -DHAVE_CONFIG_H -I. -I.. -I../config -I.. -I.. -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -g -O2 -g -Wall -O2 -DJACK_LOCATION=\/usr/bin\ -I../config -I.. -I.. -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -g -O2 -g -Wall -O2 -c client.c -fPIC -DPIC -o .libs/libjack_la-client.o In file included from ../config/sysdeps/atomicity.h:20, from ../jack/internal.h:73, from client.c:40: ../config/cpu/generic/atomicity.h:23:2: warning: #warning stub atomicity functions are not atomic on this platform In file included from ../config/sysdeps/cycles.h:24, from client.c:58: ../config/cpu/generic/cycles.h:25:2: warning: #warning You are compiling JACK on a platform for which jack/config/sysdep/cycles.h needs work client.c: In function 'jack_client_open_aux': client.c:972: error: used struct type value where scalar is required make: *** [libjack_la-client.lo] Error 1 -- Asheesh. -- Higher education helps your earning capacity. Ask any college professor. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508114: jack-a-c-k: Patch not a total fix
On Sat, 13 Dec 2008, Sebastian Andrzej Siewior wrote:
* Asheesh Laroia | 2008-12-13 06:59:46 [-0800]:
Hi.
Hello,
Is it adequate, do you think, to test if ap == NULL? I am falling asleep
so take it as a senseless suggestion.
This is not what you want. You should not access va_list directly, you
have to use helpers like va_{start|end|arg|copy} to deal with them.
The code looks to me like the option variable can be ored with
JackServerName JackLoadName JackLoadInit to indicate what is in
va_list. Same like %s printf for instance.
Ah-hah, got it.
So you should check for one of them IMHO. So in that case I was in the
wrong line an passing va_list to next function is valid (I was wondering
here a little...).
Please find attached an updated patch.
The updated patch *alone* does fix the compile failure on Alpha, with no
other changes.
-- Asheesh.
--
doogie asuffield: how do you think dpkg was originally written? :|
asuffield by letting iwj get dangerously near a computer
-- in #debian-devel
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#460695: alpine: uw-mailutils already ships mailutil
On Fri, 12 Dec 2008, Adeodato Simó wrote: Hello Asheesh, others. * Asheesh Laroia [Thu, 06 Mar 2008 19:47:24 -0800]: Supporting new drivers means patching the uw-imap source included with alpine. I believe it makes good sense to instead patch alpine the use the shared (Debian-patched not-approved-by-Mark Crispin) libc-client package and if Alpine invents additional patches for the uw-imap source in addition to the current Maildir patch then consider applying them to that shared library instead, for the benefit of php and others using it, in addition to Alpine. If we find that some patches (possibly including the current Maildir patch) may not be stable enough to force all Debian users of uw-imap and other C-lient-based software, then we could maybe extend the build routines of uw-imap to package several flavors of th c-client library with different patches applied. This seems like more trouble than it's worth. I hardly see the benefit at all, actually. But tell me if I'm missing something. It is very important to make an effort that the same code is not compiled from different source packages. That is, if package X ships a copy of library L, which is packaged separately in Debian as well, and the configure script of X wants to compile that private copy of the library and link statically against it, then Debian prefers that the configure script of X be modified so that X links against the packaged version of L. This is so becuase code duplication increases the amount of work the security team has to perform if a security hole is discovered in L; and exposes users to unknown vulnerabilities if the code duplication between X and L is not known by the security team. Thanks for the thoughtful email. I agree with the concerns you raised and will see about how to do this. Help is welcome! -- Asheesh. -- Cold hands, no gloves.
Bug#502507: [NMU] Fixing #502507 in cournol: fails to build from source
Hello Alejandro, maintainer of cournol, I'm working on improving package quality, and I found a release-critical bug filed against cournol: Bug #502507 is from two months ago. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502507 I'm CC:ing the bug, as well as Mako (my usual sponsor; I'm not a Debian Developer), as well as my account manager, Steffen. cournol's build dependency list includes a package that is not in sid anymore, so I have prepared an NMU that includes a patch in the BTS to fix that issue. This patch is necessary to allow cournol to continue to build against sid. http://mentors.debian.net/debian/pool/main/c/cournol/cournol_0.5-1.2.dsc is the dsc link. I intend to ask Mako to upload this as a Non-Maintainer Update (NMU) if you do not reply within a few days. I intend to stick to the conventions at http://www.debian.org/doc/developers-reference/pkgs.html#nmu for this NMU. I did jump ahead a little and already prepare the NMU, but don't be offended by that; if you like my changes and have time to do the update yourself, please just re-use them yourself and upload it yourself. If you do not have time to upload this update, then just say it is okay and we will uploaded it as an NMU. If you do not have even time for that, then it will be uploaded as an NMU anyway. You have about two weeks, as per the usual process. My .dsc source package is available at http://mentors.debian.net/debian/pool/main/c/cournol/cournol_0.5-1.2.dsc The debdiff between the source packages is attached as debdiff.patch. -- Asheesh. -- It were not best that we should all think alike; it is difference of opinion that makes horse-races. -- Mark Twain, Pudd'nhead Wilson's Calendar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504875: Unblock suggestion: libggi
Howdy Debian Releasers, I was examining the remaining Lenny RC bugs and found http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504875 via http://bts.turmzimmer.net/details.php?bydist=bothsortby=packagesfullcomment=on . This is an RC bug against libggi2-dev (in src:libggi). This issue is fixed in unstable, and the fix is a tiny patch, and the -3 release that is in sid corrects only that RC bug and the maintainer's email address. I believe that it should get unblocked and go into Lenny. I'm probably not authorized to formally request it, since I'm neither the maintainer nor the Release Team. (I'm CC:ing my AM so he knows what I'm up to.) -- Asheesh. -- You will be surprised by a loud noise. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#500540: Unblock suggestion: kdebase
Howdy folks, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500540 is an RC bug in kdebase that is present in Lenny but not in sid. The upload from 2-3 weeks ago of -6 fixes it. I'm explicitly CC:ing the uploader of -6. The debdiff is fairly simple, and attached. The changelog reports that this fixes two bugs: the bug CC:d and the non-RC 505316. The debdiff and the changelog indicate a series file added, but both make it clear that the series file does not change the actual patch system. This RC bug is still in Lenny, even though -6 fixes it in sid. It seems to me that kdebase should be unblocked, and -6 be allowed to flow into testing. I'm not the maintainer or debian-release, so my word is by no means gospel. I'm also CC:ing my AM so he knows what I'm up to. If debian-release *really* would prefer a 4:3.5.9.dfsg.1-5+lenny1 that only fixes the RC and removes the other two changes, I can work on preparing it. It doesn't seem a productive use of time but I leave that decision to debian-release. -- Asheesh. -- They spell it da Vinci and pronounce it da Vinchy. Foreigners always spell better than they pronounce. -- Mark Twain -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508124: This appears to actually be a bug in M2Crypto
Note the last part of the traceback: File /var/lib/python-support/python2.5/M2Crypto/m2urllib2.py, line 113, in build_opener if inspect.isclass(check): NameError: global name 'inspect' is not defined It is due to a missing import inspect in M2Crypto. It is fixed in the 0.18.2-2 upload of M2Crypto. Going to try to ask for a freeze exception for M2Crypto so that 0.18.2-1 can hit Lenny. -- Asheesh. -- Good day for a change of scene. Repaper the bedroom wall. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508124: Unblock suggestion: m2crypto
On Thu, 11 Dec 2008, Asheesh Laroia wrote: python-m2crypto 0.18.2-1 has a critical bug that it is missing an import. The attached debdiff fixes this and one other housekeeping issue. As it is a tiny patch, and it fixes a release-critical bug, I believe it is appropriate to be allowed to flow into Lenny. I was not clear in the original mail, excuse the noise: 0.18.2-2 in sid fixes the issue, and it is that package that I believe should flow into Lenny. -- Asheesh. -- Clothes make the man. Naked people have little or no influence on society. -- Mark Twain -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508124: Unblock suggestion: m2crypto
Howdy again Debian Releasers, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508124 is indicated as a lenny+sid RC bug. This is a duplicate of #484364 (by the time you see this, I will have merged them). python-m2crypto 0.18.2-1 has a critical bug that it is missing an import. The attached debdiff fixes this and one other housekeeping issue. As it is a tiny patch, and it fixes a release-critical bug, I believe it is appropriate to be allowed to flow into Lenny. I'm explicitly CC:ing the maintainer of python-m2crypto and my AM, so they both clearly know what I'm up to. As always with my unblock suggestions, I'm not the maintainer nor Debian-Release, so this is just a suggestion. But I do think it is the right course of action. -- Asheesh. -- Knock, knock! Who's there? Sam and Janet. Sam and Janet who? Sam and Janet Evening... diff -u m2crypto-0.18.2/M2Crypto.egg-info/SOURCES.txt m2crypto-0.18.2/M2Crypto.egg-info/SOURCES.txt --- m2crypto-0.18.2/M2Crypto.egg-info/SOURCES.txt +++ m2crypto-0.18.2/M2Crypto.egg-info/SOURCES.txt @@ -48 +48 @@ -SWIG/_m2crypto.i +SWIG/_m2crypto.i \ No newline at end of file diff -u m2crypto-0.18.2/M2Crypto.egg-info/PKG-INFO m2crypto-0.18.2/M2Crypto.egg-info/PKG-INFO --- m2crypto-0.18.2/M2Crypto.egg-info/PKG-INFO +++ m2crypto-0.18.2/M2Crypto.egg-info/PKG-INFO @@ -1,6 +1,6 @@ Metadata-Version: 1.0 Name: M2Crypto -Version: 0.17 +Version: 0.18.2 Summary: M2Crypto: A Python crypto and SSL toolkit Home-page: http://wiki.osafoundation.org/bin/view/Projects/MeTooCrypto Author: Heikki Toivonen diff -u m2crypto-0.18.2/debian/changelog m2crypto-0.18.2/debian/changelog --- m2crypto-0.18.2/debian/changelog +++ m2crypto-0.18.2/debian/changelog @@ -1,3 +1,10 @@ +m2crypto (0.18.2-2) unstable; urgency=low + + * Added import inspect to M2Crypto/m2urllib2.py +(Closes: #493314, #484364, 477799) + + -- Dima Barsky d...@debian.org Fri, 15 Aug 2008 22:04:14 +0100 + m2crypto (0.18.2-1) unstable; urgency=low * New upstream release (Closes: #440837) diff -u m2crypto-0.18.2/debian/control m2crypto-0.18.2/debian/control --- m2crypto-0.18.2/debian/control +++ m2crypto-0.18.2/debian/control @@ -3,7 +3,7 @@ Priority: optional Maintainer: Dima Barsky d...@debian.org Build-Depends: debhelper (= 5.0.37.2), python-all-dev (= 2.3.5-11), python-support (= 0.4), libssl-dev (= 0.9.7), swig (= 1.3.24), python-setuptools (=0.6c5-3) -Standards-Version: 3.7.2 +Standards-Version: 3.8.0 Package: python-m2crypto Architecture: any only in patch2: unchanged: --- m2crypto-0.18.2.orig/M2Crypto/m2urllib2.py +++ m2crypto-0.18.2/M2Crypto/m2urllib2.py @@ -13,6 +13,7 @@ from urllib2 import * import urlparse +import inspect import SSL import httpslib
Bug#489501: [PATCH] Fixing #489501 (zekr depends on libxul0d)
On Thu, 11 Dec 2008, Mohammad wrote: Dear Asheesh, Thank you very much for your effort and working on zekr. I tested your source package. It woks fine for me on Ubuntu Intrepid. Unfortunately, our Debian sponsors were a little busy, so I couldn't resolve the problem myself. I really appreciate if you upload your package to Debian. P.S: The current version of zekr in Debian, 0.5.1, is very old. We have prepared a deb package for the latest release, 0.7.1, which is available here: https://launchpad.net/~zekr/+archivehttps://launchpad.net/%7Ezekr/+archive Dear Mako! Now that I have the maintainer's ACK, let's do this NMU! Again, the .dsc is at http://mentors.debian.net/debian/pool/main/z/zekr/zekr_0.5.1.dfsg-1.1.dsc . And dear Mohammad, Thanks for the prompt reply. Let's talk in the future about getting zekr in Debian back on track. Maybe if one day I become a Debian Developer I can see about sponsoring this for you. (-: (And dear Steffen: two of three Serious bugs fixed so far!) -- Asheesh. -- Today is what happened to yesterday. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504050: antlr updates (bug #504050)
I'm in NM, and so I'm on a quest to hunt and crush bugs, especially RC
ones. Bug #504050 in antlr is not a Lenny RC bug, since it is sid-only,
but I would still like to see it closed. I'm CC:ing my account manager so
he knows what I'm up to.
On that note, there are two updates for the antlr Subversion repository.
First of all, 2.7.7-9 was never checked in; the attached dash-nine.patch
corrects that.
Secondly, I am attaching a patch called dash-ten.patch that can be
committed after dash-nine is. It adds the debdiff from the bug report
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504050 to the package
and updates debian/changelog.
These patches are very simple; anyone with commit access and five minutes
should be able to review them, commit, do an svn tag for -9 and -10, and
then upload.
I have written the changelog entry not as an NMU but as a maintainer
update, under the idea that I'm doing this to join the
pkg-java-maintainers team, a concept I'm comfortable with. I'll stay
around pkg-java-maintainers for at least half a year, although my primary
interest is Python, not Java. If there are more bugs I can help fix, I
may try to do that!
-- Asheesh.
--
You will live a long, healthy, happy life and make bags of money.Index: debian/control
===
--- debian/control (revision 7633)
+++ debian/control (working copy)
@@ -30,7 +30,7 @@
Package: libantlr-java
Architecture: all
-Recommends: libantlr-gcj
+Recommends: libantlr-java-gcj
Replaces: antlr ( 2.7.7-8)
Description: language tool for constructing recognizers, compilers etc (java library)
ANTLR, ANother Tool for Language Recognition, (formerly PCCTS) is
@@ -44,7 +44,7 @@
Package: libantlr-java-gcj
Section: devel
Architecture: any
-Depends: libantlr (= ${source:Version}), ${shlibs:Depends}
+Depends: libantlr-java (= ${source:Version}), ${shlibs:Depends}
Replaces: antlr-gcj
Description: language tool for constructing recognizers, compilers etc
Native support for gij for antlr. ANTLR stands for ANother
Index: debian/changelog
===
--- debian/changelog (revision 7633)
+++ debian/changelog (working copy)
@@ -1,3 +1,9 @@
+antlr (2.7.7-9) unstable; urgency=low
+
+ * libantlr-java{,-gcj}: Fix typos in dependencies.
+
+ -- Matthias Klose [EMAIL PROTECTED] Tue, 21 Oct 2008 01:08:32 +0200
+
antlr (2.7.7-8) unstable; urgency=low
* Build a libantlr-java package, without dependency on a java runtime.
diff -urN debian.dash-ten/changelog debian/changelog
--- debian.dash-ten/changelog 2008-12-10 11:23:07.0 -0800
+++ debian/changelog 2008-12-10 11:24:22.0 -0800
@@ -1,3 +1,11 @@
+antlr (2.7.7-10) unstable; urgency=low
+
+ * Fixed cantlr package to depend on libantlr-java-gcj rather than
+nonexistent antlr-gcj (finishing migration started in 2.7.7-8).
+(Closes: #504050)
+
+ -- Asheesh Laroia [EMAIL PROTECTED] Wed, 10 Dec 2008 11:23:40 -0800
+
antlr (2.7.7-9) unstable; urgency=low
* libantlr-java{,-gcj}: Fix typos in dependencies.
diff -urN debian.dash-ten/control debian/control
--- debian.dash-ten/control 2008-12-10 11:27:59.0 -0800
+++ debian/control 2008-12-10 11:03:37.0 -0800
@@ -80,7 +80,7 @@
Package: cantlr
Section: devel
Architecture: any
-Depends: gij, libantlr-java-gcj, ${shlibs:Depends}
+Depends: gij, antlr-gcj, ${shlibs:Depends}
Description: language tool for constructing recognizers, compilers etc
This is the native-compiled version of antlr. ANTLR stands for ANother
Tool for Language Recognition, (formerly PCCTS). It is a language tool
Bug#489501: [PATCH] Fixing #489501 (zekr depends on libxul0d)
:/usr/share/java/commons-logging.jar:/usr/share/java/velocity.jar:dist/zekr.jar
++CLASS_PATH=/usr/share/java/log4j-1.2.jar:/usr/share/java/swt.jar:/usr/share/java/commons-collections3.jar:/usr/share/java/commons-configuration.jar:/usr/share/java/commons-io.jar:/usr/share/java/commons-lang.jar:/usr/share/java/commons-logging.jar:/usr/share/java/velocity.jar:dist/zekr.jar
VM_ARGS=-Xms10m -Xmx70m
cd $DIR_NAME
diff -u zekr-0.5.1.dfsg/debian/changelog zekr-0.5.1.dfsg/debian/changelog
--- zekr-0.5.1.dfsg/debian/changelog
+++ zekr-0.5.1.dfsg/debian/changelog
@@ -1,3 +1,20 @@
+zekr (0.5.1.dfsg-1.1) intrepid; urgency=low
+
+ * Non-maintainer upload.
+ * debian/control: Update build-dependencies to require SWT 3.4, not 3.2
+ * debian/control: Update dependencies to use SWT 3.4 and the appropriate
+Mozilla bindings, rather than SWT 3.2
+ * patches/00_build_xml.dpatch: SWT is now in /usr/share/java/swt.jar
+ * patches/01_linux_run_sh.dpatch: SWT is now in /usr/share/java/swt.jar
+ * zekr.sh: Comment out shell script section about finding MOZILLA_FIVE_HOME,
+since the SWT 3.4 Mozilla bindings do not need that set at all.
+ * patches/01_linux_run_sh.dpatch: Similarly, comment out the extension
+of LD_LIBRARY_PATH to include MOZILLA_FIVE_HOME.
+ * debian/control: SWT 3.4 Mozilla bindings do not require libxul0d.
+Ergo we stop depending on it. (Closes: #489501)
+
+ -- Asheesh Laroia [EMAIL PROTECTED] Wed, 10 Dec 2008 19:33:52 -0800
+
zekr (0.5.1.dfsg-1) unstable; urgency=low
* Initial release. (Closes: #436189)
diff -u zekr-0.5.1.dfsg/debian/control zekr-0.5.1.dfsg/debian/control
--- zekr-0.5.1.dfsg/debian/control
+++ zekr-0.5.1.dfsg/debian/control
@@ -6,16 +6,15 @@
libcommons-lang-java (= 2.3), libcommons-logging-java (= 1.0.4),
libcommons-collections3-java (= 3.1), libcommons-configuration-java (= 1.2),
libcommons-io-java (= 1.1), velocity (= 1.4), liblog4j1.2-java (= 1.2.8),
- libswt3.2-gtk-java (= 3.2)
+ libswt-gtk-3.4-java, libswt-mozilla-gtk-3.4-jni
Build-Depends: debhelper (= 5.0), cdbs, dpatch
Standards-Version: 3.7.2
Package: zekr
Architecture: all
-Depends: libxul0d,
- zenity,
- java-gcj-compat | java2-runtime,
- libswt3.2-gtk-java (= 3.2), libswt3.2-gtk-jni (= 3.2),
+Depends: zenity,
+ libswt-gtk-3.4-java, libswt-gtk-3.4-jni,
+ libswt-mozilla-gtk-3.4-jni,
libcommons-lang-java (= 2.3), libcommons-logging-java (= 1.0.4),
libcommons-collections3-java (= 3.1), libcommons-configuration-java (= 1.2),
libcommons-io-java (= 1.1), velocity (= 1.4), liblog4j1.2-java (= 1.2.8),
diff -u zekr-0.5.1.dfsg/debian/zekr.sh zekr-0.5.1.dfsg/debian/zekr.sh
--- zekr-0.5.1.dfsg/debian/zekr.sh
+++ zekr-0.5.1.dfsg/debian/zekr.sh
@@ -5,24 +5,26 @@
purpose=Zekr provides an open platform for simply browsing and researching on the Holy Quran.
run () {
-# Set path for the Mozilla SWT binding
-MOZILLA_FIVE_HOME=${MOZILLA_FIVE_HOME%*/}
-if false [ -n $MOZILLA_FIVE_HOME -a -e $MOZILLA_FIVE_HOME/libgtkembedmoz.so ]; then
+# SWT 3.4 does not need a path set for MOZILLA_FIVE_HOME
+# So in this NMU, we comment out this handling.
+# A real package update will remove this logic entirely.
+#MOZILLA_FIVE_HOME=${MOZILLA_FIVE_HOME%*/}
+#if false [ -n $MOZILLA_FIVE_HOME -a -e $MOZILLA_FIVE_HOME/libgtkembedmoz.so ]; then
:
-elif [ -e /usr/lib/firefox/libgtkembedmoz.so ]; then
-export MOZILLA_FIVE_HOME=/usr/lib/firefox
-elif [ -e /usr/lib/xulrunner/libgtkembedmoz.so ]; then
-export MOZILLA_FIVE_HOME=/usr/lib/xulrunner
-elif [ -e /usr/lib/mozilla-firefox/libgtkembedmoz.so ]; then
-export MOZILLA_FIVE_HOME=/usr/lib/mozilla-firefox
-elif [ -e /usr/lib/mozilla/libgtkembedmoz.so ]; then
-export MOZILLA_FIVE_HOME=/usr/lib/mozilla
-else
-zenity --warning \
---title=Integrated browser support not working \
---text=This Zekr build doesn't have support for the integrated browser.
-[ $? -eq 0 ] || exit 1
-fi
+#elif [ -e /usr/lib/firefox/libgtkembedmoz.so ]; then
+#export MOZILLA_FIVE_HOME=/usr/lib/firefox
+#elif [ -e /usr/lib/xulrunner/libgtkembedmoz.so ]; then
+#export MOZILLA_FIVE_HOME=/usr/lib/xulrunner
+#elif [ -e /usr/lib/mozilla-firefox/libgtkembedmoz.so ]; then
+#export MOZILLA_FIVE_HOME=/usr/lib/mozilla-firefox
+#elif [ -e /usr/lib/mozilla/libgtkembedmoz.so ]; then
+#export MOZILLA_FIVE_HOME=/usr/lib/mozilla
+#else
+#zenity --warning \
+#--title=Integrated browser support not working \
+#--text=This Zekr build doesn't have support for the integrated browser.
+#[ $? -eq 0 ] || exit 1
+#fi
DIR_NAME=`dirname $0`
cd $DIR_NAME
cd ../share/zekr/
Bug#505445: Core dump
Dear Nigel, Let me know if you need help with instructions on how to generate a core dump. You should be able to make it if you just write ulimit -c unlimited before you run the command that segfaults. -- Asheesh. -- To generalize is to be an idiot. -- William Blake -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492933: Releaseforge 1.3 packages fix this for me
I just tried editing an existing release and adding a new file, and releaseforge handled it properly. The failures using 1.3 yestereday were due to my test machine being totally misconfigured as far as DNS. I give 1.3 my stamp of approval as a solution to this bug. -- Asheesh. -- In Brooklyn, we had such great pennant races, it made the World Series just something that came later. -- Walter O'Malley, Dodgers owner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492933: releaseforge: reportbug fails to upload to SourceForge; may be fixed in new upstream
On Sat, 2 Aug 2008, Roberto C. Sánchez wrote: On Tue, Jul 29, 2008 at 05:36:07PM -0700, Asheesh Laroia wrote: Package: releaseforge Version: 1.1-4 Severity: normal Asheesh, I have prepared packages of the new upstream release (1.3) of ReleaseForge. Would it be possible for you to test them out for me? You can obtain them here: http://people.connexer.com/~roberto/debian/ They work for me, but I would like some positive feedback before I seek a freeze excpetion (and I think that if I can positively indicate that these packages fix the bug for the subitter, it will help the case for an exception). Just tested them. (side note: new bug in 1.3: It double-lists a few projects of mine.) The release 1.3 gives me this error: 2008-08-01 22:35:24,827 - ERROR - sfcomm - (-5, 'No address associated with hostname') a few times on the console. It does claim to work fine. But it doesn't actually upload the other file I put into my existing release. (Can you test it also?) So no, it does not appear that 1.3 fixes this bug, as packaged in the above repository. -- Asheesh. -- Williams and Holland's Law: If enough data is collected, anything may be proven by statistical methods.
Bug#460695: alpine: uw-mailutils already ships mailutil
On Sat, 16 Feb 2008, Jonas Smedegaard wrote: On Fri, Feb 15, 2008 at 04:11:35PM -0800, Asheesh Laroia wrote: On Sat, 9 Feb 2008, Marc Glisse wrote: Asheesh Laroia: Ssince uw-imap and alpine are separately released source bundles from washington.edu, it seems like it'd be easiest to have them remain separate source packages. uw-imap also appears as the imap subdirectory of the alpine distribution, so they can't really be considered as different sources (there is an inclusion). Now it can still make sense to keep them separate: it is nice to have a version of alpine that is as up to date as possible, whereas the imap server (and others) may require more reliability (and thus stability). That's right. Your choice. I never proposed to merge the sources in any way. I proposed to work together on both of them - keeping them as separate sources and packaging them as separate sets of packages. I'm happy with you maintaining the UW IMAP server separately. The important question is, probably, whose mailutil should we ship? Alpine is more likely to get fruity drivers like Maildir, which Mark Crispin doesn't think are high enough quality to get into the real UW IMAP distribution; that seems to me to be a reason to ship the alpine version. But I'm not set on that. After all, stability in a mailutil might be appreciated too. (-: Maildir is a driver for the imap backend, handled by C-client. Mark Crispin does not want to offer c-client as a shared library. That, I believe, is the sole reason that uw-imap is included in the source of alpine. *nod* Supporting new drivers means patching the uw-imap source included with alpine. I believe it makes good sense to instead patch alpine the use the shared (Debian-patched not-approved-by-Mark Crispin) libc-client package and if Alpine invents additional patches for the uw-imap source in addition to the current Maildir patch then consider applying them to that shared library instead, for the benefit of php and others using it, in addition to Alpine. If we find that some patches (possibly including the current Maildir patch) may not be stable enough to force all Debian users of uw-imap and other C-lient-based software, then we could maybe extend the build routines of uw-imap to package several flavors of th c-client library with different patches applied. This seems like more trouble than it's worth. I hardly see the benefit at all, actually. But tell me if I'm missing something. -- Asheesh. -- No woman can endure a gambling husband, unless he is a steady winner. -- Lord Thomas Dewar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460695: alpine: uw-mailutils already ships mailutil
On Sat, 9 Feb 2008, Marc Glisse wrote: Asheesh Laroia: Ssince uw-imap and alpine are separately released source bundles from washington.edu, it seems like it'd be easiest to have them remain separate source packages. uw-imap also appears as the imap subdirectory of the alpine distribution, so they can't really be considered as different sources (there is an inclusion). Now it can still make sense to keep them separate: it is nice to have a version of alpine that is as up to date as possible, whereas the imap server (and others) may require more reliability (and thus stability). That's right. Your choice. I'm happy with you maintaining the UW IMAP server separately. The important question is, probably, whose mailutil should we ship? Alpine is more likely to get fruity drivers like Maildir, which Mark Crispin doesn't think are high enough quality to get into the real UW IMAP distribution; that seems to me to be a reason to ship the alpine version. But I'm not set on that. After all, stability in a mailutil might be appreciated too. (-: What do you think? -- Asheesh. -- What does it mean if there is no fortune for you? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464953: Fix released
See http://lists.debian.org/debian-security-announce/debian-security-announce-2008/msg00056.html . apt-get your way to the beautiful fixed future. -- Asheesh. -- You may worry about your hair-do today, but tomorrow much peanut butter will be sold. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460695: alpine: uw-mailutils already ships mailutil
On Mon, 14 Jan 2008, Jonas Smedegaard wrote: Greetings, Asheesh (and others following this conversation), I don't know if the mailutils packaged as part of uw-imap is better or worse than yours. But uw-imap and alpine is quite similar, even in coding style. How would you like it we maintain both packages together? Ssince uw-imap and alpine are separately released source bundles from washington.edu, it seems like it'd be easiest to have them remain separate source packages. I am fond of cdbs. And am familiar with using svn-buildpackage but have also begun using git-buildpackage for my most recent packaging. I'll go have a closer look at alpine packaging to get a feeling about your packaging habbits after writing this email... You can take a look - I hope you don't find them too messy. (-: I haven't had very good luck with cdbs, but I'm willing to be proven wrong. I think that since they're really separate source packages there's not much reason to merge them. What do you think on that matter? -- Asheesh. -- Carswell's Corollary: Whenever man comes up with a better mousetrap, nature invariably comes up with a better mouse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460695: alpine: uw-mailutils already ships mailutil
On Mon, 14 Jan 2008, Aaron M. Ucko wrote: Package: alpine Version: 1.0+dfsg-2 Severity: serious Justification: Policy 6.6(4) Shipping mailutil (and its manpage) straight up leads to file conflicts with the uw-mailutils package, which already supplies both. I'm specifically assigning this to alpine because uw-mailutils has precedence, but you're most welcome to address it in either or both (for instance by means of update-alternatives). Wow, that's embarrassing. I'll release a -3 pretty immediately that removes the file. Dear UW Mailutils package tracker recipients of this message: is your version of mailutils as up-to-date (or more) as alpine's, as well as DFSG-compliant? If so I'm perfectly satisfied to never release a mailutil binary in the alpine packageever again -- Asheesh. -- What you don't know can hurt you, only you won't know it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377420: mod-bt - FTBFS: Not resolvable build dependencies
On Sun, 9 Jul 2006, Tyler MacDonald wrote: But if I have to remove the apr1 | apr0 sutff, then a new version of mod-bt (and every other apache2 module) will be neccessary when the switch to 2.2 happens. In theory you could just switch the order of apr1 | apr0. But I agree that this is less than desired. -- Asheesh. -- Be sure each item is properly endorsed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347241: remove cue2toc from cdrdao
Package: cdrdao Version: 1:1.1.9-3 Severity: serious Justification: Policy 12.5 I pinged you on #debian-devel about this last night, but I disappeared quickly into the night. Here's the run-down: * /usr/bin/cue2toc and its man page appear in the cdrdao package. * They also both appear in my cue2toc package. MY package also includes a sample RC. * It's by the same author as my cue2toc package. * You don't credit him in debian/copyright (hence serious bug). * You ship version 0.2 whereas I ship version 0.4. * cue2toc has its own existence at http://cue2toc.sourceforge.net, and updates are moe likely to come out of the sourceforge project than a historical integration into the cdrdao source. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-386 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages cdrdao depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libgcc1 1:3.4.3-13 GCC support library ii libstdc++5 1:3.3.5-13 The GNU Standard C++ Library v3 -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
