Bug#1025825: More information on bug

[Joe Pfeiffer]

See this discussion, including a patch, on google groups:
https://groups.google.com/g/linux.debian.bugs.dist/c/FzL7OUmy8jw
-- 

Bug#1030920: src:ipyparallel unsatisfied build dependency: python-distributed-doc

[Joe Nahmias]

On Thu, Feb 09, 2023 at 09:09:12AM +0100, Paul Gevers wrote:
> Source: ipyparallel
> Version: 7.1.0-4
> Severity: serious
> Tags: sid bookworm
> User: debian...@lists.debian.org
> Usertags: edos-uninstallable
> 
> Dear maintainer(s),

Hello,

> Can you please investigate the situation and figure out how to resolve
> it? Regularly, if the build dependency is available in unstable,
> helping the maintainer of your Build-Depends to enable migration to
> testing is a great way to solve the issue. If your build dependency is
> gone from unstable and testing, you'll have to fix the build process
> in some other way. dask.distributed was removed from testing because of bug
> 1030096.

According to [2], dask.distributed 2022.02.0+ds.1-3 was removed due to a
hint from ginggs:

  Hint: <https://release.debian.org/britney/hints/ginggs>
# 20230125
# allow pandas and dask to migrate

And now version 2022.12.1+ds.1-2 is blocked from migrating due to 1030096.
Have I understood the situation correctly?

How does this relate to the impending soft freeze? My understanding is
that we only have until 2023-02-12 to fix dask.distributed and have it
migrated -- a very tight deadline.

> Paul
--Joe

Bug#1028982: metakernel: autopkgtest regression on s390x: AssertionError

[Joe Nahmias]

On Sun, Jan 15, 2023 at 07:37:01PM +0100, Paul Gevers wrote:
> With a recent upload of metakernel the autopkgtest of metakernel fails in
> testing when that autopkgtest is run with the binary packages of metakernel
> from unstable on s390x. It passes when run with only packages from testing.
> In tabular form:
> 
>passfail
> metakernel from testing0.29.4-1
> versioned deps [0] from testingfrom unstable
> all others from testingfrom testing
> 
> Currently this regression is blocking the migration to testing [1]. Can you
> please investigate the situation and fix it?
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul

Hello Paul,

Thanks for the report. I ran the following to try and reproduce this using
unstable:

ssh zelenka.debian.org
schroot -b -c sid -n $LOGNAME-metakernel
dd-schroot-cmd -c $LOGNAME-metakernel apt-get update
dd-schroot-cmd -c $LOGNAME-metakernel apt-get dist-upgrade
dd-schroot-cmd -c $LOGNAME-metakernel apt-get build-dep metakernel
dd-schroot-cmd -c $LOGNAME-metakernel apt-get install python3-metakernel 
python-metakernel-doc autopkgtest autodep8 pybuild-plugin-autopkgtest
schroot -r -c $LOGNAME-metakernel
/usr/bin/autopkgtest --shell-fail metakernel -- null
exit
schroot -e -c $LOGNAME-metakernel

However, all the tests passed for both python 3.10 & 3.11.

> [0] You can see what packages were added from the second line of the log
> file quoted below. The migration software adds source package from unstable
> to the list if they are needed to install packages from metakernel/0.29.4-1.
> I.e. due to versioned dependencies or breaks/conflicts.
> [1] https://qa.debian.org/excuses.php?package=metakernel
> 
> https://ci.debian.net/data/autopkgtest/testing/s390x/m/metakernel/30188929/log.gz

I tried to look for this list of packages on the second line of the log.gz URL,
but second line I see is:

autopkgtest [16:36:08]: version 5.27

In any case, to the best of my knowledge, there aren't any direct versioned
deps from metakernel.

Moreover, I don't know how to inject metakernel/0.29.4-1 into a bookworm
schroot on zelenka, so I'm a bit stuck here :(

Any ideas on how to proceed?

--Joe

Bug#1028477: php-odbc: regression - login failed with php 8.2, works under 8.1

[Joe Nahmias]

Package: php8.2-odbc
Version: 8.2.1-1
Severity: grave
X-Debbugs-Cc: j...@nahmias.net

Hello,

There seems to be a regression with php8.2-odbc, compared to php8.1-odbc:

$ cat /tmp/test-php_odbc.php
setAttribute(\PDO::ATTR_ERRMODE, \PDO::ERRMODE_EXCEPTION);
print("Connected!\n");

$ php8.1 /tmp/test-php_odbc.php
Connected!

$ php8.2 /tmp/test-php_odbc.php
PHP Fatal error:  Uncaught PDOException: SQLSTATE[42000] SQLDriverConnect: 
18456 [FreeTDS][SQL Server]Login failed for user 'kbUnitTests'. in 
/tmp/test-php_odbc.php:7
Stack trace:
#0 /tmp/test-php_odbc.php(7): PDO->__construct()
#1 {main}
  thrown in /tmp/test-php_odbc.php on line 7

$ dpkg -l php\* | grep ^i
ii  php-common 2:92+nmu1all  Common files for PHP packages
ii  php8.1-cli 8.1.12-1+b1  amd64command-line interpreter for 
the PHP scripting language
ii  php8.1-common  8.1.12-1+b1  amd64documentation, examples and 
common module for PHP
ii  php8.1-odbc8.1.12-1+b1  amd64ODBC module for PHP
ii  php8.1-opcache 8.1.12-1+b1  amd64Zend OpCache module for PHP
ii  php8.1-readline8.1.12-1+b1  amd64readline module for PHP
ii  php8.2-cli 8.2.1-1  amd64command-line interpreter for 
the PHP scripting language
ii  php8.2-common  8.2.1-1  amd64documentation, examples and 
common module for PHP
ii  php8.2-odbc8.2.1-1  amd64ODBC module for PHP
ii  php8.2-opcache 8.2.1-1  amd64Zend OpCache module for PHP
ii  php8.2-readline8.2.1-1  amd64readline module for PHP

Please let me know if you need any additional information!
--Joe

Bug#1028297: python3-freezegun: ships a copy of python3-arrow: /usr/lib/python3/dist-packages/arrow/*.py

[Joe Nahmias]

On Mon, Jan 09, 2023 at 11:59:42AM +0100, Andreas Beckmann wrote:
> Package: python3-freezegun
> Version: 1.2.1-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> during a test with piuparts I noticed your package failed to install
> because it tries to overwrite other packages files.

Actually, it looks like the upstream source tarball for arrow v1.2.1 got
imported into the freezegun salsa repo by mistake -- instead of freezegun
v1.2.1.  The (arrow) code was then subsequently built and uploaded (as
freezegun) -- without noticing the change.

This breaks anything that needs freezegun, as that python module is not
provided by this (version of the) package (anymore).

--Joe

Bug#1008180: php-pear uninstallable

[Joe Nahmias]

On Wed, Mar 23, 2022 at 09:21:57AM -0400, Joe Nahmias wrote:
> Hello Ondřej,
> 
> Firstly, thanks for all your work on packaging PHP for Debian!
> 
> I noticed that the recent php-pear upload to Debian unstable,
> 1:1.10.13+submodules+notgz+2022032201-1, is uninstallable due to a bad dep on
> php-archive-tar. I see in the Salsa git repo that you reverted a commit and
> then updated the changelog with -2, but there is no tag nor was -2 uploaded to
> Debian.
> 
> Was this deliberate? Is more testing needed? Can you just tag/upload? Should 
> I?
> 
> Much appreciated,
> --Joe

On the assumption that this was likely an oversight, I uploaded the -2 from
Salsa (with a quick addition to close the bug in the changelog) to the
DELAYED/2 queue. Happy to revert if this is undesirable.

--Joe

Bug#1002190: [Pkg-javascript-devel] Bug#1002190: Bug#1002190: gyp: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" returned exit code 13

[joe]

I can take a look at this.--Joe
 Original message From: Yadd  Date: 12/22/21  
04:57  (GMT-05:00) To: 1002...@bugs.debian.org Subject: [Pkg-javascript-devel] 
Bug#1002190: Bug#1002190: gyp: FTBFS:
  dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9"
  returned exit code 13 Hi,is there someone with Python skills to fix that ?I 
think that this package should really own to Python Team, not JS 
Team.Cheers,YaddOn 21/12/2021 16:59, Lucas Nussbaum wrote:> Source: gyp> 
Version: 0.1+20210831gitd6c5dd5-1> Severity: serious> Justification: FTBFS> 
Tags: bookworm sid ftbfs> User: lu...@debian.org> Usertags: ftbfs-20211220 
ftbfs-bookworm> > Hi,> > During a rebuild of all packages in sid, your package 
failed to build> on amd64.> > > Relevant part (hopefully):>> make[1]: Entering 
directory '/<>'>> dh_auto_build>> I: pybuild base:237: 
/usr/bin/python3.10 setup.py build>> running build>> running build_py>> 
creating /<>/.pybuild/cpython3_3.10/build/gyp>> copying 
pylib/gyp/__init__.py -> /<>/.pybuild/cpython3_3.10/build/gyp>> 
copying pylib/gyp/xcode_ninja.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp>> copying 
pylib/gyp/simple_copy.py -> /<>/.pybuild/cpython3_3.10/build/gyp>> 
copying pylib/gyp/ninja_syntax.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp>> copying 
pylib/gyp/common_test.py -> /<>/.pybuild/cpython3_3.10/build/gyp>> 
copying pylib/gyp/win_tool.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp>> copying pylib/gyp/input.py 
-> /<>/.pybuild/cpython3_3.10/build/gyp>> copying 
pylib/gyp/MSVSProject.py -> /<>/.pybuild/cpython3_3.10/build/gyp>> 
copying pylib/gyp/xml_fix.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp>> copying 
pylib/gyp/MSVSUtil.py -> /<>/.pybuild/cpython3_3.10/build/gyp>> 
copying pylib/gyp/mac_tool.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp>> copying 
pylib/gyp/flock_tool.py -> /<>/.pybuild/cpython3_3.10/build/gyp>> 
copying pylib/gyp/xcodeproj_file.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp>> copying 
pylib/gyp/input_test.py -> /<>/.pybuild/cpython3_3.10/build/gyp>> 
copying pylib/gyp/easy_xml_test.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp>> copying 
pylib/gyp/msvs_emulation.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp>> copying 
pylib/gyp/xcode_emulation.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp>> copying pylib/gyp/common.py 
-> /<>/.pybuild/cpython3_3.10/build/gyp>> copying 
pylib/gyp/MSVSUserFile.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp>> copying 
pylib/gyp/easy_xml.py -> /<>/.pybuild/cpython3_3.10/build/gyp>> 
copying pylib/gyp/MSVSSettings.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp>> copying 
pylib/gyp/MSVSVersion.py -> /<>/.pybuild/cpython3_3.10/build/gyp>> 
copying pylib/gyp/MSVSToolFile.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp>> copying 
pylib/gyp/MSVSSettings_test.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp>> copying 
pylib/gyp/MSVSNew.py -> /<>/.pybuild/cpython3_3.10/build/gyp>> 
creating /<>/.pybuild/cpython3_3.10/build/gyp/generator>> copying 
pylib/gyp/generator/__init__.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp/generator>> copying 
pylib/gyp/generator/xcode_test.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp/generator>> copying 
pylib/gyp/generator/msvs_test.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp/generator>> copying 
pylib/gyp/generator/msvs.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp/generator>> copying 
pylib/gyp/generator/ninja_test.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp/generator>> copying 
pylib/gyp/generator/gypsh.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp/generator>> copying 
pylib/gyp/generator/analyzer.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp/generator>> copying 
pylib/gyp/generator/xcode.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp/generator>> copying 
pylib/gyp/generator/make.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp/generator>> copying 
pylib/gyp/generator/gypd.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp/generator>> copying 
pylib/gyp/generator/dump_dependency_json.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp/generator>> copying 
pylib/gyp/generator/eclipse.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp/generator>> copying 
pylib/gyp/generator/ninja.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp/generator>> copying 
pylib/gyp/generator/cmake.py -> 
/<>/.pybuild/cpython3_3.10/build/gyp/generator>> I: pybuild 
base:237: /usr/bin/py

Bug#984122: closing 984122

[Joe Nahmias]

close 984122 2.5.0+dfsg1-1
thanks

Forgot to mark it closed in the changelog

Bug#997378: python-coverage: diff for NMU version 5.1+dfsg.1-2.1

[Joe Nahmias]

Control: tags 997378 + patch


Dear maintainer,

I've prepared an NMU for python-coverage (versioned as 5.1+dfsg.1-2.1). The diff
is attached to this message.

Regards.

