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: 
# 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#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#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#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#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   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#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#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"  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#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#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#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  dmalloc(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   (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(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#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]

Hi Riku,

On Wed, May 07, 2008 at 02:48:53PM +0300, Riku Voipio wrote:
> On Tue, May 06, 2008 at 07:41:10PM +0000, 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#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 +0000, 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 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#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]

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#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#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]