diff -Nru python-coverage-5.1+dfsg.1/debian/changelog python-coverage-5.1+dfsg.1/debian/changelog
--- python-coverage-5.1+dfsg.1/debian/changelog	2020-09-06 01:43:16.0 -0400
+++ python-coverage-5.1+dfsg.1/debian/changelog	2021-11-19 08:33:46.0 -0500
@@ -1,3 +1,10 @@
+python-coverage (5.1+dfsg.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * use add_css_file() instead of deprecated add_stylesheet(); closes: #997378. 
+
+ -- Joseph Nahmias   Fri, 19 Nov 2021 08:33:46 -0500
+
 python-coverage (5.1+dfsg.1-2) unstable; urgency=medium
 
   * The “Karl Karnadi” release.
diff -Nru python-coverage-5.1+dfsg.1/debian/patches/05.fix-add_stylesheet.patch python-coverage-5.1+dfsg.1/debian/patches/05.fix-add_stylesheet.patch
--- python-coverage-5.1+dfsg.1/debian/patches/05.fix-add_stylesheet.patch	1969-12-31 19:00:00.0 -0500
+++ python-coverage-5.1+dfsg.1/debian/patches/05.fix-add_stylesheet.patch	2021-11-19 08:31:49.0 -0500
@@ -0,0 +1,18 @@
+Description: use add_css_file() instead of deprecated add_stylesheet()
+Author: Joseph Nahmias 
+Bug-debian: https://bugs.debian.org/997378
+Forwarded: not-needed
+Applied-Upstream: https://github.com/nedbat/coveragepy/commit/4859de2850f703207b0cab2ff6e7116a3e587b65
+Last-Update: 2021-11-19
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/doc/conf.py
 b/doc/conf.py
+@@ -230,6 +230,6 @@ prerelease = bool(max(release).isalpha()
+ 
+ def setup(app):
+ """Configure Sphinx"""
+-app.add_stylesheet('coverage.css')
++app.add_css_file('coverage.css')
+ app.add_config_value('prerelease', False, 'env')
+ print("** Prerelease = %r" % prerelease)
diff -Nru python-coverage-5.1+dfsg.1/debian/patches/series python-coverage-5.1+dfsg.1/debian/patches/series
--- python-coverage-5.1+dfsg.1/debian/patches/series	2020-09-06 01:43:16.0 -0400
+++ python-coverage-5.1+dfsg.1/debian/patches/series	2021-11-19 08:32:28.0 -0500
@@ -2,3 +2,4 @@
 02.rename-public-programs.patch
 03.remove-hotkeys.patch
 04.sphinx-add-code-path.patch
+05.fix-add_stylesheet.patch

Bug#972570: [Pkg-javascript-devel] Bug#972570: node-lightgallery is built using minified files

[Joe Nahmias]

Hello,

Now that bullseye has been released, would it be possible to upload a fix
for this to unstable? That would allow node-lightgallery and rainloop to
migrate to testing (bookworm) and then be backported to bullseye.

If you are not able to do this at the moment, due to time constraints, I'm
happy to prepare the upload based on what's in Salsa, as long as it's okay
with the JS team.

Thanks,
--Joe

On Sat, Apr 24, 2021 at 04:12:06PM -0700, Daniel Ring wrote:
> It looks like this RC bug also caused the next version of Rainloop to be
> removed from bullseye before the freeze. That version contains an relatively
> important security fix (bug #962629), so both Rainloop and node-lightgallery
> will need to be uploaded to bullseye-backports (when available) as well as
> unstable.
> 
> Sincerely,
> Daniel Ring
> 
> On 4/23/2021 9:35 PM, Daniel Ring wrote:
> > The warnings are already overridden in the current version on Salsa,
> > since the Youtube/Vimeo/etc. embeds are only loaded when Lightgallery is
> > used to display a video from that source (e.g. by passing it a Youtube
> > link).
> > 
> > Sincerely,
> > Daniel Ring
> > 
> > On 4/23/2021 12:31 PM, Yadd wrote:
> > > Le 23/04/2021 à 19:03, Jonas Smedegaard a écrit :
> > > > Quoting Yadd (2021-04-23 17:47:23)
> > > > > Control: tags -1 + pending
> > > > > 
> > > > > Le 23/04/2021 à 09:44, Daniel Ring a écrit :
> > > > > > Hello Xavier,
> > > > > > 
> > > > > > It looks like the build process was minifying the source files to 
> > > > > > the
> > > > > > destination *.js files and copying the pre-minified
> > > > > > files to *.min.js. I
> > > > > > corrected it to copy the unminified files directly and minify them 
> > > > > > to
> > > > > > *.min.js.
> > > > > > 
> > > > > > I also updated the package on Salsa to exclude the minified
> > > > > > modules/*.min.js files via Files-Excluded in
> > > > > > d/copyright, so they're no
> > > > > > longer in the source package at all.
> > > > > > 
> > > > > > Sincerely,
> > > > > > Daniel Ring
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > looks good to me, thanks! Could you also ignore these warnings in a
> > > > > debain/lintian-overrides? It looks like false positive
> > > > > 
> > > > > Cheers,
> > > > > Yadd
> > > > > 
> > > > >   W: node-lightgallery: privacy-breach-generic
> > > > > usr/share/nodejs/lightgallery/dist/js/lg-video.min.min.js [ > > > > class="lg-video-object lg-dailymotion '+o+'" '+l+' width="560"
> > > > > height="315"
> > > > [...]
> > > > Those warnings look real to me.
> > > > 
> > > > What makes you consider them false positives, Xavier?
> > > 
> > > Hi Jonas,
> > > 
> > > yes but the relevant lines are in if/then/else blocks:
> > > 
> > >    if (isVideo.youtube) {
> > >  ...  video = '

Bug#982047: wordwarvi

[Joe Nahmias]

Hi Ricardo,

Sorry, been afk for a few days...

On Sat, Feb 06, 2021 at 12:48:45PM +0100, Ricardo Mones wrote:
> control: tags -1 confirmed
> 
> Hi Joe,
> 
> On Sun, Jan 31, 2021 at 07:10:46PM -0500, Joe Nahmias wrote:
> > 
> > Indeed, fortuitous timing! He just tagged and closed your issue.Yes,
> > I'm familiar with packaging and at one point was the maintainer for
> > this package, so I should be okay ;)--Joe
> 
> Well, for the next time I'd suggest you to push your changes to salsa
> *before* uploading or at least *immediately after* uploading ;-)

Hmm, I did push to salsa -- I even see the tags there!
Ah, I see what happened. I was using the debian/master branch, but the
salsa repo default is just master. Do you have a preference one way or the
other?

> If you don't have the time or willingness to do it, just please push
> your pending git commits, I'd like to fix #982047 ASAP.

I can push/upload a fix for this tonight.

> Thanks in advance,
> -- 
>  Ricardo Mones
>  http://people.debian.org/~mones
>  «Everything will be just tickety-boo today.»

--Joe

Bug#981835: I am unable to resolve libelf1 violates Multi-Arch: same / unreproducible issue

[Joe Irungu]

Good day,

I am a debian bullseye/sid 64 bit user.When I ran the command apt update &&
apt upgrade today to update my packages i got message below

You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 libdw1:i386 : Depends: libelf1:i386 (= 0.182+20210203-1.1) but
0.182+20210203-1 is installed
 libelf1 : Breaks: libelf1:i386 (!= 0.182+20210203-1.1) but
0.182+20210203-1 is installed
 libelf1:i386 : Breaks: libelf1 (!= 0.182+20210203-1) but
0.182+20210203-1.1 is installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or
specify a solution).

When I ran the apt --fix-broken install I got messages below

Unpacking libelf1:i386 (0.182+20210203-1.1) over (0.182+20210203-1) ...
dpkg: error processing archive
/var/cache/apt/archives/libelf1_0.182+20210203-1.1_i386.deb (--unpack):
 trying to overwrite shared
'/usr/share/locale/en@boldquot/LC_MESSAGES/elfutils.mo',
which is different from other instances of package libelf1:i386
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

When I researched on this I stumbled onto your webpage
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981835 and solutions
provided dont work for me.

Kindly assist.

Best Regards

Bug#979363: update dovecot package?

[Joe Nahmias]

Hello dovecot folks,

Thanks for maintaining dovecot in Debian! I received an alert on my
dovecot-fts-xapian package that it is due to be removed from bullseye due
to security issues in the current dovecot package.

Just wanted to ask if there's anything I can do to help? I could try
updating the package to the latest upstream release, which should fix
those issues, but hesitate to do that without maintainer agreement. Given
the timing, I'd hate for dovecot not to be present when bullseye freezes.

Let me know,
--Joe

Bug#974211: metakernel's autopkg tests fail

[Joe Nahmias]

reassign 974211 bash 5.1~rc1-1
retitle 974211 bash 5.1rc1 emits bracketed paste escape sequences for dumb 
terminals
notfound 974211 bash/5.1~rc2-1
forwarded 974211 
https://lists.gnu.org/archive/html/bug-bash/2020-11/msg00017.html
affects 974211 metakernel
thanks

Hello,

Thanks for the report.  This is an issue with bash 5.1~rc1 and was fixed
in bash 5.1~rc2.  I note that it passed in debci when I retried after the
new version of bash migrated to testing:
https://ci.debian.net/data/autopkgtest/testing/amd64/m/metakernel/8078921/log.gz

--Joe

Bug#966968: efp: FTBFS: efp.a65:line 89: 8000:Illegal segment error

[Joe Nahmias]

On Mon, Sep 28, 2020 at 10:58:11AM +0200, Nicolas Boulenguez wrote:
> Package: src:efp
> Followup-For: Bug #966968
> 
> asm_to_a65.pl translates efp.asm (DASM format) to efp.a65 (XA65
> format). The related lines are:
>   # "org FOO" ==> "*=FOO"
>   s/\s*org\s+/*=/;
>   and
> s/\s*SEG\.U\s+\w+/.zero/;
> s/\s*SEG\s+/./;
> They rewrite
> ; *** DATA SEGMENT
> SEG.U   data
> org $
> as
> ; *** DATA SEGMENT
> .zero
> *=$
> The '.zero' line is rejected by xa65 2.3.11.
> There has probably been a change in the syntax described in
> http://www.floodgap.com/retrotech/xa/dists/xa-2.3.11.tar.gz
> /doc/fileformat.txt

Hmm, this is strange. AFAICT, the '.zero' directive should be allowed. I
did a bit more investigation, and it definitely seems like there was a
change in xa65 to add an extra check for relmode on allowing that
statement. Looking at the diff for xat.c between 2.3.8 and 2.3.11, I
see:

  if(n==Kzero) {
-/* if(segment!=SEG_ABS) {   */
  +   if(relmode) {
  segment = SEG_ZERO;
  t[0]=Ksegment;
  t[1]=SEG_ZERO;
  *ll=2;
  er=E_OKDEF;
  -/* } else {
+   } else {
  er=E_ILLSEGMENT;
  -   }*/
+   }
  } else

At this point, I think the easiest fix is to just use DASM and skip this
whole translation business. I downloaded it from
https://github.com/dasm-assembler/dasm and it seemed to run with no issues
and produce an identical efp.nes file. So, maybe we should just package it
and then update the efp to use that instead... it seems to be a much more
active project lately than xa65.

--Joe

Bug#921904: Bug#946951: Bug#921904: win-iconv: FTBFS (wine: chdir to /tmp/wine-I6miLw/server-29-3583b06 : No such file or directory)

[Joe Nahmias]

On 12/27/2019 6:23 PM, Vincent Lefevre wrote:

On 2019-12-27 19:49:46 +, Joseph Nahmias wrote:

On Fri, Dec 27, 2019 at 07:27:42PM +, Joseph Nahmias wrote:

The attached patch works around the issue until that is fixed.


Of course, I forgot this patch... Take 2.


Wouldn't the use of wildcards be a security issue?

+   ln -s /tmp/.wine-`id -u`/server* /tmp/wine-*/

i.e. could you end up creating wrong symbolic links?


Attached is an updated patch that does the extra work to avoid the 
wildcards.



In any case, this seems rather ugly to me.


Not sure precisely what you are referring to as ugly here; but in my 
experience, band-aids are usually placed over something ugly, if that's 
what you mean... The proper fix would of course have to come from within 
wine itself.


--Joe
diff -Nru win-iconv-0.0.8/debian/changelog win-iconv-0.0.8/debian/changelog
--- win-iconv-0.0.8/debian/changelog2019-03-12 12:06:01.0 -0400
+++ win-iconv-0.0.8/debian/changelog2019-12-29 01:11:42.0 -0500
@@ -1,3 +1,12 @@
+win-iconv (0.0.8-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Work around #946951 by initializing WINEPREFIX and adding a symlink,
+closes: #921904.
+  * To speed up the build, don't install g++, only gcc is needed here.
+
+ -- Joe Nahmias   Sun, 29 Dec 2019 01:11:42 -0500
+
 win-iconv (0.0.8-3) unstable; urgency=medium
 
   * wrap-and-sort -ast
diff -Nru win-iconv-0.0.8/debian/control win-iconv-0.0.8/debian/control
--- win-iconv-0.0.8/debian/control  2019-03-12 12:06:01.0 -0400
+++ win-iconv-0.0.8/debian/control  2019-12-29 01:09:11.0 -0500
@@ -7,7 +7,7 @@
  debhelper-compat (= 12),
 Build-Depends-Indep:
  dpkg-dev (>= 1.17.14),
- mingw-w64,
+ gcc-mingw-w64,
  wine [i386 amd64]  ,
 Vcs-Git: https://salsa.debian.org/debian/win-iconv.git
 Vcs-Browser: https://salsa.debian.org/debian/win-iconv
diff -Nru win-iconv-0.0.8/debian/rules win-iconv-0.0.8/debian/rules
--- win-iconv-0.0.8/debian/rules2019-03-12 11:29:02.0 -0400
+++ win-iconv-0.0.8/debian/rules2019-12-29 01:03:56.0 -0500
@@ -3,11 +3,13 @@
 # we do not want stackprotector because there is no implementation on mingw32:
 export DEB_BUILD_MAINT_OPTIONS = hardening=-stackprotector
 
+DEB_BUILD_ARCH ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH)
 ifeq ($(DEB_BUILD_ARCH),i386)
   TESTARCH=i686-w64-mingw32
 else ifeq ($(DEB_BUILD_ARCH), amd64)
   TESTARCH=x86_64-w64-mingw32
 endif
+export WINEPREFIX := $(CURDIR)/build-$(TESTARCH)/.wine
 
 %:
dh $@
@@ -30,9 +32,17 @@
  cd .. ; \
done
 
+override_dh_auto_test: T := $(CURDIR)/build-$(TESTARCH)/tmp
 override_dh_auto_test:
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 ifdef TESTARCH
-   cd build-$(TESTARCH) && WINEPREFIX=$(shell pwd)/build-$(TESTARCH)/.wine 
$(MAKE) CC=$(TESTARCH)-gcc AR=$(TESTARCH)-ar RANLIB=$(TESTARCH)-ranlib 
DLLTOOL=$(TESTARCH)-dlltool test
+   -wineboot -i
+   mkdir -p $(T)/`cat "${WINEPREFIX}/wineserver"`/
+   -ln -s /tmp/.wine-`id -u`/$$( \
+   printf "server-%x-%x" `stat --printf="%d %i" "${WINEPREFIX}"` \
+ ) $(T)/`cat "${WINEPREFIX}/wineserver"`/
+   $(MAKE) -C build-$(TESTARCH) CC=$(TESTARCH)-gcc AR=$(TESTARCH)-ar \
+   RANLIB=$(TESTARCH)-ranlib DLLTOOL=$(TESTARCH)-dlltool \
+   TMPDIR=$(T) test
 endif
 endif

Bug#917738: patch

[Joe Lee]

tag 917738 + patch
thanks

Hi, here's a patch for bug #917738 that I extracted from upstream.
Description: remove WebServiceException
Origin: upstream, https://github.com/OpenHFT/Chronicle-Threads/commit/bb1d4edfc7a783ebdc7c58bfc2f278f665e2539e#diff-e5af304c7efa4fec7930553b2fab754b
Index: openhft-chronicle-threads-1.1.6/src/main/java/net/openhft/chronicle/threads/MonitorEventLoop.java
===
--- openhft-chronicle-threads-1.1.6.orig/src/main/java/net/openhft/chronicle/threads/MonitorEventLoop.java
+++ openhft-chronicle-threads-1.1.6/src/main/java/net/openhft/chronicle/threads/MonitorEventLoop.java
@@ -25,7 +25,6 @@ import org.jetbrains.annotations.NotNull
 import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;
 
-import javax.xml.ws.WebServiceException;
 import java.io.Closeable;
 import java.util.ArrayList;
 import java.util.List;
@@ -120,7 +119,8 @@ public class MonitorEventLoop implements
 }
 
 @Override
-public void close() throws WebServiceException {
+public void close() {
+stop();
 service.shutdown();
 try {
 if (!service.awaitTermination(100, TimeUnit.MILLISECONDS))

Bug#834298: nis: problem appears to be in invocation in /etc/init.d/nis

[Joe Pfeiffer]

Package: nis
Version: 3.17.1-3+b1
Followup-For: Bug #834298

The problem appears to be in line 172 of /etc/init.d/nis:
--exec ${NET}/ypbind -- $broadcast ${YPBINDARGS}

If I execute this by hand (for my environment, which does not use
-broadcast and has empty YPBINDARGS), ie

/usr/sbin/ypbind --

I get the response

babs:~# ypbind --
Usage:
ypbind [-broadcast | -ypset | -ypsetme] [-f configfile]
  [-no-ping] [-broken-server] [-local-only] [-i ping-interval]
  [-r rebind-interval] [-debug] [-verbose] [-n | -foreground]
ypbind -c [-f configfile]
ypbind --version

If I delete the -- from the invocation it works.

Bug#882934: Crash debugging

[Joe]

On Fri, 16 Mar 2018 16:42:43 -0700
Dima Kogan <d...@secretsauce.net> wrote:

> Let's move this back to the bug list.
> 
> Thanks for the debugging traces. I didn't see any smoking gun, but
> there're things I'd like to follow-up on to isolate the issue and then
> to hopefully allow me to reproduce it.
> 
> 1. You have a customized gtk configuration that uses a theme no longer
>in Debian. Can you please try to rename your ~/.gtkrc-2.0 file to
>something else to see if that makes the crash go away? I'm guessing
>this doesn't matter, but checking would be good.

No change.

> 
> 2. The crash makes me suspect that something related to graphics is at
>fault. You have a radeon graphics card of some sort it looks like,
>which could explain why I can't reproduce (my hardware is
> different). How old/new is your graphics drivers? Can you try to run
> pcb without hardware acceleration? You can do this with
> 
>  LIBGL_ALWAYS_SOFTWARE=true pcb-gtk

Yes, that fixes it. A quick test suggests it is running OK.

> 
>Also please try
> 
>  LIBGL_ALWAYS_INDIRECT=true pcb-gtk
>

No, still crashes.
 
> Hopefully one of these resolves the crash, which would tell us where
> to look next.
> 
> Thanks!

OK, it does look like the graphics driver, then. I don't play games, so
I've never worried about it, and it looks like I'm using the
xserver-xorg-video-radeon driver. firmware-amd-graphics is installed.

Should I try getting hold of the AMD binary driver? It's onboard
graphics on a Gigabyte MB, about seven years old.

Best regards,
Joe

Bug#882934: [Pkg-electronics-devel] Bug#882934: Segfault on window operations

[Joe]

On Wed, 6 Dec 2017 12:54:53 +0100
أحمد المحمودي <aelmahmo...@users.sourceforge.net> wrote:

> Please try using pcb-gtk using a new user. I suspect that this might
> be related to some setting or maybe GTK theme.
> 

I created a new user. PCB closes immediately after the window opens.
With my usual user, it does not close immediately, but only after a
redraw in the working area. I am assuming that for the new user, there
is some kind of welcome display which causes redraw and triggers the
segfault, but it is too fast to see. This is Debian unstable, with a
completely default user and Xfce. I do not think I have ever changed
the default theming on my normal user.

I tried running in gdb, but I'm not really familiar with debugging, and
I wasn't able to get anywhere. I loaded as many symbol files as I could
find in the dependencies of pcb-gtk, there are five threads running at
the time of failure, and the other threads have backtraces with
filenames. The thread which is failing has a backtrace with no
filenames.

Running under gdb, I can see that the window decorations redraw
correctly, it is a redraw in the working area which does not work, and
which triggers the segfault. I can resize the window smaller OK, but
not larger. I can move another window over the sidebar, status bar and
menu area, everywhere except the working area.

Best regards,
Joe

Bug#882934: Segfault on window operations

[Joe]

A bit more information: this is some kind of problem in my GTK
environment, but I have so far not found any other affected
application. I have installed PCB versions 4.0.2-4, 4.0.2-1 and
20140316-3.1 and all have the same problem. I used PCB a fair bit until
June this year, and I have never seen this happen before, so something
has changed since then. This is a large unstable installation, upgraded
almost daily.

I don't know how to proceed from here: I have an old unstable on i386
with 20140316-3.1 installed which is fine. I'm a bit reluctant to bring
it up to date. How do I troubleshoot this problem?

Bug#882934: pcb: Segfault on window operations

[Joe Rowan]

Package: pcb
Version: 1:4.0.2-4
Severity: grave
Justification: renders package unusable

Used PCB for the first time since early June, so I don't know when this problem 
began. Most movement or closing of program windows causes a segfault.
Here are the last few, in case there is anything useful in the numbers;

Nov 27 18:19:51 jresid kernel: [ 8849.901223] pcb[17889]: segfault at 12c ip 
7fec3e52b333 sp 7ffebc690060 error 4
Nov 27 18:20:32 jresid kernel: [ 8890.836129] pcb[17897]: segfault at 1f08 ip 
7f783385c333 sp 7ffca6825ea0 error 4
Nov 27 18:56:53 jresid kernel: [11072.665606] pcb[23727]: segfault at 298 ip 
7f38767b6333 sp 7ffcd2d92100 error 4
Nov 27 18:58:49 jresid kernel: [11188.635560] pcb[23738]: segfault at 110 ip 
7f5fa0d3c333 sp 7da2f3c0 error 4
Nov 27 19:01:59 jresid kernel: [11377.840046] pcb[23783]: segfault at 6a4 ip 
7f5d78eaf333 sp 7fffd2435560 error 4
Nov 27 19:28:10 jresid kernel: [   66.940661] pcb[1426]: segfault at 164 ip 
7f90fb674333 sp 7ffdfadf0ea0 error 4
Nov 27 19:39:14 jresid kernel: [  376.254327] pcb[4231]: segfault at 340 ip 
7fa198d60333 sp 7ffd2488b2c0 error 4

I tried completely reinstalling, no change.

I tried removing pcb-gtk and installing pcb-lesstif. The program is now stable, 
but I've used the GTK version for years, and I don't think I can get used to 
the Lesstif version.
This appears to be a GTK problem of some kind, but nobody else seems to have 
it. 
What can I try to provide further information?

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pcb depends on:
ii  pcb-common  1:4.0.2-4
ii  pcb-gtk 1:4.0.2-4

pcb recommends no packages.

pcb suggests no packages.

-- no debconf information

Bug#880308:

[Joe Distin]

Please take me out of your mailing list thank you

Bug#880308: CLA Diet is the end of obesity CMDJ

[Joe Distin]

Please delete me from your mailing list thank you

On Nov 10, 2017 1:52 PM, "CLA Diet"  wrote:

>
> 
>
> 
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 2017-10-30, Lucas Nussbaum wrote: >> /bin/bash ../../libtool
> --mode=install /usr/bin/install -c libvnc.la '/<>/tigervnc-1.7.0+dfsg/
> debian/tmp//lib/xorg/modules/extensions' >> libtool: install:
> /usr/bin/install -c .libs/libvnc.so /<>/tigervnc-1.7.0+dfsg/
> debian/tmp//lib/xorg/modules/extensions/libvnc.so ... >> dh_install:
> Cannot find (any matches for) "usr/lib/xorg/modules/extensions/libvnc.so"
> (tried in ., debian/tmp) >> >> dh_install: tigervnc-xorg-extension missing
> files: usr/lib/xorg/modules/extensions/libvnc.so >> dh_install: missing
> files, aborting >> /usr/share/cdbs/1/rules/debhelper.mk:233: recipe for
> target 'binary-install/tigervnc-xorg-extension' failed >> make: *** Error
> 25 The install target appears to be dropping /usr for this particular file
> on sid, but rebuilding the same sources on stretch /usr is included... This
> suggests a deeper problem, such as something in the build process ignoring
> CMAKE_INSTALL_PREFIX ... but can be worked around in the package: diff
> --git a/debian/tigervnc-xorg-extension.install 
> b/debian/tigervnc-xorg-extension.install
> index 8d6fffa..f74dabd 100644 --- a/debian/tigervnc-xorg-extension.install
> +++ b/debian/tigervnc-xorg-extension.install @@ -1 +1 @@
> -usr/lib/xorg/modules/extensions/libvnc.so usr/lib/xorg/modules/extensions
> +lib/xorg/modules/extensions/libvnc.so usr/lib/xorg/modules/extensions
> I've only test that the package successfully builds with this patch; I
> haven't tested that it actually works. live well, vagrant

Bug#868700: claws-mail: Segfaults when selected from application menu or command line

[Joe]

On Sun, 30 Jul 2017 12:33:36 +0200
Ricardo Mones <mo...@debian.org> wrote:


> 
> Once you have the debug archive just install claws-mail-dbgsym package
> and repeat the gdb steps and post back the output.
> 

Hold everything: I have an old unstable i386 installation on a portable 
hard drive. I haven't used it for a long time, and I don't normally use
it with this netbook, but it will boot, and today I did a full upgrade
and then tried claws-mail: it worked perfectly. It's a larger installation,
but the claws-mail dependencies are the same versions as for the netbook
native installation.

So presumably the netbook installation has a broken package, maybe with a 
corrupt file. It isn't claws-mail itself, I've reinstalled that.

Sorry to bother you. I'd completely forgotten this old drive, or I'd have
tried this experiment much sooner. 

Best regards,
Joe

Bug#868700: claws-mail: Segfaults when selected from application menu or command line

[Joe]

On Sat, 22 Jul 2017 23:14:15 +0200
Ricardo Mones <mo...@debian.org> wrote:

> On Tue, Jul 18, 2017 at 09:22:12PM +0100, Joe wrote:
> > On Tue, 18 Jul 2017 18:57:24 +0200
> > Ricardo Mones <mo...@debian.org> wrote:  
> [...]
> > > Does this crash happen when you start claws-mail from command
> > > line?  
> > 
> > Yes, this output was from a command line.
> >   
> > > 
> > > If it does, can you install debug packages¹ and get the backtrace
> > > when running inside gdb²?
> > >   
> > 
> > Hope this helps:
> > 
> > joe@jrenet:~$ gdb claws-mail  
> [...[
> > (gdb) run  
> [...[
> > Program received signal SIGSEGV, Segmentation fault.
> > __strchr_sse2 () at ../sysdeps/i386/i686/multiarch/strchr-sse2.S:90
> > 90  ../sysdeps/i386/i686/multiarch/strchr-sse2.S: No such
> > file or directory. (gdb)   
> 
> You forgot to type "thread apply all bt" command at this point, and
> post the backtraces which are printed after it ;-)

OK, I'm not a developer, I had to look up how to make a program work in
gdb. I've included the whole output, in case the earlier numbers were
different for this run:

(gdb) run
Starting program: /usr/bin/claws-mail 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".

(claws-mail:1691): Claws-Mail-WARNING **: Wrong column position

(claws-mail:1691): Claws-Mail-CRITICAL **: imap_item_get_path:
assertion 'folder_path != NULL' failed folder.c:3967 Condition path !=
NULL failed traceback:
0:  /usr/bin/claws-mail() [0x80cf2f8]
1:  /usr/bin/claws-mail() [0x80d275f]
2:  /usr/bin/claws-mail(folder_item_get_msg_list+0x7f) [0x80d311f]
3:  /usr/bin/claws-mail() [0x80dc881]
4:  /usr/bin/claws-mail() [0x80dd017]
5:  /usr/bin/claws-mail(gtk_sctree_insert_gnode+0x136) [0x828f386]
6:  /usr/bin/claws-mail(gtk_sctree_insert_gnode+0x1f7) [0x828f447]
7:  /usr/bin/claws-mail(gtk_sctree_insert_gnode+0x1f7) [0x828f447]
8:  /usr/bin/claws-mail(folderview_set+0x25c) [0x80df4bc]
9:  /usr/bin/claws-mail() [0x80df701]
10: /usr/bin/claws-mail() [0x822de41]
11: /lib/i386-linux-gnu/libglib-2.0.so.0(g_hook_list_marshal+0x67)
[0xb72d7847] 12:/usr/bin/claws-mail(hooks_invoke+0x64)
[0x822e554] 13: /usr/bin/claws-mail(folder_add+0xc1) [0x80cc151]
14: /usr/bin/claws-mail(folder_read_list+0x79) [0x80d0959]
15: /usr/bin/claws-mail(main+0xc65) [0x80839d5]
16: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6)
[0xb69e9276] 17:/usr/bin/claws-mail() [0x80857ea]


(claws-mail:1691): Claws-Mail-CRITICAL **: imap_item_get_path:
assertion 'folder_path != NULL' failed folder.c:3991 Condition path !=
NULL failed traceback:
0:  /usr/bin/claws-mail() [0x80cf608]
1:  /usr/bin/claws-mail() [0x80d276c]
2:  /usr/bin/claws-mail(folder_item_get_msg_list+0x7f) [0x80d311f]
3:  /usr/bin/claws-mail() [0x80dc881]
4:  /usr/bin/claws-mail() [0x80dd017]
5:  /usr/bin/claws-mail(gtk_sctree_insert_gnode+0x136) [0x828f386]
6:  /usr/bin/claws-mail(gtk_sctree_insert_gnode+0x1f7) [0x828f447]
7:  /usr/bin/claws-mail(gtk_sctree_insert_gnode+0x1f7) [0x828f447]
8:  /usr/bin/claws-mail(folderview_set+0x25c) [0x80df4bc]
9:  /usr/bin/claws-mail() [0x80df701]
10: /usr/bin/claws-mail() [0x822de41]
11: /lib/i386-linux-gnu/libglib-2.0.so.0(g_hook_list_marshal+0x67)
[0xb72d7847] 12:/usr/bin/claws-mail(hooks_invoke+0x64)
[0x822e554] 13: /usr/bin/claws-mail(folder_add+0xc1) [0x80cc151]
14: /usr/bin/claws-mail(folder_read_list+0x79) [0x80d0959]
15: /usr/bin/claws-mail(main+0xc65) [0x80839d5]
16: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6)
[0xb69e9276] 17:/usr/bin/claws-mail() [0x80857ea]

msgcache.c:586 Condition cache_file != NULL failed
traceback:
0:  /usr/bin/claws-mail(msgcache_read_cache+0xd7b) [0x812e3cb]
1:  /usr/bin/claws-mail() [0x80d2783]
2:  /usr/bin/claws-mail(folder_item_get_msg_list+0x7f) [0x80d311f]
3:  /usr/bin/claws-mail() [0x80dc881]
4:  /usr/bin/claws-mail() [0x80dd017]
5:  /usr/bin/claws-mail(gtk_sctree_insert_gnode+0x136) [0x828f386]
6:  /usr/bin/claws-mail(gtk_sctree_insert_gnode+0x1f7) [0x828f447]
7:  /usr/bin/claws-mail(gtk_sctree_insert_gnode+0x1f7) [0x828f447]
8:  /usr/bin/claws-mail(folderview_set+0x25c) [0x80df4bc]
9:  /usr/bin/claws-mail() [0x80df701]
10: /usr/bin/claws-mail() [0x822de41]
11: /lib/i386-linux-gnu/libglib-2.0.so.0(g_hook_list_marshal+0x67)
[0xb72d7847] 12:/usr/bin/claws-mail(hooks_invoke+0x64)
[0x822e554] 13: /usr/bin/claws-mail(folder_add+0xc1) [0x80cc151]
14: /usr/bin/claws-mail(folder_read_list+0x79) [0x80d0959]
15: /usr/bin/claws-mail(main+0xc65) [0x80839d5]
16: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6)
[0xb69e9276] 17:   

Bug#868700: claws-mail: Segfaults when selected from application menu or command line

[Joe]

Package: claws-mail
Version: 3.15.0-2+b1
Severity: grave
Justification: renders package unusable

Since upgrade to 3.15.0-2, claws-mail segfaults when I try to run it:

joe@jrenet:~$ claws-mail

(claws-mail:3276): Claws-Mail-CRITICAL **: imap_item_get_path: assertion 
'folder_path != NULL' failed
folder.c:3967 Condition path != NULL failed
traceback:
0:  claws-mail() [0x80cf2f8]
1:  claws-mail() [0x80d275f]
2:  claws-mail(folder_item_get_msg_list+0x7f) [0x80d311f]
3:  claws-mail() [0x80dc881]
4:  claws-mail() [0x80dd017]
5:  claws-mail(gtk_sctree_insert_gnode+0x136) [0x828f386]
6:  claws-mail(gtk_sctree_insert_gnode+0x1f7) [0x828f447]
7:  claws-mail(gtk_sctree_insert_gnode+0x1f7) [0x828f447]
8:  claws-mail(folderview_set+0x25c) [0x80df4bc]
9:  claws-mail() [0x80df701]
10: claws-mail() [0x822de41]
11: /lib/i386-linux-gnu/libglib-2.0.so.0(g_hook_list_marshal+0x67) 
[0xb6a7f847]
12: claws-mail(hooks_invoke+0x64) [0x822e554]
13: claws-mail(folder_add+0xc1) [0x80cc151]
14: claws-mail(folder_read_list+0x79) [0x80d0959]
15: claws-mail(main+0xc65) [0x80839d5]
16: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6) [0xb6191276]
17: claws-mail() [0x80857ea]


(claws-mail:3276): Claws-Mail-CRITICAL **: imap_item_get_path: assertion 
'folder_path != NULL' failed
folder.c:3991 Condition path != NULL failed
traceback:
0:  claws-mail() [0x80cf608]
1:  claws-mail() [0x80d276c]
2:  claws-mail(folder_item_get_msg_list+0x7f) [0x80d311f]
3:  claws-mail() [0x80dc881]
4:  claws-mail() [0x80dd017]
5:  claws-mail(gtk_sctree_insert_gnode+0x136) [0x828f386]
6:  claws-mail(gtk_sctree_insert_gnode+0x1f7) [0x828f447]
7:  claws-mail(gtk_sctree_insert_gnode+0x1f7) [0x828f447]
8:  claws-mail(folderview_set+0x25c) [0x80df4bc]
9:  claws-mail() [0x80df701]
10: claws-mail() [0x822de41]
11: /lib/i386-linux-gnu/libglib-2.0.so.0(g_hook_list_marshal+0x67) 
[0xb6a7f847]
12: claws-mail(hooks_invoke+0x64) [0x822e554]
13: claws-mail(folder_add+0xc1) [0x80cc151]
14: claws-mail(folder_read_list+0x79) [0x80d0959]
15: claws-mail(main+0xc65) [0x80839d5]
16: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6) [0xb6191276]
17: claws-mail() [0x80857ea]

msgcache.c:586 Condition cache_file != NULL failed
traceback:
0:  claws-mail(msgcache_read_cache+0xd7b) [0x812e3cb]
1:  claws-mail() [0x80d2783]
2:  claws-mail(folder_item_get_msg_list+0x7f) [0x80d311f]
3:  claws-mail() [0x80dc881]
4:  claws-mail() [0x80dd017]
5:  claws-mail(gtk_sctree_insert_gnode+0x136) [0x828f386]
6:  claws-mail(gtk_sctree_insert_gnode+0x1f7) [0x828f447]
7:  claws-mail(gtk_sctree_insert_gnode+0x1f7) [0x828f447]
8:  claws-mail(folderview_set+0x25c) [0x80df4bc]
9:  claws-mail() [0x80df701]
10: claws-mail() [0x822de41]
11: /lib/i386-linux-gnu/libglib-2.0.so.0(g_hook_list_marshal+0x67) 
[0xb6a7f847]
12: claws-mail(hooks_invoke+0x64) [0x822e554]
13: claws-mail(folder_add+0xc1) [0x80cc151]
14: claws-mail(folder_read_list+0x79) [0x80d0959]
15: claws-mail(main+0xc65) [0x80839d5]
16: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6) [0xb6191276]
17: claws-mail() [0x80857ea]


(claws-mail:3276): Claws-Mail-CRITICAL **: imap_item_get_path: assertion 
'folder_path != NULL' failed
Segmentation fault
joe@jrenet:~$ 



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

Kernel: Linux 4.11.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages claws-mail depends on:
ii  libatk1.0-0  2.24.0-1
ii  libc62.24-12
ii  libcairo21.14.10-1
ii  libcompfaceg11:1.5.2-5+b2
ii  libcurl3-gnutls  7.52.1-5
ii  libdb5.3 5.3.28-13
ii  libdbus-1-3  1.10.20-1
ii  libdbus-glib-1-2 0.108-2
ii  libenchant1c2a   1.6.0-11+b2
ii  libetpan20   1.8.0-1
ii  libexpat12.2.2-2
ii  libfontconfig1   2.12.3-0.2
ii  libfreetype6 2.8-0.2
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.52.3-1
ii  libgnutls30  3.5.14-2
ii  libgtk2.0-0  2.24.31-2
ii  libice6  2:1.0.9-2
ii  libldap-2.4-22.4.44+dfsg-8
ii  liblockfile1 1.14-1+b1
ii  libpango-1.0-0   1.40.6-1
ii  libpangocairo-1.0-0  1.40.6-1
ii  libpangoft2-1.0-01.40.6-1
ii  libpisock9   0.12.5-dfsg-2+b3
ii  librsvg2-2   2.40.16-1+b1
ii  libsasl2-2   2.1.27~101-g0780600+dfsg-3
ii  libsm6   2:1.2.2-1+b3
ii  xdg-utils1.1.1-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages claws-mail recommends:
ii  aspell-en [aspell-dictionary]  2017.01.22-0-0.1
ii  claws-mail-i18n

Bug#848178: Close bug

[joe belisle]

Phillip,

Thanks for your quick reply.  It was as you had said, that
libtesseract3 had not been updated.  This must be a problem with apt-
get as I had just updated using it before I sent the bug report in and
libtesseract3 had not been updated as I wanted to make sure that the
bug had not already been fixed.

I've been using apt-get because aptitude has been failing me for at
least a year and I'd just given up on using it.  It would get to the
point of checking which packages needed to be updated and then just run
on for a half hour or so until it would finally stall and I've have to
close it using Ctrl-C.  

Then, miracle of miracles today aptitude worked when I tried it after
realizing apt-get wasn't updating all the packages.  It updated over
300 packages that apt-get has been missing. 

Sorry to have sent you more work on such a stupid basis.

Joe

Bug#848178: gimagereader fails to start

[joe belisle]

Package: gimagereader
Version: 3.2.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

gimagereader fails to start.  If started from the bash prompt it gives the
following error: gimagereader-gtk: symbol lookup error: gimagereader-gtk:
undefined symbol: _ZN9tesseract11TessBaseAPI13AnalyseLayoutEv

I reported a very similar bug a year or so ago and it was simply a failure to
have updated changed symbols.



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gimagereader depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  libatkmm-1.6-1v5 2.24.2-2
ii  libc62.24-7
ii  libcairomm-1.0-1v5   1.12.0-1+b1
ii  libfontconfig1   2.11.0-6.7
ii  libgcc1  1:6.2.1-5
ii  libglib2.0-0 2.50.2-2
ii  libglibmm-2.4-1v52.50.0-1
ii  libgomp1 6.2.1-5
ii  libgtk-3-0   3.22.4-1
ii  libgtkmm-3.0-1v5 3.22.0-1
ii  libgtksourceviewmm-3.0-0v5   3.18.0-1
ii  libgtkspellmm-3.0-0v53.0.5+dfsg-1
ii  libjpeg62-turbo  1:1.5.1-2
ii  libjson-glib-1.0-0   1.2.2-1
ii  libpangomm-1.4-1v5   2.40.1-3
ii  libpodofo0.9.4   0.9.4-3
ii  libpoppler-glib8 0.44.0-3
ii  libsane  1.0.25-2+b1
ii  libsigc++-2.0-0v52.10.0-1
ii  libstdc++6   6.2.1-5
ii  libtesseract33.04.00-5
ii  libxml++2.6-2v5  2.40.1-1

gimagereader recommends no packages.

gimagereader suggests no packages.

-- no debconf information

Bug#834624: vm-bonus-el: vm-bogofilter.el doesn't byte-compile

[Joe Pfeiffer]

Package: vm-bonus-el
Version: 35.2+nmu1
Severity: serious

Attempting to install, byte-compilation fails.  The compilation log in
/tmp/ contains

emacs24 -q -no-site-file --no-site-file -batch -l path.el -f batch-byte-compile 
vm-bogofilter.el
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable vm-supported-sort-keys)
Eager macro-expansion failure: (void-variable 

Bug#802287: kdenlive: Kdenlive for Debian 8 fails to load

[Joe McEntire]

Package: kdenlive
Version: 0.9.2-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
Attempted to install and run kdenlive

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Installed kdenlive, kdenlive fails to start once I clicked the icon.  I
then rolled back to the wheezy version of the packages kdenlive, kdenlive-data,
libmlt++3, libmlt5, melt holding these packages at the wheezy version level

   * What was the outcome of this action?
With the Jessie version the package fails to run.  kdenlive will not
start
With the Wheezy version the package works as expected.

The occurs on both my desktop and my laptop.  I cannot get the Jessie
version to work no matter what I try.

   * What outcome did you expect instead?
Kdenlive should launch as expected once installed.

*** End of the template - remove these template lines ***



-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/24 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kdenlive depends on:
ii  ffmpeg7:2.6.1-1~wheezy1
ii  kde-runtime   4:4.14.2-2
pn  kdenlive-data 
ii  libc6 2.19-18+deb8u1
ii  libgcc1   1:4.9.2-10
ii  libgl1-mesa-glx [libgl1]  10.3.2-1+deb8u1
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libkdecore5   4:4.14.2-5
ii  libkdeui5 4:4.14.2-5
ii  libkio5   4:4.14.2-5
ii  libknewstuff3-4   4:4.14.2-5
ii  libknotifyconfig4 4:4.14.2-5
ii  libkrossui4   4:4.14.2-5
pn  libmlt++3 
pn  libmlt5   
ii  libnepomuk4   4:4.14.2-5
ii  libqjson0 0.8.1-3
ii  libqt4-dbus   4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-network4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-opengl 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-script 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-svg4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-xml4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtcore44:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libsolid4 4:4.14.2-5
ii  libsoprano4   2.9.4+dfsg-1.1
ii  libstdc++64.9.2-10
ii  libx11-6  2:1.6.2-3
ii  libxau6   1:1.0.8-1
ii  libxdmcp6 1:1.1.1-1+b1
ii  libxext6  2:1.3.3-1
pn  melt  

Versions of packages kdenlive recommends:
ii  dvdauthor0.7.0-1.3
ii  dvgrab   3.5-2+b2
ii  frei0r-plugins   1.4-3
ii  genisoimage  9:1.1.11-3
ii  recordmydesktop  0.3.8.1+svn602-1+b1
ii  swh-plugins  0.4.15+1-7

kdenlive suggests no packages.

-- no debconf information

Bug#777511: linux-image-3.16: md: bug with re-adding a partially recovered device to a mirror

[Joe Lawrence]

Stratus encountered a similar MD RAID1 bug here:

  https://www.marc.info/?l=linux-raid=143619993921782=4

and posted a potential fix here:

  https://www.marc.info/?l=linux-raid=143811224629816=4

Any feedback on the upstream report/patch would be greatly appreciated.

Thanks,

-- Joe

Bug#794489: gimagereader fails to open

[joe belisle]

Package: gimagereader
Version: 3.1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

gimagereader fails to open and reports the following error when called from a
bash prompt.

gimagereader-gtk: symbol lookup error: gimagereader-gtk: undefined symbol:
_ZN9tesseract11TessBaseAPI13AnalyseLayoutEv



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gimagereader depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  libc62.19-19
ii  libcairomm-1.0-1 1.10.0-1.1
ii  libgcc1  1:5.1.1-14
ii  libglib2.0-0 2.44.1-1.1
ii  libglibmm-2.4-1c2a   2.44.0-1
ii  libgomp1 5.1.1-14
ii  libgtk-3-0   3.16.6-1
ii  libgtkmm-3.0-1   3.16.0-1
ii  libgtksourceviewmm-3.0-0 3.12.0-1
ii  libgtkspellmm-3.0-0  3.0.3+dfsg-1
ii  libpangomm-1.4-1 2.36.0-1
ii  libpoppler-glib8 0.26.5-3
ii  libsane  1.0.24-13
ii  libsigc++-2.0-0c2a   2.4.1-1
ii  libstdc++6   5.1.1-14
ii  libtesseract33.04.00-5

gimagereader recommends no packages.

gimagereader 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#788273: lime-forensics-dkms: fails to build for Linux 4.0

[Joe Sylve]

This should now be fixed in the latest commit (tag v1.5)


On Tue, 09 Jun 2015 23:20:36 +0200 Andreas Beckmann a...@debian.org wrote:

 Package: lime-forensics-dkms

 Version: 1.4-2

 Severity: serious

 Tags: sid stretch

 User: debian...@lists.debian.org

 Usertags: piuparts



 from make.log:



 DKMS make.log for lime-forensics-1.4-2 for kernel 4.0.0-2-586 (x86_64)

 Tue Jun  9 21:18:17 UTC 2015

 make: Entering directory '/usr/src/linux-headers-4.0.0-2-586'

   LD  /var/lib/dkms/lime-forensics/1.4-2/build/built-in.o

   CC [M]  /var/lib/dkms/lime-forensics/1.4-2/build/tcp.o

 /var/lib/dkms/lime-forensics/1.4-2/build/tcp.c: In function
'write_vaddr_tcp':

 /var/lib/dkms/lime-forensics/1.4-2/build/tcp.c:133:9: error: unknown
field 'msg_iov' specified in initializer

   struct msghdr msg  = { .msg_iov = iov, .msg_iovlen = 1 };

  ^

 /var/lib/dkms/lime-forensics/1.4-2/build/tcp.c:133:9: error: unknown
field 'msg_iovlen' specified in initializer

 /usr/src/linux-headers-4.0.0-2-common/scripts/Makefile.build:263: recipe
for target '/var/lib/dkms/lime-forensics/1.4-2/build/tcp.o' failed

 make[3]: *** [/var/lib/dkms/lime-forensics/1.4-2/build/tcp.o] Error 1

 /usr/src/linux-headers-4.0.0-2-common/Makefile:1407: recipe for target
'_module_/var/lib/dkms/lime-forensics/1.4-2/build' failed

 make[2]: *** [_module_/var/lib/dkms/lime-forensics/1.4-2/build] Error 2

 Makefile:145: recipe for target 'sub-make' failed

 make[1]: *** [sub-make] Error 2

 Makefile:8: recipe for target 'all' failed

 make: *** [all] Error 2

 make: Leaving directory '/usr/src/linux-headers-4.0.0-2-586'





 Andreas

Bug#781132: reportbug: GTK version sent email to mepis

[joe belisle]

Package: reportbug
Version: 6.6.3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I was reporting a bug in xiphos using the GTK interface and the bug was sent to 
mepis, not the Debian bug tracker.  The email address was not valid too, for 
the email could not be delivered.


-- Package-specific info:
** Environment settings:
INTERFACE=text

** /home/garyk/.reportbugrc:
reportbug_version 6.6.0
mode standard
ui text
realname joe belisle
email joebelisl...@gmail.com
smtphost smtp.googlemail.com
smtpuser joebelisle32
smtptls

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

Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages reportbug depends on:
ii  apt   1.0.9.7
ii  python2.7.8-4
ii  python-reportbug  6.6.3
pn  python:anynone

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail none
pn  debconf-utils  none
pn  debsumsnone
pn  dlocatenone
pn  emacs23-bin-common | emacs24-bin-commonnone
ii  exim4  4.84-8
ii  exim4-daemon-light [mail-transport-agent]  4.84-8
ii  file   1:5.22+15-2
ii  gnupg  1.4.18-7
ii  python-gtk22.24.0-4
pn  python-gtkspellnone
pn  python-urwid   none
ii  python-vte 1:0.28.2-5
ii  xdg-utils  1.1.0~rc1+git20111210-7.4

Versions of packages python-reportbug depends on:
ii  apt   1.0.9.7
ii  python-debian 0.1.25
ii  python-debianbts  1.12
pn  python:anynone

python-reportbug 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#777665: Simple fix attached

[Joe Healy]

Tags: + patch

I've attached a patch for a direct fix.

I'm delaying applying it for 24-48 hours until I hear from upstream if
salt-common should require python-msgpack or not.

A fair bit of the code implies python-msgpack should not be needed for
local (ie salt-call) use.

Joe
diff --git a/debian/control b/debian/control
index 256af75..100f03e 100644
--- a/debian/control
+++ b/debian/control
@@ -25,6 +25,7 @@ Depends: ${python:Depends},
  python-jinja2,
  python-apt,
  python-yaml,
+ python-msgpack,
  python-pkg-resources
 Recommends: lsb-release,
 python-mako

Bug#771863: [PKG-Openstack-devel] [ovs-dev] Bug#771863: Bug#771863: Service does not start or parse interfaces correctly

[Joe Stringer]

On 23 December 2014 at 03:12, Fabio Fantoni fabio.fant...@m2r.biz wrote:
 For have it working I had to do service networking restart.
 I found probably final solution applying also this patch:
 http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=commitdiff;h=9a8b5cc1a3d941c0e33f3f5b5ac260a35a8130af
 Even if seems not good in some cases.
 I don't know if also Jessie have this problem but probably yes. If yes I
 think this bug is only partially solves with 2.3.0+git20140819-3.

FYI, the above URL points to an outdated git and may go away; OVS has
migrated to GitHub:
https://github.com/openvswitch/ovs/commit/9a8b5cc1a3d941c0e33f3f5b5ac260a35a8130af

If you accessed the above URL via the OVS website somehow, please get
in touch with me off-list so we can fix the links to point to the
correct location.


 I had also another start problem probably not related to this, after some
 hours xenbr0 stopped to working.
 I not found any useful errors about in logs, only some strange thing, in
 ifconfig xenbr0 was without the static ip, in syslog keep tried to acquire
 configuration with dhcp failing (dhcp server present and working in lan).
 After service networking restart was working again but I not understand
 was happen and why :(
 Someone have any idea about?

I see that Guru has suggested a possible fix; if that does not address
your issue, you could send your question to disc...@openvswitch.org or
open a fresh debian bug (or both!). It would be helpful to provide
related logs (ovs-vswitchd.log and/or syslog), OVS versions and OVS
configuration.

Thanks,
Joe


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

Bug#771863: [ovs-dev] Bug#771863: Service does not start or parse interfaces correctly

[Joe Stringer]

On 18 December 2014 at 01:00, Fabio Fantoni fabio.fant...@m2r.biz wrote:
 One maintainer or debian developer can do a new build of ovs with the fix
 available in 2.3.1 please?

   * Version 2.3.0+git20140819-2 of openvswitch is marked for
 autoremoval from testing on 2015-01-15.
   * It is affected by RC bug #771863 https://bugs.debian.org/771863.


 Without this fix openvswitch will be removed from Jessie and I think this
 would be a bad thing.

 Thanks for any reply and sorry for my bad english.

Ben usually takes care of this sort of thing, but he is out on holiday
through to Christmas.

Simon, would you be able to take care of this?


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

Bug#771863: [ovs-dev] Bug#771863: Bug#771863: Service does not start or parse interfaces correctly, updating severity

[Joe Stringer]

On 15 December 2014 at 10:21, Gurucharan Shetty shet...@nicira.com wrote:
 On Sat, Dec 13, 2014 at 2:03 AM, Stig Sandbeck Mathisen s...@debian.org 
 wrote:
 I would like to clarify that 2.3.1 does get rid of the check on
 $RUNLEVEL which was the original bug description.

 That's great, thanks. :)

 I probably should treat this as a separate bug. Would you like me to
 file a new bug for it in the Debian BTS, in addition to submitting an
 upstream patch?

snip

I agree that this should be treated as a separate bug, yes please (I'm
just following up as it wasn't clear to me whether you're working on
this or not).


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

Bug#770174: [Pkg-salt-team] Bug#770174: salt-common: service module doesn't work for init scripts

[Joe Healy]

Thanks Julien,

I'll apply this fix and upload tonight. I'll also look at the other fixes
made upstream on the 2014.1 branch.

Joe

On Wed, Nov 19, 2014 at 10:43 PM, Julien Cristau julien.cris...@logilab.fr
wrote:

 Package: salt-common
 Version: 2014.1.13+ds-1
 Severity: grave
 Tags: patch upstream fixed-upstream
 Justification: renders package unusable

 Hi,

 when booting with systemd, the service module is provided by
 salt/modules/systemd.py, which only considers native systemd units in
 its get_all function, not services provided by init scripts.  This
 breaks the service state.

 The fix is in upstream commits
 90bece1faa1862465e97f7caf262c65cd84583ff and
 968b26f45351d790a9fa2afd9bbd6c5bb31f13d5, so basically:

 diff --git a/salt/modules/systemd.py b/salt/modules/systemd.py
 --- a/salt/modules/systemd.py
 +++ b/salt/modules/systemd.py
 @@ -72,6 +74,28 @@ def _systemctl_cmd(action, name):
  return 'systemctl {0} {1}'.format(action, _canonical_unit_name(name))


 +def _get_all_units():
 +'''
 +Get all units and their state. Units ending in .service
 +are normalized so that they can be referenced without a type suffix.
 +'''
 +rexp = re.compile(r'(?m)^(?Pname.+)\.(?Ptype' +
 +  '|'.join(VALID_UNIT_TYPES) +
 +  r')\s+loaded\s+(?Pactive[^\s]+)')
 +
 +out = __salt__['cmd.run_stdout'](
 +'systemctl --all --full --no-legend --no-pager list-units | col
 -b'
 +)
 +
 +ret = {}
 +for match in rexp.finditer(out):
 +name = match.group('name')
 +if match.group('type') != 'service':
 +name += '.' + match.group('type')
 +ret[name] = match.group('active')
 +return ret
 +
 +
  def _get_all_unit_files():
  '''
  Get all unit files and their state. Unit files ending in .service
 @@ -173,7 +197,7 @@ def get_all():

  salt '*' service.get_all
  '''
 -return sorted(_get_all_unit_files().keys())
 +return sorted(set(_get_all_units().keys() +
 _get_all_unit_files().keys()))


  def available(name):


 There are a few other fixes in that file that might be worth
 considering, but at least the above is I think necessary for salt to
 be in decent shape for jessie.

 Cheers,
 Julien
 --
 Julien Cristau  julien.cris...@logilab.fr
 Logilab http://www.logilab.fr/
 Informatique scientifique  gestion de connaissances

 ___
 pkg-salt-team mailing list
 pkg-salt-t...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-salt-team

Bug#754347: Crash log

[Joe Steeve]

The entire crash log is in:
https://bugzilla.gnome.org/show_bug.cgi?id=732455

-- 
Joe Steeve
HiPro IT Solutions Pvt. Ltd.
http://hipro.co.in

Bug#741522: [Pkg-salt-team] Bug#741522: python-libcloud in sid

[Joe Healy]

Yes, It can, I'll close it off.


Thanks,


Joe
On Jun 17, 2014 8:06 PM, Marcin Kulisz deb...@kulisz.net wrote:

 Looks like in jessie and sid we already have python-libcloud_0.14.1-1, so
 this
 issue should go.
 --

 |_|0|_|  |
 |_|_|0| Heghlu'Meh QaQ jajVam  |
 |0|0|0|  kuLa -  |

 gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3
 3DF1 A4DF C732 4688 38BC F121 6869 30DD  58C3 38B3

 ___
 pkg-salt-team mailing list
 pkg-salt-t...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-salt-team

Bug#748092: [Pkg-salt-team] Bug#748092: salt-ssh: Missing dependency to python-zmq

[Joe Healy]

Upstream have made a fix, so I'll do a new release to fix this shortly.

https://github.com/saltstack/salt/commit/de4d823b9afdbd1f96735a796a3ecee295b3dcda

Bug#748092: [Pkg-salt-team] Bug#748092: salt-ssh: Missing dependency to python-zmq

[Joe Healy]

Thanks for the report.

https://github.com/saltstack/salt/issues/12766

I've submitted this bug upstream and will follow to see when it is resolved.

In the mean time, I'll have a quick look to see if i can patch the issue,
otherwise I'll look at depending on python-zmq.

Thanks,

Joe

Bug#747277: [Pkg-javascript-devel] Bug#747277: cannot start app: no method createServer

[Joe Nahmias]

reopen 747277
severity 747277 important
retitle 747277 Document proper migration from express
thanks

On Wed, May 07, 2014 at 08:45:38AM +0200, Jérémy Lal wrote:
 Hi,

Hello,

 Le mardi 06 mai 2014 à 23:33 -0400, Joseph Nahmias a écrit :
  Package: node-express
  Version: 4.1.1~dfsg-1
  Severity: grave
  
  Hello,
  
  Since I updated node-express today, I am no longer able to start my webapp. 
   I get the following error message:
 
 You'll find good information about how to transition to express 4.0 in
 the express wiki [1].
 
 Here the transition is rough because debian jumps directly from express
 2 to 4.
 
 Closing.

I think this is a bit hasty.  I would think for an upgrade of this
magnitude there should be some documentation in the package about how to
transition to the new version (for instance, including the links you've
provided here in this bug report).  IMHO, this is perfect fit for a
NEWS.Debian note -- especially since it is backwards incompatible and
breaks existing code that has been working for years so abruptly.

 Jérémy.

Thanks,
--Joe


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

Bug#741652: grub-pc-bin: No boot, cannot find root partition

[Joe Rowan]

Source: grub-pc-bin
Version: 2.02~beta2-7
Severity: critical
Justification: breaks the whole system

Dear Maintainer,


   * What led up to the situation?
Upgrade from 2.00-22 to 2.02~beta2-7

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Found reference to bug 741464, not exactly the same but worth trying, nothing 
else found on Net
Boot with installation disc, mount LVM partitions, chroot, downgrade to 2.00-22 
using dpkg, update-grub

   * What was the outcome of this action?
Booted OK, then downgraded related 2.02~beta2-7 packages


Additional information: during boot, was dropped to an initramfs shell when 
root partition not found. Only two partitions found, the reiserfs sda1 /boot 
and the swap partition in LVM, problem seemed to be failure of reiserfs in LVM.
Tried with rootdelay=30 seconds, no different




-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/first-root / reiserfs rw,relatime 0 0
/dev/mapper/first-backup /backup reiserfs rw,relatime 0 0
/dev/sda1 /boot reiserfs rw,relatime,notail 0 0
/dev/mapper/first-home /home reiserfs rw,relatime 0 0
/dev/mapper/first-tmp /tmp reiserfs rw,relatime 0 0
/dev/mapper/first-usr /usr reiserfs rw,relatime 0 0
/dev/mapper/first-var /var reiserfs rw,relatime 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-Hitachi_HDT721032SLA360_STF204ML0XDJMP
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
set default=0

if [ x${feature_menuentry_id} = xy ]; then
  menuentry_id_option=--id
else
  menuentry_id_option=
fi

export menuentry_id_option

if [ ${prev_saved_entry} ]; then
  set saved_entry=${prev_saved_entry}
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod lvm
insmod reiserfs
set root='lvm/first-usr'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint='lvm/first-usr'  
fcd5801a-eb3e-4eeb-b44c-fd00eb5cbab3
else
  search --no-floppy --fs-uuid --set=root fcd5801a-eb3e-4eeb-b44c-fd00eb5cbab3
fi
font=/share/grub/unicode.pf2
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_GB
  insmod gettext
fi
terminal_output gfxterm
if [ ${recordfail} = 1 ] ; then
  set timeout=-1
else
  set timeout=5
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod lvm
insmod reiserfs
set root='lvm/first-usr'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint='lvm/first-usr'  
fcd5801a-eb3e-4eeb-b44c-fd00eb5cbab3
else
  search --no-floppy --fs-uuid --set=root fcd5801a-eb3e-4eeb-b44c-fd00eb5cbab3
fi
insmod png
if background_image /share/images/desktop-base/joy-grub.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload=${1}
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-9bc3e03d-ce1a-403a-871b-fb7aa701b816' {
load_video
insmod gzio
insmod part_msdos
insmod reiserfs
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  
d73f3638-d220-48ef-8ac9-915a1cf20aab
else
  search --no-floppy --fs-uuid --set=root 
d73f3638-d220-48ef-8ac9-915a1cf20aab
fi
echo'Loading Linux 3.13-1-amd64 ...'
linux   /vmlinuz-3.13-1-amd64 root=/dev/mapper/first-root ro 
rootdelay=10 
echo'Loading initial ramdisk ...'
initrd  /initrd.img-3.13-1-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-9bc3e03d-ce1a-403a-871b-fb7aa701b816' {
menuentry 'Debian GNU/Linux, with Linux 3.13-1-amd64' --class debian 
--class 

Bug#741522: salt-cloud: requires newer version of python-libcloud

[Joe Healy]

Package: salt-cloud
Version: 2014.1.0+ds-1
Severity: grave
Justification: renders package unusable


   * What led up to the situation?

Running salt-cloud gives the following exception:

# salt-cloud
Traceback (most recent call last):
  File /usr/bin/salt-cloud, line 10, in module
salt_cloud()
  File /usr/lib/pymodules/python2.7/salt/scripts.py, line 121, in salt_cloud
cloud.run()
  File /usr/lib/pymodules/python2.7/salt/cloud/cli.py, line 50, in run
libcloud_version()
  File /usr/lib/pymodules/python2.7/salt/cloud/libcloudfuncs.py, line 94, in
libcloud_version
'libcloud 0.13.2. Please upgrade.'.format(libcloud.__version__)
ImportError: Your version of libcloud is 0.5.0. salt-cloud requires = libcloud
0.13.2. Please upgrade.


this should not have occurred. The package for python-libcloud needs to be
updated and a versioned dependency added.



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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#733014: pycarddav: diff for NMU version 0.6.1-1.1

[Joe Nahmias]

tags 733014 + patch
tags 733014 + pending
thanks

Dear maintainer,

I've prepared an NMU for pycarddav (versioned as 0.6.1-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.
--Joe
diff -Nru pycarddav-0.6.1/debian/changelog pycarddav-0.6.1/debian/changelog
--- pycarddav-0.6.1/debian/changelog	2013-12-23 12:18:10.0 -0500
+++ pycarddav-0.6.1/debian/changelog	2014-02-22 13:16:09.0 -0500
@@ -1,3 +1,10 @@
+pycarddav (0.6.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix upgrades from 0.5.1-1 and earlier (Closes: #733014)
+
+ -- Joe Nahmias je...@debian.org  Sat, 22 Feb 2014 13:16:01 -0500
+
 pycarddav (0.6.1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru pycarddav-0.6.1/debian/control pycarddav-0.6.1/debian/control
--- pycarddav-0.6.1/debian/control	2013-12-23 12:39:35.0 -0500
+++ pycarddav-0.6.1/debian/control	2014-02-22 13:06:48.0 -0500
@@ -41,6 +41,8 @@
  python-lxml,
  python-sqlite,
  python-requests
+Breaks: pycarddav ( 0.6.1)
+Replaces: pycarddav ( 0.6.1)
 Description: simple to use CardDAV python library
  pyCardDAV is a python module for syncing with a CardDAV server. It is
  mainly used with the binaries provided in `pycarddav`

Bug#736783: [Pkg-salt-team] Bug#736783: [src:salt] Sourceless file

[Joe Healy]

I'll add the override - that is trivial.

With the modernizr*.min.js file, the source is in
modernizr.custom.20463.jshttps://github.com/saltstack/salt/blob/develop/doc/_themes/saltstack/static/js/vendor/modernizr.custom.20463.js.
I'll get upstream to rename it for future releases and do a ds release in
the mean time.

Thanks,

Joe


On Mon, Jan 27, 2014 at 8:04 AM, bastien ROUCARIES 
roucaries.bast...@gmail.com wrote:

 Package: src:salt
 Version: 0.17.4-2
 Severity: serious
 User: debian...@lists.debian.org
 Usertags: source-contains-prebuilt-javascript-object
 X-Debbugs-CC: ftpmas...@debian.org

 salt 0.17.4-2 (source)
 I could not find the source of:

 doc/_themes/saltstack/static/js/vendor/modernizr-2.6.2-respond-1.1.0.min.js
 Please add an override for:
   doc/_themes/saltstack/static/js/vendor/bootstrap.min.js




 Bastien

 ___
 pkg-salt-team mailing list
 pkg-salt-t...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-salt-team

Bug#725999: [Pkg-salt-team] Bug#725999: salt: fails to ship source and incomplete debian/copyright

[Joe Healy]

On Mon, Oct 21, 2013 at 06:01:58AM -0400, Luke Faraone wrote:
 Yes. If you don't want to modify the upstream tarball this is then the
 recommended approach.

Thanks Luke, it turns out I need to modify the upstream tarball as
there are non DFSG files (fonts) in there.

So I'll remove these files and patch to use the versions packaged by
debian.

Thanks,

Joe


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

Bug#726480: upstream appear to have a patch

[Joe Healy]

https://github.com/saltstack/salt/pull/7356/files


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

Bug#725999: [Pkg-salt-team] Bug#725999: salt: fails to ship source and incomplete debian/copyright

[Joe Healy]

Thanks for picking these up and apologies for letting them through.

On Thu, Oct 10, 2013 at 08:05:18PM -0400, Luke Faraone wrote:
 
 Please document
 ../doc/_themes/saltstack/static/css/bootstrap-responsive.css in
 debian/copyright.

Will do.

 
 Please also recreate the minified versions during your package build,
 don't just accept the ones generated by upstream.

Will do.

 
 You do not ship the source for
 ../doc/_themes/saltstack/static/js/vendor/modernizr-2.6.2-respond-1.1.0.min.js
 at all, which is patently unacceptable.

Agreed. Is it acceptable to add the source in via a quilt patch then
build the minified version? or is there a better approach?

 
 This package embeds jQuery, which is suboptimal as jQuery is packaged in
 Debian. Regardless, it must be mentioned in debian/copyright.
 

My understanding is that there are two approaches I could use here. I
could rebuild the upstream .tar.gz without jQuery (and the others) or
I could depend on the debian jQuery and patch the documentation to use
the debian jQuery.

If I do the second, we would still ship a (unused) version of jQuery
in the orig.tar.gz, however, it would not be present in the .deb. As
such, it should still be mentioned in the debian/copyright. Is this
correct?

I'm not thrilled by either option (upstream not including it/them
would be best), but am leaning towards not modifying the orig.tar.gz
as at this stage, I believe the contentious files are all (able to be)
DFSG compliant.

Thanks for your assistance.

Joe


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

Bug#580820: oss-compat is a pain and should go away

[Joe Nahmias]

Agreed.

fceux (which will obsolete fceu) is now in experimental and i will be 
uploading it to unstable in the near future which will then allow me to 
transition all users over to that package.


--Joe

On 6/17/2013 10:40 AM, Holger Levsen wrote:

control: severity -1 serious
# justification: oss-compat is a pain and should go away

Hi,

also this bug was rightfully serious already in 2010 and was only downgraded
as a new maintainer had a new upstream version on mentors.d.n and so that it
could stay in the squeeze release... but we shouldnt really release this again
in jessie... esp. as there is a proper fix: new upstream version with alsa
support.


cheers,
Holger




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

Bug#658681: Select and install software fails with debian-testing DVD text install

[Joe Thompson]

On Sun, Feb 5, 2012 at 06:37, Miguel Figueiredo el...@debianpt.org wrote:
 On 05-02-2012 06:02, Joe Thompson wrote:

 Package: installation-reports
 Severity: critical
 Tags: d-i
 X-Debbugs-Cc: debian-b...@orion-com.com

 Using the testing DVD that I downloaded the evening of 3 Feb 2012,
 installation fails near the end (95% or so of the way through Select
 and install software) using the text installer.

 Steps followed: all choices were the defaults except as follows --

 * use entire disk with LVM
 * use guided partitioning, separate /home
 * use kernel linux-image-3.1.0
 * scan another CD: No
 * use a network mirror: Yes
   * debian.lcs.mit.edu mirror
 * install options: Debian desktop, SSH server

 Install failed after Configuring ntfsprogs. -- Joe

 Likely a mirror issue or disk full. Can you provide more info from what
 happened from the installation log?

It appears the install log wasn't saved, but indeed when I mount the
drive with TRK, I now see the 12-GB drive (this is a VM) has been
divided up into a 243-MB /boot, 424 MB swap, 3.33-GB /, and 8.01-GB
/home, with the / partition completely full.

Can the installer be corrected to partition things out more sanely on
small drives like this, or at least warn after the tasksel stage that
install may fail because / wasn't allocated enough space? -- Joe
-- 
Joe Thompson | j...@orion-com.com
I'd take seven earthquakes and your computer autoinstalling a Hebrew
spelling corrector that it apparently expects you're going to need as
a definite sign of the coming apocalypse. -- AdB, in conversation



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

Bug#658681: Select and install software fails with debian-testing DVD text install

[Joe Thompson]

Package: installation-reports
Severity: critical
Tags: d-i
X-Debbugs-Cc: debian-b...@orion-com.com

Using the testing DVD that I downloaded the evening of 3 Feb 2012,
installation fails near the end (95% or so of the way through Select
and install software) using the text installer.

Steps followed: all choices were the defaults except as follows --

* use entire disk with LVM
* use guided partitioning, separate /home
* use kernel linux-image-3.1.0
* scan another CD: No
* use a network mirror: Yes
  * debian.lcs.mit.edu mirror
* install options: Debian desktop, SSH server

Install failed after Configuring ntfsprogs. -- Joe



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

Bug#629417: Debian Bug report logs - #629417 update-flashplugin-nonfree --install fails on i386 (sha512sum rejected)

[Joe Morris]

Hi, I read a bug report indicating that the nonfree flash plugin bug
was fixed but I am still getting the sha512sum rejected
install_flash_player_10_linux.tar.gz message so the checksums are
inaccurate or something. I see the checksums were updated in August
and May, but it seems like they may need to be updated again. I swear
I was able to 100% successfully install the flash-nonfree yesterday,
but I ran into an unrelated problem this morning, had to reinstall,
and today (June 7) I encounter the bug.

Thanks!



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

Bug#580820: do you plan to continue working on fceu?

[Joe Nahmias]

tags 580820 pending
thanks

Actually, I have a new package ready, I'm just testing it.  I'll probably
upload this weekend.

--Joe

On Fri, Sep 03, 2010 at 08:39:34AM -0500, Jordi Gutiérrez Hermoso wrote:
 On Mon, 5 Jul 2010 22:10:26 -0400 Joe Nahmias j...@nahmias.net wrote:
  Yes, I do plan on working on fceu. Just finished some stuff IRL, so
  I should have time to look at this in the near future.
 
 Are you still working on this? The squeeze release managers are
 getting itchy to remove leaf packages from squeeze with RC bugs, and
 fceu looks like a prime candidate.
 
 If you need help, maybe one of us could help.



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

Bug#576460: mtpfs segfaults when i mount a creative zen v plus

[joe]

Hi Luigi,

If you're running testing (squeeze) or unstable (sid), you can just
install the libmtp-dbg package to get the debugging symbols.

--Joe

PS - You might also want to install the libc debug symbols (in package
libc6-dbg).

On Thu, Apr 08, 2010 at 09:33:25PM +0200, luigi curzi wrote:
 Il giorno Thu, 8 Apr 2010 16:55:15 +0100
 Chris Lamb la...@debian.org ha scritto:
 
  Okay, I think we need some debugging symbols for this to be helpful.
  Do you have enough Debian-fu to recompile mtpfs and libmtp with
  debugging enabled?
 
 i downloaded sources from debian repository, but i don't know how to
 modify libmtp's rules to create a package with debug symbols.
 in mtpfs's rules must i add -g -o0 to cflags?
 -- 
 Luigi Curzi



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

Bug#588491: omfs-source: fails to compile with m-a

[Joe Nahmias]

tags 588491 + wontfix
thanks

Hi Brandon,

The omfs driver has been part of the mainline kernel since 2.6.27.  Since
testing/squeeze is on 2.6.32, this package serves no purpose anymore; so,
I will shortly be requesting removal of this package.

Thanks for the report though.
--Joe

On Thu, Jul 08, 2010 at 08:02:34PM -0700, Brandon Del Bel wrote:
 Package: omfs-source
 Version: 0.8.0-2
 Severity: serious
 Justification: fails to build from source
 
 buildlog from 'm-a a-i omfs':
 
 dh_clean
 /usr/bin/make KERNELDIR=/lib/modules/2.6.32-5-amd64/build clean
 make[1]: Entering directory `/usr/src/modules/omfs'
 /usr/bin/make -C /lib/modules/2.6.32-5-amd64/build M=/usr/src/modules/omfs 
 clean
 make[2]: Entering directory `/usr/src/linux-headers-2.6.32-5-amd64'
 make[2]: Leaving directory `/usr/src/linux-headers-2.6.32-5-amd64'
 make[1]: Leaving directory `/usr/src/modules/omfs'
 /usr/bin/make  -f debian/rules kdist_clean kdist_config binary-modules
 make[1]: Entering directory `/usr/src/modules/omfs'
 dh_clean
 /usr/bin/make KERNELDIR=/lib/modules/2.6.32-5-amd64/build clean
 make[2]: Entering directory `/usr/src/modules/omfs'
 /usr/bin/make -C /lib/modules/2.6.32-5-amd64/build M=/usr/src/modules/omfs 
 clean
 make[3]: Entering directory `/usr/src/linux-headers-2.6.32-5-amd64'
 make[3]: Leaving directory `/usr/src/linux-headers-2.6.32-5-amd64'
 make[2]: Leaving directory `/usr/src/modules/omfs'
 for templ in ; do \
 cp $templ `echo $templ | sed -e 's/_KVERS_/2.6.32-5-amd64/g'` ; \
   done
 for templ in `ls debian/*.modules.in` ; do \
 test -e ${templ%.modules.in}.backup || cp ${templ%.modules.in} 
 ${templ%.modules.in}.backup 2/dev/null || true; \
 sed -e 's/##KVERS##/2.6.32-5-amd64/g ;s/#KVERS#/2.6.32-5-amd64/g ; 
 s/_KVERS_/2.6.32-5-amd64/g ; s/##KDREV##/2.6.32-15/g ; s/#KDREV#/2.6.32-15/g 
 ; s/_KDREV_/2.6.32-15/g  '  $templ  ${templ%.modules.in}; \
   done
 dh_testdir
 dh_testroot
 dh_clean -k
 dh_clean: dh_clean -k is deprecated; use dh_prep instead
 /usr/bin/make KERNELDIR=/lib/modules/2.6.32-5-amd64/build 
 MODVERSIONS=detect KERNEL=linux-2.6.32-5-amd64
 make[2]: Entering directory `/usr/src/modules/omfs'
 /usr/bin/make -C /lib/modules/2.6.32-5-amd64/build M=/usr/src/modules/omfs 
 modules
 make[3]: Entering directory `/usr/src/linux-headers-2.6.32-5-amd64'
 /usr/src/linux-headers-2.6.32-5-common/arch/x86/Makefile:81: stack protector 
 enabled but no compiler support
   CC [M]  /usr/src/modules/omfs/inode.o
 /usr/src/modules/omfs/inode.c: In function ‘omfs_new_inode’:
 /usr/src/modules/omfs/inode.c:40: error: ‘struct task_struct’ has no member 
 named ‘fsuid’
 /usr/src/modules/omfs/inode.c:41: error: ‘struct task_struct’ has no member 
 named ‘fsgid’
 /usr/src/modules/omfs/inode.c: In function ‘omfs_fill_super’:
 /usr/src/modules/omfs/inode.c:424: error: ‘struct task_struct’ has no member 
 named ‘uid’
 /usr/src/modules/omfs/inode.c:425: error: ‘struct task_struct’ has no member 
 named ‘gid’
 /usr/src/modules/omfs/inode.c:426: error: dereferencing pointer to incomplete 
 type
 make[6]: *** [/usr/src/modules/omfs/inode.o] Error 1
 make[5]: *** [_module_/usr/src/modules/omfs] Error 2
 make[4]: *** [sub-make] Error 2
 make[3]: *** [all] Error 2
 make[3]: Leaving directory `/usr/src/linux-headers-2.6.32-5-amd64'
 make[2]: *** [modules] Error 2
 make[2]: Leaving directory `/usr/src/modules/omfs'
 make[1]: *** [binary-modules] Error 2
 make[1]: Leaving directory `/usr/src/modules/omfs'
 make: *** [kdist_build] Error 2
 
 -- System Information:
 Debian Release: squeeze/sid
   APT prefers testing
   APT policy: (500, 'testing')
 Architecture: i386 (x86_64)
 
 Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
 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 omfs-source depends on:
 ii  bzip2 1.0.5-4high-quality block-sorting file 
 co
 ii  debhelper 7.9.1  helper programs for debian/rules
 ii  module-assistant  0.11.3 tool to make module package 
 creati
 
 omfs-source recommends no packages.
 
 omfs-source 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#580820: do you plan to continue working on fceu?

[Joe Nahmias]

Hi Christine,

Yes, I do plan on working on fceu.  Just finished some stuff IRL, so I
should have time to look at this in the near future.

--Joe

On Sat, Jun 26, 2010 at 05:32:58PM -0400, Christine Spang wrote:
 Hi Joe,
 
 Do you plan to continue working on the fceu Debian package?
 You have not made any uploads in some time, and it has
 a critical bug that would be fixed by packaging the latest
 version. If you do not intend to work on it, it would be a
 good idea to orphan the package, as such changes shouldn't
 be done as non-maintainer uploads.
 
 cheers,
 Christine
 
 



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

Bug#578041: mysql-server-core-5.1: mysql server does not start

[Joe]

Package: mysql-server-core-5.1
Version: 5.1.45-3
Severity: grave
Justification: renders package unusable


Mysqld fails to start after most recent upgrade, dated April 10th. 
Problem appears to be incorrect filename in /etc/init.d/mysql which 
checks existence of /usr/sbin/mysqld but invokes /usr/bin/mysqld_safe, 
which does not exist. Changing that name to /usr/sbin/mysqld appears to 
allow normal starting, but with errors. The source file 
/usr/share/mysql/debian-start.inc.sh which is referenced in 
/etc/mysql/debian-start does not exist, so the commands used in 
debian-start are not found. The mysql files under /etc all have old 
dates, though they agree with the April 10th contents of 
/usr/share/mysql-common/internal-use-only, in using incorrect or missing 
filenames.


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

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

Versions of packages mysql-server-core-5.1 depends on:
ii  libc6   2.10.2-6 Embedded GNU C Library: 
Shared lib

ii  libgcc1 1:4.4.3-7GCC support library
ii  libstdc++6  4.4.3-7  The GNU Standard C++ Library v3
ii  libwrap07.6.q-18 Wietse Venema's TCP 
wrappers libra

ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

mysql-server-core-5.1 recommends no packages.

mysql-server-core-5.1 suggests no packages.

-- no debconf information
--
Joe



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

Bug#576457: I can confirm, 0.9.21-1.2 does not work on amd64

[Joe Oblivian]

$ dpkg -l pulseaudio
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
ii  pulseaudio 0.9.21-1.2 PulseAudio sound server


j...@bunny:~$ pulseaudio --start
E: core-util.c: Failed to create secure directory: Permission denied
W: lock-autospawn.c: Cannot access autospawn lock.
E: main.c: Failed to acquire autospawn lock


So it seems something is still missing from the patch.

Should we open a new bug?

Joe




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

Bug#537130: Workaround

[Joe]

It looks as if copying the files from /debian/tmp to their proper 
locations, then re-running the upgrade, may be enough to solve the 
problem. Possibly some of the copying steps were missed. The following 
reboot seemed to be clean.


--
Joe




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

Bug#525376: package installation fails during postinst

[Joe Nahmias]

Package: libboost1.38-dbg
Version: 1.38.0-3
Severity: grave

Hello, I just tried to install the libboost1.38-dbg package and dpkg
errors out during the postinst.  I turned on set -x and here's the
trace:

$ sudo dpkg --configure -a
Setting up libboost1.38-dbg (1.38.0-3) ...  
+ update=/usr/share/python/runtime.d/libboost1.38-dbg.rtupdate
+ which pyversions
++ pyversions -d
+ /usr/share/python/runtime.d/libboost1.38-dbg.rtupdate rtupdate none python2.5
+ debug=
+ case $0 in
+ action=rtupdate
+ shift
+ case $action in
+ rtupdate python2.5
+ case $1 in
+ py=py25
+ update_linklibs py25 a
+ py=py25
+ suf=a
+ cd /usr/lib
+ for thread in '' -mt
+ target=libboost_python-py25.a
+ link=libboost_python.a
+ test -e libboost_python-py25.a
+ for thread in '' -mt
+ target=libboost_python-mt-py25.a
+ link=libboost_python-mt.a
+ test -e libboost_python-mt-py25.a
dpkg: error processing libboost1.38-dbg (--configure):
 subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
 libboost1.38-dbg

Looking at my /usr/lib/, I see the following:

$ ls -l /usr/lib/libboost_python-mt*
-rw-r--r--. 1 root root 7086332 2009-04-04 04:10 
/usr/lib/libboost_python-mt-d-py24.a
lrwxrwxrwx. 1 root root  35 2009-04-24 00:04 
/usr/lib/libboost_python-mt-d-py24.so - libboost_python-mt-d-py24.so.1.38.0
-rw-r--r--. 1 root root 4211456 2009-04-04 04:10 
/usr/lib/libboost_python-mt-d-py24.so.1.38.0
-rw-r--r--. 1 root root 7091948 2009-04-04 04:10 
/usr/lib/libboost_python-mt-d-py25.a
lrwxrwxrwx. 1 root root  35 2009-04-24 00:04 
/usr/lib/libboost_python-mt-d-py25.so - libboost_python-mt-d-py25.so.1.38.0
-rw-r--r--. 1 root root 4215174 2009-04-04 04:10 
/usr/lib/libboost_python-mt-d-py25.so.1.38.0


Hope this helps,
--Joe


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

Kernel: Linux 2.6.29-1-686 (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#517605: (no subject)

[Joe Nahmias]

Hi,

On Sun, Mar 08, 2009 at 05:21:49PM +, Iain Lane wrote:
 Hi,
 
 I've made the remaining transition bugs serious as they block completion
 of the Mono 2 transition. You package will ftbfs until this is resolved.
 
 Please apply the patches soon.
 
 Thanks,
 Iain (pkg-cli-libs team).
 

Please feel free to NMU as I'm keyless at the moment.

--Joe



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

Bug#518913: aspell cannot create hash file for en

[Joe Thompson]

Package: aspell
Version: 0.60.6-1
Severity: grave
Tags: l10n
Justification: renders package unusable

After upgrading from debian sarge, through etch, and finally to lenny, I 
noticed when trying to install AbiWord that aspell failed to create a hash 
file for locale en.  In fact the problem I get is exactly as described 
here: 

http://osdir.com/ml/linux.debian.devel.dictionary/2005-07/msg00010.html

which as you can see is a 3.5-year-old message.  Nonetheless, that's the 
behavior I see -- anytime anything triggers aspell-autobuildhash, I get an 
ncurses dialog saying:

-
Problems rebuilding an aspell hash file (en)

** Error: Could not build the hash file for en-common

This error was caused by package providing 'en', although it can be made 
evident during other package postinst. Please complain to the maintainer 
of package providing 'en'.

Until this problem is fixed you will not be able to use aspell with 'en'.
-

I've tried reinstalling all of the following:

aspell
aspell-en
libaspell15
dictionaries-common

and nothing has fixed it.

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

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
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 aspell depends on:
ii  dictionaries-common   0.98.12Common utilities for spelling dict
ii  libaspell15   0.60.6-1   GNU Aspell spell-checker runtime l
ii  libc6 2.7-18 GNU C Library: Shared libraries
ii  libgcc1   1:4.3.2-1.1GCC support library
ii  libncursesw5  5.7+20081213-1 shared libraries for terminal hand
ii  libstdc++64.3.2-1.1  The GNU Standard C++ Library v3

Versions of packages aspell recommends:
ii  aspell-en [aspell-dictionary] 6.0-0-5.1  English dictionary for GNU Aspell

Versions of packages aspell suggests:
pn  aspell-docnone (no description available)
pn  spellutilsnone (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#513780: kdesdk-scripts: undeclared file conflict /usr/share/man/man1/demangle.1.gz

[Joe Nahmias]

Package: kdesdk-scripts
Version: 4:4.2.0-1
Severity: serious

# apt-get install kdesdk-scripts
[...]
Preparing to replace kdesdk-scripts 4:3.5.9-2 (using 
.../kdesdk-scripts_4%3a4.2.0-1_all.deb) ...
Unpacking replacement kdesdk-scripts ...
dpkg: error processing 
/var/cache/apt/archives/kdesdk-scripts_4%3a4.2.0-1_all.deb (--unpack):
 trying to overwrite `/usr/share/man/man1/demangle.1.gz', which is also in 
package kmtrace
Processing triggers for man-db ...
Errors were encountered while processing:
 /var/cache/apt/archives/kdesdk-scripts_4%3a4.2.0-1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

$ dpkg -l kmtrace | grep ^.i
ii  kmtrace  4:3.5.9-2 a KDE 
memory leak tracer


-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (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 kdesdk-scripts depends on:
ii  perl  5.10.0-19  Larry Wall's Practical Extraction 
ii  python2.5.2-3An interactive high-level object-o

Versions of packages kdesdk-scripts recommends:
ii  automake1:1.10.1-3   A tool for generating GNU Standard
ii  cvs 1:1.12.13-12 Concurrent Versions System
ii  gawk1:3.1.5.dfsg-4.1 GNU awk, a pattern scanning and pr

Versions of packages kdesdk-scripts suggests:
ii  devscripts 2.10.45   scripts to make the life of a Debi
pn  dmallocnone(no description available)
ii  gdb6.8-3 The GNU Debugger
ii  kdelibs4-d 4:3.5.10.dfsg.1-1 developer documentation for the KD
ii  kdesdk-doc 4:3.5.9-2 KDE Software Development Kit docum
ii  khelpcente 4:4.0.0.really.3.5.9.dfsg.1-6 help center for KDE
ii  qt3-doc3:3.3.8b-5Qt3 API documentation
pn  valgrind   none(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#474947: MMap out of room issue still exists in 0.7.14

[Joe Nahmias]

Package: apt
Version: 0.7.14+b1
Followup-For: Bug #474947

$ sudo apt-get -o APT::Cache-File=2 update
[snip]
Fetched 10.2MB in 25s (405kB/s)
Reading package lists... Error!
E: Dynamic MMap ran out of room
E: Error occurred while processing vino (NewVersion1)
E: Problem with MergeList 
/var/lib/apt/lists/ftp.us.debian.org_debian_dists_etch_main_binary-i386_Packages
E: The package lists or status file could not be parsed or opened.
$


Note that commenting out the line deb http://ftp.us.debian.org/debian/
etch main contrib non-free in my sources.list works around the issue.

--Joe

-- Package-specific info:

-- apt-config dump --

APT ;
APT::Architecture i386;
APT::Build-Essential ;
APT::Build-Essential:: build-essential;
APT::Install-Recommends false;
APT::Install-Suggests false;
APT::Acquire ;
APT::Acquire::Translation environment;
APT::Authentication ;
APT::Authentication::TrustCDROM true;
APT::NeverAutoRemove ;
APT::NeverAutoRemove:: ^linux-image.*;
APT::NeverAutoRemove:: ^linux-restricted-modules.*;
APT::Default-Release unstable;
APT::Get ;
APT::Get::Fix-Broken true;
APT::Get::Show-Upgraded true;
APT::Get::Purge true;
APT::Cache-Limit 16777216;
APT::Clean-Installed false;
Dir /;
Dir::State var/lib/apt/;
Dir::State::lists lists/;
Dir::State::cdroms cdroms.list;
Dir::State::userstatus status.user;
Dir::State::status /var/lib/dpkg/status;
Dir::Cache var/cache/apt/;
Dir::Cache::archives archives/;
Dir::Cache::srcpkgcache srcpkgcache.bin;
Dir::Cache::pkgcache pkgcache.bin;
Dir::Etc etc/apt/;
Dir::Etc::sourcelist sources.list;
Dir::Etc::sourceparts sources.list.d;
Dir::Etc::vendorlist vendors.list;
Dir::Etc::vendorparts vendors.list.d;
Dir::Etc::main apt.conf;
Dir::Etc::parts apt.conf.d;
Dir::Etc::preferences preferences;
Dir::Bin ;
Dir::Bin::methods /usr/lib/apt/methods;
Dir::Bin::dpkg /usr/bin/dpkg;
Dir::Log var/log/apt;
Dir::Log::Terminal term.log;
DPkg ;
DPkg::Pre-Install-Pkgs ;
DPkg::Pre-Install-Pkgs:: /usr/sbin/apt-listbugs apt || exit 10;
DPkg::Pre-Install-Pkgs:: /usr/bin/apt-listchanges --apt || test $? -ne 10;
DPkg::Pre-Install-Pkgs:: /usr/sbin/dpkg-preconfigure --apt || true;
DPkg::Tools ;
DPkg::Tools::Options ;
DPkg::Tools::Options::/usr/sbin/apt-listbugs ;
DPkg::Tools::Options::/usr/sbin/apt-listbugs::Version 2;
DPkg::Tools::Options::/usr/bin/apt-listchanges ;
DPkg::Tools::Options::/usr/bin/apt-listchanges::Version 2;
DPkg::Post-Invoke ;
DPkg::Post-Invoke:: if [ -x /usr/bin/debsums ]; then /usr/bin/debsums 
--generate=nocheck -sp /var/cache/apt/archives; fi;
DPkg::Post-Invoke:: debsums --generate=nocheck -sp /var/cache/apt/archives;
DPkg::Build-Options -rfakeroot -b -uc;
Debug ;
Debug::pkgProblemResolver true;
Acquire ;
Acquire::PDiffs false;

-- (no /etc/apt/preferences present) --


-- /etc/apt/sources.list --

deb http://ftp.egr.msu.edu/debian/ unstable main contrib
deb-src http://ftp.egr.msu.edu/debian/ unstable main contrib

deb http://ftp.us.debian.org/debian/ unstable main contrib non-free
deb-src http://ftp.us.debian.org/debian/ unstable main contrib non-free

deb http://security.debian.org/ etch/updates main contrib non-free
deb-src http://security.debian.org/ etch/updates main contrib non-free
deb http://ftp.us.debian.org/debian/ etch main contrib non-free
deb http://ftp.us.debian.org/debian/ lenny main contrib non-free

deb-src http://mentors.debian.net/debian unstable main contrib

-- System Information:
Debian Release: lenny/sid
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-686 (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 apt depends on:
ii  debian-archive-keyring   2008.04.16+nmu1 GnuPG archive keys of the Debian a
ii  libc62.7-12  GNU C Library: Shared libraries
ii  libgcc1  1:4.3.1-6   GCC support library
ii  libstdc++6   4.3.1-6 The GNU Standard C++ Library v3

apt recommends no packages.

Versions of packages apt suggests:
pn  apt-doc   none (no description available)
ii  aptitude  0.4.11.8-1 terminal-based package manager
ii  bzip2 1.0.5-0.1  high-quality block-sorting file co
ii  dpkg-dev  1.14.20Debian package development tools
ii  lzma  4.43-14Compression method of 7z format in

-- no debconf information



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

Bug#490217: python-dns vulnerable to CVE-2008-1447 DNS source port guessable

[Joe Malicki]

Package: python-dns
Version: 2.3.0-5.1
Severity: grave
Tags: security
Justification: user security hole

CVE-2008-1447, which deals with DNS reply poisoning that
is possible due to DNS clients sending DNS requests on
predictable UDP source ports, is a security issue that
also applies to python-dns, as it does not implement the
recommended UDP port randomization... example:

Note lack of port randomization in code:
def sendUDPRequest(self, server):
refactor me
self.response=None
self.socketInit(socket.AF_INET, socket.SOCK_DGRAM)
for self.ns in server:
try:
# TODO. Handle timeouts c correctly (RFC)
#self.s.connect((self.ns, self.port))
self.conn()
self.time_start=time.time()
if not self.async:
self.s.send(self.request)
self.response=self.processUDPReply()
#except socket.error:
except None:
continue
break
if not self.response:
if not self.async:
raise DNSError,'no working nameservers found'

In [25]: import DNS
In [26]: d=DNS.DnsRequest(name='www.google.com', server='208.80.142.5', 
port=53)
In [27]: r=d.req() 
In [28]: r=d.req()

In [29]: r=d.req()

In [30]: r=d.req()
(etc)

Yields, with tcpdump udp port 53:
15:27:15.912894 IP baekdudaegan.metacarta.com.43661  
eiger.metacarta.com.domain:  0+ A? www.google.com. (32)
15:27:17.224843 IP baekdudaegan.metacarta.com.43662  
eiger.metacarta.com.domain:  0+ A? www.google.com. (32)
15:27:18.344731 IP baekdudaegan.metacarta.com.43663  
eiger.metacarta.com.domain:  0+ A? www.google.com. (32)
15:27:18.952729 IP baekdudaegan.metacarta.com.43664  
eiger.metacarta.com.domain:  0+ A? www.google.com. (32)
15:27:19.384802 IP baekdudaegan.metacarta.com.43665  
eiger.metacarta.com.domain:  0+ A? www.google.com. (32)
15:27:19.752853 IP baekdudaegan.metacarta.com.43666  
eiger.metacarta.com.domain:  0+ A? www.google.com. (32)
15:27:20.120819 IP baekdudaegan.metacarta.com.43667  
eiger.metacarta.com.domain:  0+ A? www.google.com. (32)
15:27:22.680866 IP baekdudaegan.metacarta.com.43668  
eiger.metacarta.com.domain:  0+ A? www.google.com. (32)
15:27:23.416775 IP baekdudaegan.metacarta.com.43669  
eiger.metacarta.com.domain:  0+ A? www.google.com. (32)


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages python-dns depends on:
ii  python2.4.4-2An interactive high-level object-o
ii  python-support0.5.6  automated rebuilding support for p

python-dns recommends no packages.

-- no debconf information



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

Bug#485668: Conflict with package called clit

[Joe Nahmias]

On Tue, Jun 10, 2008 at 09:56:33PM +0300, Juhapekka Tolvanen wrote:
 Package: convlit
 Version: 1.8-1
 Severity: serious
 
 
 Unpacking convlit (from .../convlit_1.8-1_i386.deb) ...
 dpkg: error processing /var/cache/apt/archives/convlit_1.8-1_i386.deb
 (--unpack):
  trying to overwrite `/usr/bin/clit', which is also in package clit

Um, where did you get the 'clit' package from?  I don't see it in any
debian release available on packages.debian.org:

$ grep-available -P ^clit$
$

--joe



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

Bug#474413: Problem with autobuild of libtommath/0.39-2

[Joe Nahmias]

On Wed, May 07, 2008 at 05:49:23AM +0300, Guillem Jover wrote:
 On Tue, 2008-05-06 at 19:41:10 +, Joe Nahmias wrote:
  Maybe I'm missing something, but I don't understand why the build target
  is called in the first place.  Can't you just run debian/rules
  binary-arch -- which is mandated by policy -- and everything will be ok
  because of the target dependancies in debian/rules.  Why use build at
  all -- especially since dpkg-buildpackage can't determine the right
  thing with build/build-arch?!?
 
 build does not require root privs, binary-* do.

So what?  dpkg-buildpackage already makes use of the appropriate binary
target, so there's no additional requirement for it.  All I'm suggesting
is to skip the build step (ie. comment out line 364), since it is
uneccessary and will be handled by the makefile dependancies.

I only wish I had access to resources so that I could test this against
the entire archive.

--Joe



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

Bug#474413: Problem with autobuild of libtommath/0.39-2

[Joe Nahmias]

Hi Riku,

On Wed, May 07, 2008 at 02:48:53PM +0300, Riku Voipio wrote:
 On Tue, May 06, 2008 at 07:41:10PM +, Joe Nahmias wrote:
  On Mon, May 05, 2008 at 11:57:55PM +0300, Riku Voipio wrote:
   Lets not complicate this matter with the age-long build/build-arch
   discussion. libtommath needs add the build-dependencies enough to
   to get through debian/rules build for the time being.
 
  Maybe I'm missing something [...]
 
 Yes. You missed the part where I requested not complicate the issue.
 dpkg-buildpackage/sbuild will be made better eventually. Will happen
 faster if someone actually shows a patch that uses build-arch and
 demonstrates that it will break building of 1% packages. Currently
 it seems people prefer to just talk about it and hypothise about problems
 that could potentially materialize in some parallax universe rather than
 provide patches and testresults of full archive rebuilds.

I agree, it's not complicated -- fix your buildd software (or
environment, if you pefer) to install B-D-I if you're going to use the
build target.  It's not a bug in my package if you use faulty
software/environment in your buildd, that doesn't follow policy's
requirements for building debian packages, and then the build fails
because you didn't follow the instructions.  Nobody is forcing you to
install only B-D and not B-D-I and then use dpkg-buildpackage which uses
the build target.

Furthermore, I have an idea that avoids the whole complicated build-arch
issue entirely, which you have not addressed or responded to.  I'd be
happy to provide a patch (comment out line 364 in dpkg-buildpackage) but
I don't have the resources to do a full archive rebuild to test it.  Can
you or anyone else reading this help me out with that?

 So for now, no furious handwaving towards the policy/dpkg/sbuild etc
 is going to help your package a) getting built b) getting to
 testing/lenny.

It's already in testing/lenny, albeit only for one arch.  I could build
the package for each arch manually -- and with proper environment and
software it would work just fine; but, I'll probably end up copying the
B-D-I into B-D to avoid the hassle.  I just hope you realize that the
true problem/bug is in the current buildd b0rkage that has become the
status quo -- not in anything I did in the packaging.

--Joe



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

Bug#478524: Bug#474413: Problem with autobuild of libtommath/0.39-2

[Joe Nahmias]

On Mon, May 05, 2008 at 11:57:55PM +0300, Riku Voipio wrote:
 Lets not complicate this matter with the age-long build/build-arch
 discussion. libtommath needs add the build-dependencies enough to
 to get through debian/rules build for the time being.

Maybe I'm missing something, but I don't understand why the build target
is called in the first place.  Can't you just run debian/rules
binary-arch -- which is mandated by policy -- and everything will be ok
because of the target dependancies in debian/rules.  Why use build at
all -- especially since dpkg-buildpackage can't determine the right
thing with build/build-arch?!?

And I would further argue that it's a bug for sbuild to use
dpkg-buildpackage (as it's currently implemented, using the build
target) without installing B-D-I.  IOW, sbuild should fix this by
installing B-D-I to work around the dpkg-buildpackage issue, or use some
other method (run debian/rules clean; debian/rules binary-arch
manually) to build the arch-only portions of packages.  Then, when the
issue with build/build-arch is finally resolved, only sbuild has to be
changed -- rather than make every packager fix this for each and every
package.

--Joe



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

Bug#474413: Problem with autobuild of libtommath/0.39-2

[Joe Nahmias]

Hi Roger,

On Tue, May 06, 2008 at 09:36:37PM +0100, Roger Leigh wrote:
 Joe Nahmias [EMAIL PROTECTED] writes:
[snip]
 I discussed this yesterday on #debian-devel.  The main issues are

Sorry I missed it, had I known I would've liked to participate.

 - it's not possible to robustly determine if debian/rules contains a
   build-arch or build-indep target due to things like pattern rules.
   There are some hacky ways to do this, but these would not be
   reliable.  Ideally, make needs to provide a means of querying if a
   target is present.

OK.

 - most packages do not yet contain a build-arch|build-indep target,
   and policy currently makes this optional.  Calling debian/rules
   binary-arch will break a lot of packages.

Um, my reading of policy says that BINARY-arch is required and should
depend on the appropriate targets to build the package as necessary.
So, I don't see why dpkg-buildpackage can't simply run:

...
  debian/rules clean
  debian/rules binary-arch
...

All this would do is potentially expose bugs in packages that are not
currently policy-compliant in terms of the target dependancies, of which
I doubt there are very many due to dh_make templates and the like.

 - moving to requiring these targets is something that would need to be
   done after the release of Lenny, as a release goal for Lenny+1.

I understand for BUILD-arch; but BINARY-arch is required and has been as
far back as I can remember (corrections welcome).

  And I would further argue that it's a bug for sbuild to use
  dpkg-buildpackage (as it's currently implemented, using the build
  target) without installing B-D-I.  IOW, sbuild should fix this by
  installing B-D-I to work around the dpkg-buildpackage issue, or use some
  other method (run debian/rules clean; debian/rules binary-arch
  manually) to build the arch-only portions of packages.  Then, when the
  issue with build/build-arch is finally resolved, only sbuild has to be
  changed -- rather than make every packager fix this for each and every
  package.
 
 I could fix this in sbuild, but unfortunately the packaged sbuild
 (which we maintain) is not the same as that used by the actual Debian
 autobuilders (which has a separate maintainer), and so this would not
 really help.  Hopefully at some point the autobuilders can switch to
 the buildd-tools code, but the buildd/wanna-build part isn't ready for
 that yet.  It will hopefully be ready after Lenny, but I can't promise
 anything.

Ah, it seems I'm barking up the wrong tree...
Well, I would certainly suggest that you fix this, but I guess it won't
do me all that much good :(

Thanks for the information though and if I can help in any way, please
feel free to ask.
--Joe



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

Bug#474413: Problem with autobuild of libtommath/0.39-2

[Joe Nahmias]

clone 474413 -1
retitle -1 debian/rules build target requires installing B-D-I
reassign -1 sbuild
blocks 474413 by -1
thanks

Hello,

Well, I made the change and now calling binary-arch target of
debian/rules no longer runs latex.

However, as you can see on line 156 of
http://buildd.debian.org/fetch.cgi?pkg=libtommath;ver=0.39-2;arch=s390;stamp=1209376922,
sbuild is actually calling the build target -- not the binary-arch
target as previously asserted.  This, as I mentioned in my first reply,
requires the installation of B-D-I as per policy 7.6.

--Joe



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

Bug#474413: libtommath - FTBFS: debian/rules broken.

[Joe Nahmias]

tags 474413 + pending
thanks

On Fri, Apr 25, 2008 at 12:40:06AM +0200, Bernd Zeimetz wrote:
 As binary-arch depends on install, which depends on build, which depends
 on build-arch AND build-indep, the build-indep target is called even if
 you build an arch:any package. You need to fix your install target (or
 use something like install-indep and install-arch) to avoid running
 build-indep while installing your binary-arch stuff.

Seems reasonable to me.  Have made the fix locally, but am away from my
key.  Will upload shortly.

--Joe



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

Bug#473939: sitecopy: FTBFS: configure: incompatible neon library version 0.28.1: wanted 0.24 25 26 27

[Joe Orton]

On Wed, Apr 02, 2008 at 05:13:33PM +0530, Kartik Mistry wrote:
 On Wed, 2 Apr 2008 13:08:49 +0200
 Lucas Nussbaum [EMAIL PROTECTED] wrote:
 ...
 | checking linking against neon... yes
 | configure: incompatible neon library version 0.28.1: wanted 0.24 25 26 27
 | configure: error: could not use external neon library
 | make: *** [build-console/config.status] Error 1
 ...
 
 Hi Joe,
 
 Can you please provide patch for libneon28 for sitecopy?

Just change the 0.27.x patch to read:

+NE_REQUIRE_VERSIONS([0], [24 25 26 27 28])

0.28.x is backwards-compatibile with 0.27.

joe



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

Bug#469855: postinst fails if udev is not running

[Joe Nahmias]

Package: nut
Version: 2.2.1-2
Severity: serious
Tags: patch

Hello,

It seems that the nut postinst script errors out if udev is not running
at the time the script is run.  This creates problems in buildds or
chroots since udev is normally not started in those environments.  See,
for example, the i386 build log for collectd 4.3.0-2 at:
http://buildd.debian.org/fetch.cgi?pkg=collectd;ver=4.3.0-2;arch=i386;stamp=1204846772

The following patch below should fix this:

--- postinst2008-02-08 10:13:24.0 -0500
+++ postinst.fixed  2008-03-07 09:38:46.0 -0500
@@ -19,8 +19,10 @@ case $1 in
 chmod 770 /var/run/nut /var/lib/nut
 
 # restart udev to apply the USB rules to the already plugged devices
-[ -x /etc/init.d/udev ]  pidof udevd  /dev/null \
-/usr/sbin/invoke-rc.d udev restart
+# only if it's already running
+if [ -x /etc/init.d/udev ]  pidof udevd  /dev/null; then
+/usr/sbin/invoke-rc.d udev restart
+fi
 ;;
 
   abort-upgrade)

Thanks,
--Joe

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

Kernel: Linux 2.6.24-1-686 (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 [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#464777: (no subject)

[Joe Emenaker]

The problem with the build error is due to the fact that some of the 
mutex defines were removed in 2.6.24.


You can find patches for this by just googling for DEFINE_MUTEX_LOCKED 
lirc_dev.c. One of those patches is here: 
http://www.nabble.com/LIRC-will-not-compile-with-2.6.24-rc1-td13558651.html


Mercifully, the problem only involves only lirc_dev.c and no others... 
and the patch is simple enough that you can do it by hand.


I checked yesterday and it appears that even the upstream CVS version 
*still* has not been patched (which means that even the deb in 
experimental will have this problem).


Turns out that if you fix this and try to build again, you'll hit 
another build error caused by a change in 2.6.23 where the 
unregister_chrdev function now returns a void instead of an int (see a 
patch here: 
http://www.mail-archive.com/debian-bugs-rc@lists.debian.org/msg124309.html). 
I believe that this one *is* fixed in the upstream CVS.


After those patches, I was able to build on 2.6.24.






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

Bug#465748: vm: Sven's patch works

[Joe Pfeiffer]

Package: vm
Followup-For: Bug #465748

This is a confirmation that I've applied Sven's patch against 8.0.9-1:
it applies cleanly and works.  Thanks Sven!

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'stable'), (600, 'unstable'), (500, 
'oldstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-2-k7 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages vm depends on:
ii  emacs [emacsen]  22.1+1-2.3  The GNU Emacs editor (metapackage)
ii  emacs21 [emacsen]21.4a+1-5.3 The GNU Emacs editor
ii  emacs22 [emacsen]22.1+1-2.3  The GNU Emacs editor
ii  make 3.81-3  The GNU version of the make util
ii  ucf  3.005   Update Configuration File: preserv

vm recommends no packages.

-- no debconf information



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

Bug#469312: initramfs-tools: awk reports syntax error in update-initramfs

[Joe Pfeiffer]

Package: initramfs-tools
Version: 0.91e
Severity: critical
Justification: breaks the whole system

Attempting to run update-initramfs is giving me the following result:

snowball:552$ sudo update-initramfs -u 2.6.22-3-k7
update-initramfs: Generating /boot/initrd.img-2.6.22-3-k7
awk: /^md/2/{print substr($5, 1, 3)}
awk:^ syntax error

The resulting initrd image apears to be corrupt -- at any rate, my
kernel panicked shortly after trying to mount it.

-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=Linux ro root=902

-- /proc/filesystems
cramfs
ext3
fuseblk

-- lsmod
Module  Size  Used by
iptable_mangle  3136  0 
iptable_filter  3264  0 
ipt_MASQUERADE  3904  1 
iptable_nat 7556  1 
nf_nat 18348  2 ipt_MASQUERADE,iptable_nat
nf_conntrack_ipv4  18124  2 iptable_nat
nf_conntrack   61000  4 
ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4
nfnetlink   6168  3 nf_nat,nf_conntrack_ipv4,nf_conntrack
ip_tables  12708  3 iptable_mangle,iptable_filter,iptable_nat
x_tables   14660  3 ipt_MASQUERADE,iptable_nat,ip_tables
binfmt_misc11400  1 
via40192  2 
drm76628  3 via
nfsd  204912  13 
exportfs5952  1 nfsd
ppdev   8964  0 
lp 11300  0 
autofs420804  2 
nfs   225452  0 
lockd  61320  3 nfsd,nfs
nfs_acl 3840  2 nfsd,nfs
sunrpc158972  11 nfsd,nfs,lockd,nfs_acl
ipv6  239524  35 
sd_mod 27584  0 
fuse   42388  1 
dm_snapshot16804  0 
dm_mirror  21376  0 
dm_mod 52672  2 dm_snapshot,dm_mirror
snd_via82xx27224  0 
gameport   15304  1 snd_via82xx
snd_ac97_codec 93220  1 snd_via82xx
ac97_bus2560  1 snd_ac97_codec
snd_pcm_oss39904  0 
snd_mixer_oss  15872  1 snd_pcm_oss
snd_pcm72772  3 snd_via82xx,snd_ac97_codec,snd_pcm_oss
snd_page_alloc  9800  2 snd_via82xx,snd_pcm
snd_mpu401_uart 8384  1 snd_via82xx
snd_seq_dummy   4036  0 
snd_seq_oss29760  0 
snd_seq_midi8480  0 
snd_rawmidi23264  2 snd_mpu401_uart,snd_seq_midi
usb_storage77440  0 
parport_pc 34212  1 
parport34312  3 ppdev,lp,parport_pc
evdev   9664  2 
snd_seq_midi_event  7360  2 snd_seq_oss,snd_seq_midi
snd_seq46864  6 
snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
snd_timer  21380  2 snd_pcm,snd_seq
snd_seq_device  8012  5 
snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq
shpchp 31380  0 
usbhid 26144  0 
hid25792  1 usbhid
snd48804  11 
snd_via82xx,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_mpu401_uart,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
i2c_viapro  8788  0 
pcspkr  3392  0 
k8temp  5824  0 
soundcore   7840  1 snd
i2c_core   24000  1 i2c_viapro
rtc13144  0 
pci_hotplug29568  1 shpchp
amd64_agp  12420  1 
agpgart32264  2 drm,amd64_agp
pl2303 20036  0 
usbserial  31976  1 pl2303
usblp  13632  0 
ext3  122632  2 
jbd55848  1 ext3
mbcache 8580  1 ext3
raid1  22784  1 
md_mod 74196  4 raid1
ide_cd 36896  0 
cdrom  33184  1 ide_cd
ide_disk   16832  7 
ata_generic 7876  0 
libata116912  1 ata_generic
scsi_mod  137356  3 sd_mod,usb_storage,libata
via_rhine  24136  0 
mii 5696  1 via_rhine
ehci_hcd   31116  0 
uhci_hcd   23376  0 
usbcore   125704  8 
usb_storage,usbhid,pl2303,usbserial,usblp,ehci_hcd,uhci_hcd
via82cxxx   8964  0 [permanent]
generic 5124  0 [permanent]
ide_core  114436  5 usb_storage,ide_cd,ide_disk,via82cxxx,generic
thermal13768  0 
processor  31368  1 thermal
fan 5124  0 

-- /etc/kernel-img.conf
# Do not create symbolic links in /
Do_Symlinks = 
do_initrd = Yes

-- /etc/initramfs-tools/initramfs.conf
MODULES=most
BUSYBOX=y
KEYMAP=n
BOOT=local
DEVICE=eth0
NFSROOT=auto


-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'stable'), (600, 'unstable'), (500, 
'oldstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-2-k7 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked 

Bug#463159: XCB-enabled libx11 causes hangs in various X clients

[Joe Drew]

Michel Dänzer wrote:
 As it seems threading related: Does XInitThreads() get called and finish
 before any other libX11 function is called?

Yes. (And yes, it's definitely threading-related.)

Bug#453166: More info on Swig 1.31 vs 1.33

[Joe Swatosh]

Hi Peter,

On Jan 29, 2008 5:04 PM, Peter Samuelson [EMAIL PROTECTED] wrote:

 Roderich, thanks for all your hard work!

 Kouhei, Joe, * - can anyone have a look at this compatibility issue
 with svn + ruby + swig 1.3.33?  Roderich Schupp has figured out exactly
 what the problem is, but I have no idea how to address it.

 His analysis applies to 1.4.x.  Apologies if this has already been
 fixed on trunk - I can't easily check, as 'make check-swig-rb' has been
 failing for some time for unrelated reasons, like
 subversion/bindings/swig/ruby/svn/error.rb:68: uninitialized constant
 Svn::Error::WcMismatchedChangelist (NameError).





I'm not sure how much help I can be.  The Ruby bindings never worked on
Windows for 1.4, but I've downloaded SWIG 1.3.33 and after I get the
bindings tests passing again I will try it out as time allows.

--
Joe



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

Bug#463159: reassigning

[Joe Drew]

reassign 463159 libxcb1 1.1-1
forwarded 463159 http://bugs.freedesktop.org/show_bug.cgi?id=9528
thanks

This bug is actually in libxcb1, not libx11-6. (Although I'm willing to
be proven wrong, and that it's some *interaction* between libx11 and
libxcb that's causing it.)



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

Bug#463159: XCB-enabled libx11 causes hangs in various X clients

[Joe Drew]

Package: libx11-6
Version: 2:1.1.3-1
Severity: critical

This is only 'critical' because it causes unrelated software (e.g., Side
Effects Software's Houdini) to break by causing hangs. Feel free to
downgrade, but this is a very important bug to me, at least.

This is also reported upstream:
http://bugs.freedesktop.org/show_bug.cgi?id=9528

Simply upgrading to a XCB-enabled libx11 build causes clients to start
hanging inside _XReply. There is a bunch of analysis at
http://lists.freedesktop.org/archives/xcb/2007-August/002961.html too.

To reproduce, download a build of Houdini 9.0 from www.sidefx.com and
run it. You will see various hangs almost immediately upon running
'houdini'.

I can help with all manner of debugging; I just don't understand X (and
in particular, libx11 and XCB) enough to do this myself.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.22-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libx11-6 depends on:
ii  libc6 2.7-6  GNU C Library: Shared libraries
ii  libx11-data   2:1.0.3-7  X11 client-side library
ii  libxcb-xlib0  1.1-1  X C Binding, Xlib/XCB interface li
ii  libxcb1   1.1-1  X C Binding
ii  x11-common1:7.3+10   X Window System (X.Org) infrastruc

libx11-6 recommends no packages.

-- no debconf information



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

Bug#455684: crashes x server

[Joe Nahmias]

Package: torus-trooper
Version: 0.22.dfsg1-1
Severity: critical

Hello,

Running torus-trooper on my Thinkpad T61 causes the X server to crash
and constantly restart.

Any tips on how to debug this?

--Joe


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

Kernel: Linux 2.6.22-3-686 (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 torus-trooper depends on:
ii  libbulletml0d1  0.0.6-2  C++ library to handle BulletML eas
ii  libc6   2.6.1-6  GNU C Library: Shared libraries
ii  libgcc1 1:4.2.2-3GCC support library
ii  libgl1-mesa-glx [libgl1]7.0.1-2  A free implementation of the OpenG
ii  libglu1-mesa [libglu1]  7.0.1-2  The OpenGL utility library (GLU)
ii  libsdl-mixer1.2 1.2.8-1  mixer library for Simple DirectMed
ii  libsdl1.2debian 1.2.12-1 Simple DirectMedia Layer
ii  libstdc++6  4.2.2-3  The GNU Standard C++ Library v3
ii  torus-trooper-data  0.22.dfsg1-1 speeding ship sailing through barr

torus-trooper recommends no packages.

-- no debconf information



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

Bug#453767: no longer starts after python-gst0.10 upgrade

[Joe Wreschnig]

reassign 453767 python-gst
thanks
i'd really prefer to terminate commands with fucking idiots though

On Fri, 2007-11-30 at 22:09 -0500, Ari Pollak wrote:
 Package: quodlibet
 Version: 1.0-1
 Severity: grave
 
 quodlibet no longer starts after upgrading python-gst0.10. It fails with
 lots of errors like this:
 Traceback (most recent call last):
   File /usr/share/quodlibet/formats/__init__.py, line 22, in ?
 try: format = __import__(name, {}, {}, self)
   File /usr/share/quodlibet/formats/xiph.py, line 131, in ?
 if gst.registry_get_default().find_plugin(plugin) is not None:
 AttributeError: 'module' object has no attribute 'registry_get_default'

After upgrading, this happens to me if I have python-gst0.10 and
python-gst both installed.

$ python
 import pygst
 pygst.require(0.10)
 import gst
 gst.gst_version
(0, 8, 12)

I don't know who broke what when, but this is not a bug in Quod Libet. A
temporary fix is to remove the python-gst (which is for 0.8) package.
-- 
Joe Wreschnig [EMAIL PROTECTED]


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

Bug#452679: [Pkg-tcltk-devel] Bug#452679: tcl8.5: FTBFS: out of stack space (infinite loop?)

[Joe English]

Upstream bug report: 

http://sourceforge.net/support/tracker.php?aid=1815573

In the meantime, compiling with -DNO_TCL_CHECK_STACK_SPACE
should avoid the problem.



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

Bug#433657: contains /etc/defoma/config, as does gs-common

[Joe Drew]

Package: libpango1.0-common
Version: 1.16.4-1
Severity: serious

dpkg: error processing
/var/cache/apt/archives/libpango1.0-common_1.16.4-3_all.deb (--unpack):
trying to overwrite `/etc/defoma/config', which is also in package gs-common

This has been the case for a few days now. I don't see the bug on pango
or gs-common, so I'm reporting it now. Sorry if it's a duplicate.

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

Kernel: Linux 2.6.21-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libpango1.0-common depends on:
ii  debconf [debconf-2.0]1.5.13  Debian configuration management sy
ii  defoma   0.11.10-0.1 Debian Font Manager -- automatic f
ii  fontconfig   2.4.2-1.2   generic font configuration library

Versions of packages libpango1.0-common recommends:
pn  libpango1.0-0 none (no description available)
ii  x-ttcidfont-conf  25.1   Configure TrueType and CID fonts f

-- no debconf information


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

Bug#425061: crashes immediately on startup

[Joe Drew]

Package: icedove
Version: 2.0.0.0-1
Severity: grave

$ icedove --debug
/usr/lib/icedove/run-mozilla.sh -g /usr/lib/icedove/icedove-bin
MOZILLA_FIVE_HOME=/usr/lib/icedove
  
LD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove/plugins:/usr/lib/mre/mre-2.0.0.0:.:/home/joe/dev/hfs/dsolib:/home/joe/dev/hfs/custom/houdini:/home/joe/dev/hfs/python/lib
DISPLAY=:0.0
DYLD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/mre/mre-2.0.0.0
 
LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove/components:/usr/lib/mre/mre-2.0.0.0
   SHLIB_PATH=/usr/lib/icedove:/usr/lib/mre/mre-2.0.0.0
  LIBPATH=/usr/lib/icedove:/usr/lib/mre/mre-2.0.0.0
   ADDON_PATH=/usr/lib/icedove
  MOZ_PROGRAM=/usr/lib/icedove/icedove-bin
  MOZ_TOOLKIT=
moz_debug=1
 moz_debugger=
/usr/bin/gdb /usr/lib/icedove/icedove-bin -x /tmp/mozargs.B22931
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as x86_64-linux-gnu...
(no debugging symbols found)
Using host libthread_db library /lib/libthread_db.so.1.
(gdb) r

[...]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47879557200416 (LWP 22934)]
0x2aaab05e5b51 in ?? () from /usr/lib/icedove/components/libgklayout.so
(gdb) bt
#0  0x2aaab05e5b51 in ?? () from /usr/lib/icedove/components/libgklayout.so
#1  0x2aaab05e6965 in ?? () from /usr/lib/icedove/components/libgklayout.so
#2  0x2aaab06e2d78 in ?? () from /usr/lib/icedove/components/libgklayout.so
#3  0x2aaab05f072f in ?? () from /usr/lib/icedove/components/libgklayout.so
#4  0x2aaab05f2248 in ?? () from /usr/lib/icedove/components/libgklayout.so
#5  0x2aaab05dc845 in ?? () from /usr/lib/icedove/components/libgklayout.so
#6  0x2aaab0632558 in ?? () from /usr/lib/icedove/components/libgklayout.so
#7  0x2aaab05bebad in ?? () from /usr/lib/icedove/components/libgklayout.so
#8  0x2aaab072898c in ?? () from /usr/lib/icedove/components/libgklayout.so
#9  0x2aaab0806d74 in ?? () from /usr/lib/icedove/components/libgklayout.so
#10 0x2aaab168fae6 in ?? () from /usr/lib/icedove/components/libhtmlpars.so
#11 0x2aaab1693fbd in ?? () from /usr/lib/icedove/components/libhtmlpars.so
#12 0x2aaab1694338 in ?? () from /usr/lib/icedove/components/libhtmlpars.so
#13 0x2aaab16947f2 in ?? () from /usr/lib/icedove/components/libhtmlpars.so
#14 0x2aaab169150a in ?? () from /usr/lib/icedove/components/libhtmlpars.so
#15 0x2aaab16a5e06 in ?? () from /usr/lib/icedove/components/libhtmlpars.so
#16 0x2aaab16a8ac8 in ?? () from /usr/lib/icedove/components/libhtmlpars.so
#17 0x2aaab16a54cf in ?? () from /usr/lib/icedove/components/libhtmlpars.so
#18 0x2b8bd61e54de in ?? () from /usr/lib/icedove/components/libnecko.so
#19 0x2b8bd61e55e4 in ?? () from /usr/lib/icedove/components/libnecko.so
#20 0x2b8bcfca1305 in ?? () from /usr/lib/icedove/libxpcom_core.so
#21 0x2b8bcfcbc389 in PL_HandleEvent ()
   from /usr/lib/icedove/libxpcom_core.so
#22 0x2b8bcfcbc62b in PL_ProcessPendingEvents ()
   from /usr/lib/icedove/libxpcom_core.so
#23 0x2b8bcfcbe0fb in ?? () from /usr/lib/icedove/libxpcom_core.so
#24 0x2ad098a2 in ?? ()
   from /usr/lib/icedove/components/libwidget_gtk2.so
#25 0x2b8bd27916d4 in g_main_context_dispatch ()
   from /usr/lib/libglib-2.0.so.0
#26 0x2b8bd279450d in ?? () from /usr/lib/libglib-2.0.so.0
#27 0x2b8bd279481a in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#28 0x2b8bd07b2b13 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#29 0x2ad09c3c in ?? ()
   from /usr/lib/icedove/components/libwidget_gtk2.so
#30 0x2ba0e67e in ?? ()
   from /usr/lib/icedove/components/libtoolkitcomps.so
#31 0x00408414 in ?? ()
#32 0x2b8bd31ba8e4 in __libc_start_main () from /lib/libc.so.6
#33 0x00403959 in ?? ()
#34 0x7fffdb54d618 in ?? ()
#35 0x in ?? ()
(gdb) 


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

Kernel: Linux 2.6.20-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages icedove depends on:
ii  debianutils 2.18.2   Miscellaneous utilities specific t
ii  fontconfig  2.4.2-1.2generic font configuration library
ii  libatk1.0-0 1.18.0-2 The ATK accessibility toolkit
ii  libc6   2.5-7GNU C Library: Shared libraries
ii  libcairo2   1.4.6-1  The Cairo 2D vector graphics libra
ii  libfontconfig1  2.4.2-1.2generic font configuration library
ii  libfreetype6

Bug#421167: quodlibet: fails to start, claiming 'filesrc' cannot be found

[Joe Wreschnig]

On Fri, 2007-04-27 at 09:15 +0200, Sebastian Dröge wrote:
 Am Donnerstag, den 26.04.2007, 20:09 -0700 schrieb Joe Wreschnig:
 I agree that the fix for this bug was not at all complete and this special
 case should be handled too. Is file:// the only URL that causes a problem 
 for
 you or is quodlibet using file://blabla/bla in general? (note that there 
 are only
 two slashes after the colon)

 file:// is not a valid URI, it's only the protocol part of some URI. Then 
 according
 to rfc1738 file://blabla/bla corresponds to the location /bla on the host 
 blabla.

Yes, I know; http://; is also not a valid URL, but it's what I was told
in #gstreamer to use to check for generic HTTP support (whether via
gnomevfs or neon), so I assumed that file:// was similar. Quod Libet
hands correctly formed URIs to the playbin to play actual files.

 Then, if quodlibet wants to check for the element filesrc it should just 
 check if it
 can create a filesrc element and not check if there is some random element 
 that might
 support the file:// protocol.

Actually I don't care if there's a filesrc element, I just care if
something supports file://. But the error message mentions filesrc
because users have no idea what Get an element that supports file://
means; they have a better idea what Install filesrc means, and this
has helped people diagnose a lot of broken GStreamer installations in
the past.

 Apart from that, would you be fine if I just special case file:// and allow 
 that as
 a valid URI for filesrc as a workaround for this?

Yes.
-- 
Joe Wreschnig [EMAIL PROTECTED]


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

Bug#421167: quodlibet: fails to start, claiming 'filesrc' cannot be found

[Joe Wreschnig]

On Thu, 2007-04-26 at 23:21 +0200, Martin wrote:
 Package: quodlibet
 Version: 0.23.1-1
 Severity: grave
 Justification: renders package unusable
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Quod Libet fails to start, pops up a message saying Quod Libet could
 not find the 'filesrc' GStreamer element. Check your GStreamer
 installation. It used to work fine before/during the freeze.

Sounds like something in GStreamer changed. QL actually tries to create
that element by checking the result of
gst.element_make_from_uri(gst.URI_SRC, file://, ), which previously
returned whatever element would handle a file URL. We didn't actually
care what it was, as long as it existed (filesrc is just the most
common / only? one).

I can't reproduce this, but you're the third person I've heard it from
and across three distros.

This is a grave GStreamer bug.
-- 
Joe Wreschnig [EMAIL PROTECTED]


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

Bug#421167: quodlibet: fails to start, claiming 'filesrc' cannot be found

[Joe Wreschnig]

On Thu, 2007-04-26 at 23:21 +0200, Martin wrote:
 Package: quodlibet
 Version: 0.23.1-1
 Severity: grave
 Justification: renders package unusable
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Quod Libet fails to start, pops up a message saying Quod Libet could
 not find the 'filesrc' GStreamer element. Check your GStreamer
 installation. It used to work fine before/during the freeze.
 ...
 Versions of packages quodlibet recommends:
 ii  gstreamer0.10-alsa0.10.12-2  GStreamer plugin for ALSA
 pn  gstreamer0.10-gnomevfsnone (no description available)

^-- This would be why. In 0.10.10 and all previous versions, a filesrc
object would be returned:

 gst.element_make_from_uri(gst.URI_SRC, file://, )
__main__.GstFileSrc object () at 0x402076bc

Now, in unstable:
 gst.element_make_from_uri(gst.URI_SRC, file://, )
__main__.GstGnomeVFSSrc object () at 0xb7d6393c

And if I remove gstreamer0.10-gnomevfs:
 gst.element_make_from_uri(gst.URI_SRC, file://, )


So, filesrc is in fact broken.

Blah blah API compatibility, blah blah you need unit tests, blah blah,
no one listens to me, blah STOP BREAKING MY SOFTWARE DAMNIT.

The GStreamer changelog says:

2007-02-13  Sebastian Dröge  [EMAIL PROTECTED]

* plugins/elements/gstfilesink.c: (gst_file_sink_uri_set_uri):
* plugins/elements/gstfilesrc.c: (gst_file_src_uri_set_uri):
Also check for an absolute path following file:// in the filesrc
element. Remove redundant check and call g_path_is_absolute() on the
unescaped location.

Sebastian, do you understand what an API is, and why changes like that
ARE NOT ALLOWED, especially in point releases?
-- 
Joe Wreschnig [EMAIL PROTECTED]


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

Bug#419225: printf_fp crashes again

[Joe Drew]

reopen 419225
found 419225 2.5-3
thanks

This bug was fixed in libc6 2.5-2, but it regressed in 2.5-3. Maybe  
this test case should be made part of the libc6 regression tests?


Joe


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

Bug#356853: an reflection meditation hunting

[joe Hung]

shipped edit titlesedit FourThe Carey
http://img444.imageshack.us/img444/9128/kbxpws9.gif
virgi nicolesefu beauty hangiganmy bomance



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

Bug#407956: CVE-2006-4192: buffer overflow

[Joe Wreschnig]

On Mon, 2007-01-22 at 16:07 +0100, Loïc Minier wrote:
 Package: gst-plugins-bad0.10
 Version: 0.10.3-3
 Severity: serious
 Tags: security patch
 
 Hi,
 
  gst-plugins-bad0.10 is affected by CVE-2006-4192: buffer overflow in
  gst/modplug/libmodplug/sndfile.cpp.  See GNOME #385788.
 
  Please let me know if I may upload the proposed NMU patch (attached).

Yes, go ahead.
-- 
Joe Wreschnig [EMAIL PROTECTED]


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

Bug#400237: Incorrect licensing information

[Joe Wreschnig]

Package: angrydd
Severity: serious
Version: 1.0.1-1

According to debian/copyright:
License:

   This package is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or
   (at your option) any later version.

This is absolutely incorrect. As the COPYING file and all source files
clearly state,

Unless otherwise noted above, all material (source code, documentation,
and game data) is licensed under the GNU GPL version 2 as published by
the Free Software Foundation, copyrighted by the owners credited above.
The full text of the license follows.

or

# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.

Please just copy the beginning (pre-GPL portion) of the COPYING file,
and be more careful in the future.
-- 
Joe Wreschnig [EMAIL PROTECTED]


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

Bug#390309: python-gst0.10: module interface changed, breaks quodlibet and possibly others

[Joe Wreschnig]

On Sat, 2006-09-30 at 13:19 +0200, Bastian Kleineidam wrote:
 Package: python-gst0.10
 Version: 0.10.5-4
 Severity: serious
 Justification: breaks unrelated software
 
 Hi,
 
 after upgrading to 0.10.5-4, quodlibet stopped working and gave this
 error message:
 Traceback (most recent call last):
   File /usr/bin/quodlibet, line 301, in ?
 main()
   File /usr/bin/quodlibet, line 33, in main
 library = load_library()
   File /usr/bin/quodlibet, line 255, in load_library
 lib = library.init(const.LIBRARY)
   File /usr/share/quodlibet/library/__init__.py, line 38, in init
 library.load(cache_fn, skip=True)
   File /usr/share/quodlibet/library/_library.py, line 124, in load
 try: items = pickle.load(fileobj)
   File /usr/share/quodlibet/formats/mp3.py, line 15, in ?
 if gst.registry_get_default().find_plugin(mad) is None:
 AttributeError: 'module' object has no attribute 'registry_get_default'
 
 Downgrading to 0.10.5-3 made quodlibet working again. So it seems that
 some change between -3 and -4 changed the module interface.
 
 Feel free to ask if you need more info or test runs.

[EMAIL PROTECTED]:~$ python
Python 2.4.4c0 (#2, Jul 30 2006, 15:43:58)
[GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)] on linux2
Type help, copyright, credits or license for more information.
 import pygst
 pygst.require(0.10)
 import gst
 gst.gst_version, gst.pygst_version
((0, 8, 12), (0, 8, 4))

That would be why it broke. I suspect something broke the import order
when it switched from python-central to python-support.
-- 
Joe Wreschnig [EMAIL PROTECTED]


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

Bug#382157: pycentral refuses to overwrite local files

[Joe Wreschnig]

Package: python-central
Version: 0.5.1
Severity: grave

I originally reported this at [0]; this is just a copy/paste of that
email (with an updated version of the error message). I mentioned there
that I thought it was grave (it prevents python from installing), and I
got no responses either way, so that's how I'm reporting it.

When installing a package that uses pycentral, that I had previously
installed by hand, I got an error:

Setting up python2.3 (2.3.5-15) ...
byte-compiling files for package python2.3...
Linking and byte-compiling packages for runtime python2.3...
pycentral: pycentral rtinstall: package python-mutagen: already exists: 
/usr/lib/python2.3/site-packages/mutagen/__init__.py
pycentral rtinstall: package python-mutagen: already exists: 
/usr/lib/python2.3/site-packages/mutagen/__init__.py
dpkg: error processing python2.3 (--configure):
 subprocess post-installation script returned error exit status 1

I think making this an error is a bad decision. File conflicts within
the packaging system should already be dealt with via dpkg. Outside of
the package system, dpkg always silently overwrites local
non-configuration files, and it's not an error normally.

This is particularly bad for Python, because the default install prefix
for local software is /usr, and there's no distutils uninstall command.
So you have to manually find and remove all the files from any
locally-installed package to switch to dpkg's version.

Unless there's a good reason for this behavior, I think this is a grave
bug for pycentral, since no other part of the packaging system creates
errors in this situation.

[0] http://lists.debian.org/debian-python/2006/06/msg00292.html
-- 
Joe Wreschnig [EMAIL PROTECTED]


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

Bug#375651: patch for pydance

[Joe Wreschnig]

On Sat, 2006-08-05 at 21:31 +0200, Luca Bruno wrote:
 tags 375651 patch
 thanks
 
 Hi Joe,
 I couldn't contact you on IRC :(
 
  If Pygame 1.8 (or SVN) doesn't make it into Debian before etch, I'm
  okay with removing pydance from the release.
 
 It would be a pity to have pydance out of etch.
 So I've made a patch for it. 
 It basically adds AA to text, so pydance doesn't crash anymore.
 
 Please apply it ASAP and let it migrate to etch ;)

Thank you for this!

I will try to get to this soon, but that might be a while. I'm busy with
other projects + potentially moving at the moment. NMUs appreciated, as
the patch looks good to me. There might be more places where pydance
renders non-AA text, but I can't think of any at the moment. (pydance
may also need to be updated for the new new Python policy.) 

 Also, I can't see difference with the SVN version of this:
 http://kai.vm.bytemark.co.uk/svn/pydance/trunk/pydance/fontfx.py
 
 So please forward the patch upstream.

I am upstream. I'd rather not merge it there, because really is an
SDL/Pygame bug (which will be fixed in 1.8; Pygame also has a regression
test for it now, so hopefully it won't happen again).
-- 
Joe Wreschnig [EMAIL PROTECTED]


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