Bug#854727: Removal from stretch?

[Scott Howard]

I was contacted by someone at SUSE that is working on fixing the security
bugs - but even if successful, I don't know how good the quality will be or
how much testing will be able to get done before stretch is released.
Removal might be safest option

Bug#822709: cgminer now builds with gcc 6

[Scott Howard]

Hi - I can't reproduce this anymore, and reproducible builds have been
able to compile cgminer with the new gcc default:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/cgminer.html

Maybe something changed somewhere else?

Closing for now.

Thanks

Bug#804531: eagle: cannot be rebuilt against libssl1.0.2

[Scott Howard]

On Wed, May 11, 2016 at 7:23 AM, Sebastian Andrzej Siewior
<sebast...@breakpoint.cc> wrote:
> On 2016-05-10 18:19:02 [-0400], Scott Howard wrote:
>> I agree with this assessment. I'll raise the issue upstream. It's
>> non-free, so not too high on my priority list (and not much I can do
>> on my own anyways...)
>
> Could you please open a RM bug against ftp-master? There is no need to
> keep this in unstable, right? It holds back libssl1.0.0.
> Alternatively I could do it for you once I sorted most of the few other
> packages that hold on to libssl1.0.0 as well…
>
>> Thanks, everyone.
>> ~Scott
>
> Sebastian

Yes, I'll file a RM request. Upstream got back to me, they're working
on it - but no need to hold up ssl for now.
~Scott

Bug#804531: eagle: cannot be rebuilt against libssl1.0.2

[Scott Howard]

Thank you Sebastian,

On Mon, May 9, 2016 at 6:14 PM, Sebastian Andrzej Siewior
 wrote:
> On 2016-04-22 00:19:58 [+0200], Andreas Beckmann wrote:
>> Since the only API/ABI difference between libssl1.0.0 and libssl1.0.2 is
>> the removal of some symbols, you could try the following:
> …
>
> | $ readelf -a bin/eagle|grep -i SSLv3
> |09aa3640  00019607 R_386_JUMP_SLOT      SSLv3_client_method
> |09aa36ec  0001c207 R_386_JUMP_SLOT      SSLv3_server_method
> |   406:  0 FUNCGLOBAL DEFAULT  UND SSLv3_client_method
> |   450:  0 FUNCGLOBAL DEFAULT  UND SSLv3_server_method
>
> Haven't tried it but it seems that the binary uses the removed symbols.
>
> Besides I looked at the license [0]:
> - 2.1.b says "not to … vary or modify the Software" so I think the
>   change of libssl1.0.0 -> .2 is not permitted.

I agree with this assessment. I'll raise the issue upstream. It's
non-free, so not too high on my priority list (and not much I can do
on my own anyways...)

Thanks, everyone.
~Scott

Bug#797165: freeimage: fixing CVE hints

[Scott Howard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello - Freeimage > 1.5.4 (that is, the current sid version) requires
OpenJPEG 2.1.0, which is not in Debian. I wasted some time trying to
make freeimage 1.7 work with openjpeg 1.5, but it's taking a bit too
much time. At this moment, the best course of action may be to simply
carry the new patches Raphael pointed out rather than updating
freeimage then working to remove openjpeg 2.1 support. Just a hint, if
you're ambitious, please don't let my comment stop you.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV9wT8AAoJEI7QYGkDfiTykTIP/2+mXufK8+v5FwaaYrC9DqUA
dLIpLu8BzXvFNi7fxKSdeQ7TpccIUcRZPlijrSNC93spZgNmsfR98xtmUAcSC3W9
QqrUSSZOOr6Rn5vdWpHRpVZS2wYICnzGLX5AmPh+LpLXImAoWbu28d2vsU6GMAsN
qWcH7NGuu/37iH5oMxBUuJ9y1Bgd7HruOl80O9SN+M9b90XxTiFIN2nCKAhtZxgv
8wldA2jCTgWX7mOW5Xd/mz0s+JJzlUiDjTj9xadSyrXSgR0JEE86mpCHs5uqJUZQ
Ngje4+SffS2Z/PIycP3uv855N/nrinEMejHDaQ1o/GFIk4fymImZ6yB90Z2buU0y
oKpVN0iaRcmGZcHycuBrGgvB6ev9wIlD4rzPlhHWFUJ9Kyadt8Gud6AfCAEDLF7n
99TvK86y2xL8pwj0RLqB3Yf0YV/Fp+5HZuG+qBgcJH8c9GGx9ZHhmzuboFJS/xTD
L+4hJYYxiHP1n1uJ7NUN3ReOx4OmIJRHRwck5qfJCVMv+tQU+zHQ4H40/vfip07u
j4dTz+t+TudWohHu2i7Fo5cFKE3Ec7n8bRYLHdp4nhn2d+3LSr27RER64fae8PWv
PSmYsv7YumjhnqrETQrpmugqJziJnAA0VFW1OYQEZl/UQtXf5B75TDt9y27kEJ4H
mLbU4ErFThcRv/rMNQDV
=ojF1
-END PGP SIGNATURE-

Bug#796902: python-scipy: FTBFS: dh: unable to load addon sphinxdoc

[Scott Howard]

Fix appears to be in SVN
http://anonscm.debian.org/viewvc/python-modules?view=revisionrevision=33993

Bug#791209: Patched muparser for gcc 5 transitio

[Scott Howard]

tags 791209 patch
user release.debian@packages.debian.org
usertag 791209 + transition
block 791209 by 790756
reassign 791209 release.debian.org
thanks

Hello,

Package renamed to libmuparser2v5.
See patch:
http://anonscm.debian.org/cgit/debian-science/packages/muparser.git/patch/?id=5fb47ad4af6a7e4cdddbb078b7159d552c0e1f86

The package is ready for upload to unstable:
http://anonscm.debian.org/cgit/debian-science/packages/muparser.git

I can take care of it whenever it is clear for transition, or it can
be NMUed if that is easier.
Cheers,
Scott


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

Bug#790403: build still fails, bitcoin 0.10.2

[Scott Howard]

reopen 790403
thanks

Failed again, even with
xvfb-run -a dh_auto_test

I can't reproduce the build failure, so I'd appreciate any tips.

I'll next try
xvfb-run -a make check
~Scott


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

Bug#767379: eagle: don't depend on libjpeg62 nor libpng anymore

[Scott Howard]

severity 767379 serious
thanks

In testing/sid: eagle depends on libjpeg62-dev which is now a virtual
package. Also, libpng-dev dependency can be dropped as well.

In wheezy, the dependency on libjpeg62 was deprecated, so you're right
- that warning/error doesn't matter for stable and the programs should
work normally.

Also there are unresolved references to ssl symbols:
dpkg-shlibdeps: warning: debian/eagle/usr/lib/eagle/bin/eagle contains
an unresolvable reference to symbol DSA_free: it's probably a plugin
(and 100+ others)...

probably should be cleaned up before release.


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

Bug#767379: eagle: don't depend on libjpeg62 nor libpng anymore

[Scott Howard]

fixed 767379 6.3.0-1
thanks

Upon further investigation, eagle in unstable and testing does not
depend on libjpeg62 nor libpng - this was fixed in 6.3.0-1. Also, the
bug mentioned here appears to only occur if someone tries to install
the wheezy eagle package on the jessie system system jessie does not
have the libjpeg2 library the wheezy eagle package expects.

The solution could be to install both the wheezy eagle package and the
wheezy libjpeg62 package. However, that may conflict with the jessie
libjpeg62-turbo package. Either way, the binary will still work but
you may end up with a misconfigured dpkg. The solution to that is to
uninstall eagle before upgrading the system, then reinstall.

Since Debian doesn't support forward-porting of packages from previous
releases, I'm closing the bug.


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

Bug#754682: [Pkg-bitcoin-devel] Bug#754682: cgminer: FTBFS on kfreebsd-*: expected '=', ',', '; ', 'asm' or '__attribute__' before 'transfer_callback'

[Scott Howard]

Thanks,

On Sun, Jul 13, 2014 at 8:53 AM, Cyril Brulebois k...@debian.org wrote:
 your package no longer builds on kfreebsd-*:

This is due to:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749157

We can easily do a work around until the above patch is fixed


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

Bug#718272: [Pkg-bitcoin-devel] Bug#718272:

[Scott Howard]

Thank you, Chris. I think you articulated the situation well and the options.


On Wed, Jun 25, 2014 at 1:18 PM, Chris Bainbridge
chris.bainbri...@gmail.com wrote:
 This is not necessary as the debian-installer already enables
 stable-updates by default.

stable-updates is enabled by default, but not stable-proposed-updates.
That means that users will have to wait on the order of 2 months or
more for new versions. security updates are instantaneous and is
probably the better way of handling network changes that cannot be
delayed.

 Backporting is not necessary. The package can be version bumped for a
 security update, or version bumped in stable-updates for non-security
 changes. In the case of Bitcoin, mandatory network changes could
 arguably be considered security updates if they prevent the bitcoin
 server from working, because being unable to update the copy of the
 blockchain would open up additional attack vectors.

I agree mandatory network changes can be argued to be a security
update and could be the best way forward, but they do not prevent the
bitcoin server from working. It still works and creates a fragmented
network with every other non-updated server. That network acts just
like the real network and could, in theory, supplant or reject the
real network. That's what happened here [1]. It wasn't really a
security threat as much as a incompatibility in the protocols with a
potential for financial loss. This is a new area for Debian: data
loss, corruption, exploitation, unauthorized access are all clearly
security bugs, but is potential financial loss from to a working as
intended system a security bug? Maybe, we'd need the security team's
opinion on that.

 tor has very similar restrictions (version 1.0, network protocol
 could change) and yet it is in both stable and testing. Testing
 already has other software (cgminger, bfgminer) that is reliant on the
 bitcoin protocol. Given all this, I do not think that the problems
 presented in this bug are a reason to hold up bitcoin from entering
 testing or, ultimately, stable.

I think it's possible for us to get the package ready for release in
jessie if we have a proper management plan. There are 3 possible
changes to bitcoin:

1) Security fixes
2) Network protocol changes [2]
3) New features/usability bug fixes

We need a plan that allows us to definitely fix 1 and 2 for users in a
stable release as needed on short notice.

1) is clearly doable via security updates.
2) is harder. stable-updates takes too long (see above). Protocol
changes are not traditional security bugs, but might be classified as
one. It's a different situation than tor [3].
3) doable via stable-updates (or backports)

This is my opinion, but if we can get someone from the security team
to say that they will accept bitcoin network protocol changes as
security bugs, then I think that would be acceptable to do 1 and 2 via
security AND also update the package to new versions using
stable-updates. This is my opinion, but I think 2 months+ is too long
for default users to wait for network protocol changes which sometimes
require a response on the order of days or hours. We'd also have to
remember to patch both the stable and stable-updates version of the
package for each protocol change. As you can see, this gets
complicated, and there is much downside if something goes wrong - thus
my general uneasiness towards having bitcoin in a stable release.

Something to keep in mind: this may be confusing to some users when
they are told they must upgrade to version 0.10, and we keep 0.9-2
where our -2 includes the required protocol changes in 0.10, but that
isn't that big of a problem and would just require proper
communication probably via the debian news and changelog files.

In somewhat related news, bitcoin is talking about splitting the
wallet out from the node. An SPV wallet will be safe to ship in a
stable release, even if the nodes are not.


In summary: I think the next step is for someone to contact the
security team to see what they think of the situation.

Cheers,
Scott


[1] https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki

[2] cgminer and bfgminer actually don't rely on the bitcoin protocol,
they use either JSON RPC commands or the stratum protocol and are
independent of the bitcoin protocol. Yes, that interface can (and
does) change, but such changes are not as catastrophic as a bitcoin
fork and have been backwards compatible in the past.

[3] Like tor, if a large percentage of users are using the wrong
version of the bitcoin protocol, it is possible that the network will
become fragmented. A fragmented bitcoin network could lead to lost
transactions for the specific user and damage bitcoin's credibility
(leading to large financial losses for every user of the network). I
may be wrong, but I believe tor fragmentation is serious, but not as
grave (if the tor network fragments due to a non-security based
protocol change, all that happens is the network of peers 

Bug#718272: [Pkg-bitcoin-devel] Bug#718272:

[Scott Howard]

On Wed, Jun 25, 2014 at 2:50 PM, Scott Howard showard...@gmail.com wrote:
 Thank you, Chris. I think you articulated the situation well and the options.

one more thing: debian is discussion dropping libdb (the db the node,
but not the wallet, uses). That might force our hand as well: either
ship and support upstream's included libdb or drop the node and just
ship the wallet. libdb long-term security maintenance might be
challenging.


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

Bug#718272: [Pkg-bitcoin-devel] Bug#718272:

[Scott Howard]

On Wed, Jun 25, 2014 at 3:11 PM, Luke Dashjr l...@dashjr.org wrote:
 On Wednesday, June 25, 2014 6:53:57 PM Scott Howard wrote:
 On Wed, Jun 25, 2014 at 2:50 PM, Scott Howard showard...@gmail.com wrote:
  Thank you, Chris. I think you articulated the situation well and the
  options.

 one more thing: debian is discussion dropping libdb (the db the node,
 but not the wallet, uses). That might force our hand as well: either
 ship and support upstream's included libdb or drop the node and just
 ship the wallet. libdb long-term security maintenance might be
 challenging.

 You mean LevelDB? Debian should use the embedded copy regardless, due to the
 consensus-critical requirements.

 It is not possible to build BCCore wallets without the node at this time.

You're right, brain slip: Debian is using the embedded leveldb
distributed by bitcoin for the blockchain and have for several months.

Berkeley DB is used for wallets. Berkeley DB (libdb) is what is going
to be dropped since they were re-licensed AGPL3 (amongst other
reasons). Debian has been using Berkeley DB for a while in bitcoin
(long before I got involved) with the --with-incompatible-libdb
configure flag, so this may cause a problem since BDB has notorious
compatibility issues between versions.


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

Bug#718272: [Pkg-bitcoin-devel] Bug#718272: Bug#718272: Bug#718272: Bitcoin still not ready for stable release in Debian

[Scott Howard]

On Tue, Dec 17, 2013 at 6:16 PM, Dmitry Smirnov only...@debian.org wrote:
 Hi Scott,

 For your information I have a case that you might find interesting:

 Zabbix did not meet release criteria and was removed from testing
 just before release of Wheezy. Ever since yours truly was maintaining
 it in wheezy-backports.

 Why wouldn't we seek backports manager(s)' permission to provide
 bitcoin in wheezy-backports?

Sorry for long delay, just saw this.

This sounds good., it will give us the control to prevent stable
release with the flexibility of constant updates. Users will have to
enable backports, and thus know and be willing to keep the package up
to date. I think it's crucial that we have several people working to
keep the package up to date in backports, since it will not be
automatic. There is more work, but I think this fits all the
requirements upstream wants (flexibility of updating) with the way
things work in Debian. We'd keep this bug open to prevent transition
to stable, but maintain the package in unstable and backports
directly.

If someone wants to work and backport and maintain bticoin in
backports, long-term, I think that's a good idea. It might be more
responsibility than I can take on at the moment, however.

~Scott


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

Bug#743299: arduino: block migration to testing, jssc/bossac/libastylej validation

[Scott Howard]

Source: arduino
Version: 1:1.5.6.2+dfsg2-1
Severity: serious


block migration to testing. Need to have more testing on:
jssc (new serial implementation)
bossac (upload to avr32 devices)
astyle/libastylej (autoformating of code)


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

Bug#742418: astyle FTBFS on s390x: use -fPIC instead of -fpic when building shared libraries

[Scott Howard]

Package: astyle
Version: 2.03-1.1
Severity: serious

build log:

obj/astyle_main_sj.o: In function `Java_AStyleInterface_AStyleGetVersion':
/«PKGBUILDDIR»/build/gcc/../../src/astyle_main.cpp:3103:(.text+0x35c):
relocation truncated to fit: R_390_GOT12 against symbol `astyle::g_version'
defined in .data.rel.local section in obj/astyle_main_sj.o
obj/astyle_main_sj.o: In function `AStyleGetVersion':
/«PKGBUILDDIR»/build/gcc/../../src/astyle_main.cpp:3253:(.text+0x386):
relocation truncated to fit: R_390_GOT12 against symbol `astyle::g_version'
defined in .data.rel.local section in obj/astyle_main_sj.o
obj/astyle_main_sj.o: In function `ASStreamIterator':
/«PKGBUILDDIR»/build/gcc/../../src/astyle_main.cpp:95:(.text+0x2b9e):
relocation truncated to fit: R_390_GOT12 against symbol `vtable for
astyle::ASStreamIteratorstd::basic_istringstreamchar, std::char_traitschar,
std::allocatorchar  ' defined in
..data.rel.ro._ZTVN6astyle16ASStreamIteratorISt19basic_istringstreamIcSt11char_traitsIcESaIc[_ZTVN6astyle16ASStreamIteratorISt19basic_istringstreamIcSt11char_traitsIcESaIc]
section in obj/astyle_main_sj.o
obj/astyle_main_sj.o: In function
`astyle::ASStreamIteratorstd::basic_istringstreamchar,
std::char_traitschar, std::allocatorchar  ::~ASStreamIterator()':
/«PKGBUILDDIR»/build/gcc/../../src/astyle_main.cpp:111:(.text._ZN6astyle16ASStreamIteratorISt19basic_istringstreamIcSt11char_traitsIcESaIcEEED2Ev[_ZN6astyle16ASStreamIteratorISt19basic_istringstreamIcSt11char_traitsIcESaIcEEED5Ev]+0x18):
additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
make[2]: *** [libastylej.so] Error 1
make[2]: Leaving directory `/«PKGBUILDDIR»/build/gcc'
dh_auto_build: make -j1 -C build/gcc astyle shared java returned exit code 2




Fix:
build/gcc/Makefile sets
CFLAGSs   = -DASTYLE_LIB -fpic $(CFLAGSr)
CFLAGSsd  = -DASTYLE_LIB -fpic $(CFLAGSd)
CFLAGSa   = -DASTYLE_LIB $(CFLAGSr)
CFLAGSad  = -DASTYLE_LIB $(CFLAGSd)
CFLAGSsj  = -DASTYLE_JNI -fpic $(CFLAGSr) $(JAVAINCS)
CFLAGSsjd = -DASTYLE_JNI -fpic $(CFLAGSd) $(JAVAINCS)

which should be -fPIC to build safely on more architectures

I'll do another 0-delay NMU to fix this.



-- System Information:
Debian Release: wheezy/sid
  APT prefers saucy-updates
  APT policy: (500, 'saucy-updates'), (500, 'saucy-security'), (500, 'saucy'), 
(100, 'saucy-backports')
Architecture: i386 (i686)

Kernel: Linux 3.11.0-18-generic (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


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

Bug#742418: NMU for astyle FTBFS on s390x

[Scott Howard]

tags 742418 patch pending
thanks

Hello all,

See NMU at:
http://anonscm.debian.org/gitweb/?p=collab-maint/astyle.git;a=commitdiff;h=40043eca6053949a6bfbfb98eb5fecb18988edef

has been uploaded to DELAYED/0.

Let me know if you need anything else.
~Scott

Bug#735847: closed by Scott Howard show...@debian.org (Bug#735847: fixed in freeimage 3.15.4-3)

[Scott Howard]

On Mon, Jan 20, 2014 at 7:26 PM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
 great, using system tiff is the best fix, thanks for going the extra mile!
 skimage now works again.

great to hear - thanks for helping!


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

Bug#735847: freeimage: builds wrong tiff, broken 32 bit

[Scott Howard]

Thanks for the report,

Checking over the package, I don't think it's a problem of not
updating the patch. The previous version of the package and patches
didn't touch anything related to TIFF and used freeimage's included
libtiff. The current version also doesn't touches anything involving
libtiff (or the internal libtiff) since freeimage requires private
headers and interfaces. At this point, it looks like bug is the
upstream bug you found. If their patch fixes this, it can be uploaded.

Before uploading that patch and closing this bug, I'd like to look at
long is 32 bit on 32 bit arches. it needs to be int64_t or long long.
This occurs several times in the file. LibTIFF4/tiffconf.h is
generated at build time, so it should be OK on all archs. In the
source package, there is LibTIFF4/tiffconf.h.in which is the template
for tiffconf.h after it is configured. Is this not the case? That
would be a different bug if so.

Cheers,
Scott


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

Bug#735847: freeimage: builds wrong tiff, broken 32 bit

[Scott Howard]

On Sun, Jan 19, 2014 at 8:18 PM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
 I disagree, all three issues found do seem like independent issues with
 little relation (on amd64 at least).

Ok, so there are three bugs:

1)
 the exif tag truncation is very unlikely cause the complete data
 structure corruption.

Ah, Sources/LibTIFF4 instead of LibTIFF on the lines that updated the
sources. Thanks for finding that (gensrclist.sh, genfipsrclist.sh)

2) [patch is available]
 tag truncation

3)
 The wrong type sizes can not be related because I tested that and it
 only affects 32 bit (which I was not using for debugging).

On bug #3, it looks like Source/LibTIFF/ is configured at build time,
but Source/LibTIFF4/ has already been configured and shipped by
upstream.

This is extra confusing, because upstream's tiffconf.h in SVN doesn't
match what they are distributing in their source tarballs:
http://freeimage.cvs.sourceforge.net/viewvc/freeimage/FreeImage/Source/LibTIFF4/tiffconf.h?view=markup
At no point in the history did tiffconf.h match what they are distributing.

Also, this has been reported before:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601762

And fixed with these two patches
http://anonscm.debian.org/gitweb/?p=collab-maint/freeimage.git;a=commitdiff;h=5657e6b0bbc7def9e5598e6872a91a202b7b4113
http://anonscm.debian.org/gitweb/?p=collab-maint/freeimage.git;a=commitdiff;h=cddd3e04b65efb1291ed6b28ac8310f33eec4466

namely
+/* Signed 64-bit type formatter */
+#define TIFF_INT64_FORMAT % PRId64
+
+/* Signed 64-bit type */
+#if SIZEOF_LONG == 8
+#define TIFF_INT64_T signed long
+#else
+#define TIFF_INT64_T signed long long
+#endif
+
+/* Unsigned 64-bit type formatter */
+#define TIFF_UINT64_FORMAT % PRIu64
+
+/* Unsigned 64-bit type */
+#if SIZEOF_LONG == 8
+#define TIFF_UINT64_T unsigned long
+#else
+#define TIFF_UINT64_T unsigned long long
+#endif

I'll go ahead and ask upstream if they could reconsider allowing their
packages to build using system libraries, these are all things best
handled by (and probably already solved by) libtiff maintainers.

Thanks again,
Scott


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

Bug#718272: [Pkg-bitcoin-devel] Bug#718272: Bitcoin still not ready for stable release in Debian

[Scott Howard]

On Sat, Dec 14, 2013 at 12:39 AM, Luke-Jr l...@dashjr.org wrote:
 I agree with Scott's assessment, although I would note that Debian *does* have
 a suite that addresses the needs of Bitcoin: stable-updates. Mandatory
 protocol rule changes would seem to fall within the broken by the flow of
 time category. Thoughts?

I think this is the way to go once bitcoin version 1.0 (or the
equivalent) is released. It requires users to enable the
stable-updates repository, but we can put a note in the description
with a hint to do that. It may be confusing for some users to get a
message (or see a post on a forum) that says, You MUST upgrade to
version 1.6! then wonder why Debian is distributing version 1.5, even
if it is a patched version 1.5.

Ideally, once it is stable enough for distribution, I'd like to see
someone from upstream (Matt Corallo?) take control of the
bitcoind/bitcoin-qt packages. DDs on the packaging team can sponsor
uploads and make sure things are done in a policy compliant way.


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

Bug#718272: Bitcoin still not ready for stable release in Debian

[Scott Howard]

Below is my opinion, and is open for debate:

Although there are mechanisms for supporting security updates in
stable debian releases, and luke-jr's work of porting fixes is great
and exactly what is needed, updates to network protocols would not
classify as a security update and would only be available via
backports.d.o.

Mandatory network updates from upstream don't have a propagation
system through stable Debian releases, therefore it should not be in a
stable release.

Ubuntu has just removed the bitcoin package in favor of the upstream
official PPA. This package, as it is an unstable-only package, has a
similar function as a PPA at this point. Users can apt-pin to it and
stay up-to-date via regular updates.

As bitcoin evolves, and network protocols becomes standardized, we can
revisit whether this would be viable for stable release.


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

Bug#718272: [Pkg-bitcoin-devel] Bug#718272: backport branches are available

[Scott Howard]

On Wed, Sep 4, 2013 at 11:59 AM, Luke-Jr l...@dashjr.org wrote:
 This isn't correct. We do support backported/stable versions in a separate git
 repository:
 https://gitorious.org/bitcoin/bitcoind-stable/

 Debian is welcome to choose a branch and I will do what I can to ensure it
 receives long-term support. I would recommend using the latest release
 (currently 0.8.4) if possible.

Thanks - I haven't seen that documented anywhere and wasn't aware of
it. That's a great service to provide.

How are those updated? It appears whenever there is a current-version
micro-release, those commits are backported to the stable branches.
Are only security and network related commits backported?
Is there a stable micro-release when those are backported, or is this
something that is more of a rolling stable branch.


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

Bug#718454: thansk for arduino-mk NMU

[Scott Howard]

Thanks for the NMU, I just got around to seeing it.

Upstream was in the middle of a transition between lead developers and
there has been significant changes to the code base. I'm going to
upload a new version that will include some of your changes.

Some, however, have been dropped (e.g., line_count.patch) since
upstream now uses a different implementation entirely.

Thanks again
~Scott


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

Bug#718272: upstream does not support stable releases (block migration to testing)

[Scott Howard]

Source: bitcoin
Severity: serious

The bitcoin network requires on strict adherence to consensus between nodes.
Small changes to underlying libraries, even justified security changes,
threaten to break consensus and could possible cause accidental forks.

For example, it is possible for bug fix in libleveldb to cause a fork in the
network if existing nodes expect buggy behaviour.

Therefore, bitcoin upstream developers have strongly encouraged downstream
packagers to use the exact version of libleveldb included with their source
code.  However, upstream does not backport or support previously released
versions of bitcoind/bitcoin-qt.

For example: if we release Debian Jessie with version 0.8 of bitcoin, and a
security bug is found in that version and fixed upstream, the fix may be based
on top of version 0.10 and unable to be ported to 0.8. Upstream will, in that
case, release version 0.10 and not backport the fix to 0.8. This is especially
tricky now that Debian is using the bitcoin packaged version of leveldb.

Because of the sensitivity of this situation (lots of money can be lost), I
believe we should block migration to testing until either upstream supports
stable releases or we have a volunteer that works closely enough with upstream
code (an upstream developer) that is will to backport security and network-
related fixes.


There has been some work on multibit and electrum packages in Debian, these may
be better choices for wallets. If we keep bitcoin in unstable, we'll be able to
update as needed and users will understand that these packages are not stable
and will need to be updated often.



-- System Information:
Debian Release: wheezy/sid
  APT prefers raring-updates
  APT policy: (500, 'raring-updates'), (500, 'raring-security'), (500, 
'raring-proposed'), (500, 'raring'), (100, 'raring-backports')
Architecture: i386 (i686)

Kernel: Linux 3.8.0-27-generic (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


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

Bug#707736: qtiplot no longer can edit columns with ne libmuparser

[Scott Howard]

severity 707736 serious
tags 707736 help
thanks

This is important enough to prevent migrating to testing. I'm really
busy with grants for a few weeks, so if anyone wants to look at it I'd
appreciate it.


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

Bug#708584: versioning system/package name allows for binary incompatible libraries

[Scott Howard]

On Mon, May 27, 2013 at 1:35 AM, Anton Gladky gl...@debian.org wrote:
 Hi Scott,

 I have uploaded the 3.7.0-5 version into DELAYED/5 queue. Feel free
 to cancel/reschedule or just let me know, if you find some issues in
 this version.

 Best regards,

 Anton

Looks good, I've been traveling so I couldn't look too closely at it -
but that looks like a good solution.
Don't worry about binNMUing qtiplot. There is another bug I'm working
on there, the pending upload of qtiplot will build against the new
alglib library.
Thanks again.
~Scott


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

Bug#708584: versioning system/package name allows for binary incompatible libraries

[Scott Howard]

On Fri, May 17, 2013 at 1:47 AM, Anton Gladky gladky.an...@gmail.com wrote:
 Hi,

 I have done this upload, sorry if I broke something or offended somebody.

I'm the one that should apologize, I saw that you did contact me on
April 26, but I failed to respond.


 Ok, if you want, I will create libalglib3.7.0. But I do not know, whether it
 is necessary for
 the package, having just qtiplot in build-rdeps and with popcon 33. But you
 are the
 main maintainer, you should decide.

qtiplot's popcon is 1091, libalglib-2.6.0 popcon was several hundred,
libalglib3's popcon is 33.
In the past we had a problem where people did uploads to alglib that
broke alglib because they don't follow reasonable versioning. In fact,
alglib used to have a blurb on their website about how they don't
believe in build systems and everyone should hardcode their code into
projects.


 Why, actually, the version 2.6.0 has  been uploaded into Debian on 06 Mar
 2011,
 if it was half a year obsolete and unsupported by upstream? The version
 3.3.0 was
 already available [1].

the only depending package in Debian required version 2.6.0, newer
versions broke that package, so we kept it until someone needed a
newer version (which is now, apparently).

 Does another package need it?


 Yes, not (yet) uploaded into Debian.

this is a good reason to work it out.



 2) Why did a team upload switch from autotools to cmake?


 3-versions are completely different from 2-vesions. It was rewritten from
 scratch.
 And yes, personal preferences. Why did you ask about that after uploading
 the
 package?

Personal preference is ok, it is just something you avoid doing on NMU
and team uploads without checking with the maintainers first (which
you tried to do, but I missed the email)
I'm OK with cmake, could we set the release ldflag instead of
version as to not set the SONAME? I know how to do this in autotools
but not with cmake. This would be similar to how libalglib-2.6.0 did
it.



 3) Why did 1 and 2 happen without consulting with the current uploaders of
 alglib or the depending package?

 That is not true and I am surprised, that you decided to discuss it here:
   1) I sent you and your co-maintainer an email with patches on alglib on
 April 26th.
   2) May 5th the package has been uploaded into experimental.
   3) May 15th, the package has been uploaded into unstable.

 The first communication with you was on May 16th.

 So I think, the second part of the bug is not RC.
 Again, sorry, if I broke something. I will try to be careful next time and
 ready for co-maintaining.

Yes, I'm sorry I missed your email on the 26th. If I didn't turn you
off already, you're more than welcome to become an uploader/maintainer
of this package.

I appreciate your work, sorry about the miscommunication.

Regarding the RC part - we should consider how to future proof the
versioning. I prefer the release flag for alglib since they don't
use sane versioning [1]. We could set the SONAME to 3.7.0, like you
suggested, as well. In my opinion both are acceptable. If you'd like
to add yourself as an uploader and can choose which way you prefer.

[1] http://www.sourceware.org/autobook/autobook/autobook_91.html

Regards,
Scott


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

Bug#708584: versioning system/package name allows for binary incompatible libraries

[Scott Howard]

Package: alglib
Version: 3.7.0-1~exp1
Severity: serious

the version of alglib is 3.7.0. Debian now is assigning a SONAME version of 3.
This is incorrect as it implies all 3.x.x libraries are binary compatible,
which they are not. Upstream changelog explicitly states that not binary 3.7.0
and 3.6.0 are not binary compatible, for example.

When assigning a SONAME version that differs from upstream, use the debian
word in the SONAME. For example, 3debian0 would be an appropriate SONAME, but
you would have to keep track of backwards incompatible changes to symbols and
bump the next version when it comes out (e.g. 3debian1). If you don't do this,
you risk making libraries that are incompatible with other distributions and
upstream. That's why the old build system used the -release @VERSION@ flag
instead of -version, so ensure that the soname remained blank. You can assign
a SONAME to the library, but please append debianX or keep the old system so
we can follow policy 8.2 The run-time shared library must be placed in a
package whose name changes whenever the SONAME of the shared library changes.
I preferred the old system since I didn't like assigning a SONAME that upstream
was not using.

Other issues, not directly related to this bug, but somewhat at an RC level so
we can take care of it before it migrates to testing:
1) Why was alglib bumped at all? Does another package need it? Why was the new
version uploaded, breaking the only depending package in Debian without first
checking with that package?
2) Why did a team upload switch from autotools to cmake?
3) Why did 1 and 2 happen without consulting with the current uploaders of
alglib or the depending package?



-- System Information:
Debian Release: wheezy/sid
  APT prefers raring-updates
  APT policy: (500, 'raring-updates'), (500, 'raring-security'), (500, 
'raring-proposed'), (500, 'raring'), (100, 'raring-backports')
Architecture: i386 (i686)

Kernel: Linux 3.8.0-20-generic (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


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

Bug#708240: qtiplot FTBFS with new minizip.c

[Scott Howard]

The minizip.c that ships with the new version of zlib has changed
significantly and is no longer compatible with what qtiplot uses.

We can now just use minizip.c that comes with qtiplot

(todo: include the license in debian/copyright, drop the build
dependency on zlib, fix get-orig-source rule to not exclude it in the
future, drop part of patch that looks for minizip in working
directory)


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

Bug#672524: bitcoin: FTBFS[any-i386]: testsuite errors

[Scott Howard]

Somehow the path is getting botched in kfreebsd-i386:

On amd64 [1] (and similarly on all other architectures except *i386) we pass
-DTEST_DATA_DIR=/build/buildd-bitcoin_0.8.1-2-amd64-bLPEbz/bitcoin-0.8.1/src/test/data
and the debug output says
Trying to open 
/build/buildd-bitcoin_0.8.1-2-amd64-bLPEbz/bitcoin-0.8.1/src/test/data/base58_encode_decode.json

but on kfreebsd-i386 [2]  and i386 buildds we pass
-DTEST_DATA_DIR=/build/buildd-bitcoin_0.8.1-2-kfreebsd-i386-B2WCjD/bitcoin-0.8.1/src/test/data
and the debug output says
Trying to open 
/build/buildd-bitcoin_0.8.1-2-kfreebsd-1-B2WCjD/bitcoin-0.8.1/src/test/data/base58_encode_decode.json

i386 somehow got changed into a 1, and this seems to happen on
kfreebsd-i386 and i386 buildds.

anyone know why the buildds seem to change the i386 string to 1?

[1]https://buildd.debian.org/status/fetch.php?pkg=bitcoinarch=amd64ver=0.8.1-2stamp=1366775051
[2]https://buildd.debian.org/status/fetch.php?pkg=bitcoinarch=amd64ver=0.8.1-2stamp=1366775051


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

Bug#704719: FTBFS on visp

[Scott Howard]

This post can help:
http://www.eyrie.org/~eagle/journal/2012-01/008.html


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

Bug#703213: Manditory upgrade of bitcoin versions = 0.7.2

[Scott Howard]

Source: bitcoin
Version: 0.7.2-1
Severity: serious

From upstream:
http://bitcoin.org/may15.html

The most recent accidental fork is forcing an upgrade. We either
should get bitcoin 0.8.1 in to unstable or add some wrapper to
bitcoind and bitocin-qt to create a DB_CONFIG file.
Summary below:

15 May 2013 Upgrade Deadline
What is happening

If you are using Bitcoin-Qt/bitcoind version 0.7.2 or earlier, you
must take action before 15 May, 2013. If you do nothing, you are
likely to be left behind and will be out of sync with the rest of the
Bitcoin network.

We recommend that you upgrade to version 0.8.1 before the 15th of May
to avoid any issues. If you are a solo miner or mining pool operator,
please see the the notes at the end of this page for how to upgrade
safely.
If you cannot upgrade to version 0.8.1

If you cannot upgrade to the latest version, you can still avoid the
problem. Create a file called DB_CONFIG in the bitcoin data directory,
containing these two lines:

set_lg_dir database
set_lk_max_locks 5


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

Bug#672524: [Pkg-bitcoin-devel] Bug#672524: upload of bitcoin package

[Scott Howard]

Uploaded, thanks so much for your help!

Here is the results from the buildlog.



Debug output for #672524
pwd
/build/buildd-bitcoin_0.7.2-3-kfreebsd-i386-Os85sN/bitcoin-0.7.2
ls -Rl .
{SNIP}
./src/test/data:
total 96
-rw-r--r-- 1 buildd sbuild   438 Dec 10 14:47 base58_encode_decode.json
-rw-r--r-- 1 buildd sbuild  4195 Dec 10 14:47 base58_keys_invalid.json
-rw-r--r-- 1 buildd sbuild 12618 Dec 10 14:47 base58_keys_valid.json
-rw-r--r-- 1 buildd sbuild 20645 Dec 10 14:47 script_invalid.json
-rw-r--r-- 1 buildd sbuild 33360 Dec 10 14:47 script_valid.json
-rw-r--r-- 1 buildd sbuild  7507 Dec 10 14:47 tx_invalid.json
-rw-r--r-- 1 buildd sbuild  9525 Dec 10 14:47 tx_valid.json

ok so it is there. Later on:

HOME=/build/buildd-bitcoin_0.7.2-3-kfreebsd-i386-Os85sN/bitcoin-0.7.2/debian/home
src/test_bitcoin
Running 70 test cases...
Trying to open 
/build/buildd-bitcoin_0.7.2-3-kfreebsd-1-Os85sN/bitcoin-0.7.2/src/test/data/base58_encode_decode.json
test/script_tests.cpp(109): error in base58_EncodeBase58: Cound not
find/open base58_encode_decode.json
Trying to open 
/build/buildd-bitcoin_0.7.2-3-kfreebsd-1-Os85sN/bitcoin-0.7.2/src/test/data/base58_encode_decode.json
test/script_tests.cpp(109): error in base58_DecodeBase58: Cound not
find/open base58_encode_decode.json
Trying to open 
/build/buildd-bitcoin_0.7.2-3-kfreebsd-1-Os85sN/bitcoin-0.7.2/src/test/data/base58_keys_valid.json
test/script_tests.cpp(109): error in base58_keys_valid_parse: Cound
not find/open base58_keys_valid.json
Trying to open 
/build/buildd-bitcoin_0.7.2-3-kfreebsd-1-Os85sN/bitcoin-0.7.2/src/test/data/base58_keys_valid.json
test/script_tests.cpp(109): error in base58_keys_valid_gen: Cound
not find/open base58_keys_valid.json
Trying to open 
/build/buildd-bitcoin_0.7.2-3-kfreebsd-1-Os85sN/bitcoin-0.7.2/src/test/data/base58_keys_invalid.json
test/script_tests.cpp(109): error in base58_keys_invalid: Cound not
find/open base58_keys_invalid.json
Trying to open 
/build/buildd-bitcoin_0.7.2-3-kfreebsd-1-Os85sN/bitcoin-0.7.2/src/test/data/script_valid.json
test/script_tests.cpp(109): error in script_valid: Cound not
find/open script_valid.json
Trying to open 
/build/buildd-bitcoin_0.7.2-3-kfreebsd-1-Os85sN/bitcoin-0.7.2/src/test/data/script_invalid.json
test/script_tests.cpp(109): error in script_invalid: Cound not
find/open script_invalid.json
Trying to open 
/build/buildd-bitcoin_0.7.2-3-kfreebsd-1-Os85sN/bitcoin-0.7.2/src/test/data/tx_valid.json
test/script_tests.cpp(109): error in tx_valid: Cound not find/open
tx_valid.json
Trying to open 
/build/buildd-bitcoin_0.7.2-3-kfreebsd-1-Os85sN/bitcoin-0.7.2/src/test/data/tx_invalid.json
test/script_tests.cpp(109): error in tx_invalid: Cound not find/open
tx_invalid.json
*** 9 failures detected in test suite Bitcoin Test Suite
make: *** [debian/stamps-perpkg-build/bitcoind] Error 201

In summary: i386 and kfreebsd-i386 builds fail on buildd machines.
They don't fail on other machines, pbuilder chroots, or Ubuntu
builders. The failure comes from he test suite not being able to find
a file, but our debugging shows that the file exists and that it is
attempting to open the correct file.


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

Bug#672524: upload of bitcoin package

[Scott Howard]

Hey Petter,
Are you still looking for an uploader? There's a typo in debian/rules,
btw - the quotes need to be closed on the line:

@echo Debug output for #672524

Cheers,
Scott


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

Bug#699351: linux-gd obsolete and lubupnp4

[Scott Howard]

retitle 699351 linux-igd follows old UPnP IGD V1 spec
thanks


On Thu, Jan 31, 2013 at 3:32 AM, VALETTE Eric OLNC/OLPS
eric2.vale...@orange.com wrote:
 Look at the CVE that have been filled regarding libupnp6 and the associated
 bugs.

Thanks - they have been fixed in libupnp4 [1]. I've renamed the bug
appropriately. I do not know enough about UPnP IGD V1 versus V2 [2] to
have an opinion about whether this is an RC bug or not, so I'll leave
that for the security team or someone more qualified.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699459
[2] http://upnp.org/sdcps-and-certification/standards/sdcps/


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

Bug#699316: libupnp4: Multiple stack buffer overflow vulnerabilities

[Scott Howard]

clone 699316 -1
reassign -1 libupnp4
retitle -1 libupnp4: Multiple stack buffer overflow vulnerabilities
thanks

From [1], libupnp4 has the same vulnerabilities as described in Bug
#688316. Cloning so it's on someone's radar.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699351


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

Bug#699459: libupnp4: Multiple stack buffer overflow vulnerabilities

[Scott Howard]

Package: libupnp4
Severity: grave
Tags: security


More information is available at bug #699316 (including a patch).
According to bug #699351, these security problems are also found in
libupnp4.

Here's the original posting by Salvatore Bonaccorso car...@debian.org


Hi,

the following vulnerabilities were published for libupnp.

CVE-2012-5958[0]: Stack buffer overflow of Tempbuf
CVE-2012-5959[1]: Stack buffer overflow of Event-UDN
CVE-2012-5960[2]: Stack buffer overflow of Event-UDN
CVE-2012-5961[3]: Stack buffer overflow of Evt-UDN
CVE-2012-5962[4]: Stack buffer overflow of Evt-DeviceType
CVE-2012-5963[5]: Stack buffer overflow of Event-UDN
CVE-2012-5964[6]: Stack buffer overflow of Event-DeviceType
CVE-2012-5965[7]: Stack buffer overflow of Event-DeviceType

Upstream changelog for 1.6.18 states:

***
Version 1.6.18
***

2012-12-06 Marcelo Roberto Jimenez mroberto(at)users.sourceforge.net

Security fix for CERT issue VU#922681

This patch addresses three possible buffer overflows in function
unique_service_name(). The three issues have the folowing CVE numbers:

CVE-2012-5958 Issue #2: Stack buffer overflow of Tempbuf
CVE-2012-5959 Issue #4: Stack buffer overflow of Event-UDN
CVE-2012-5960 Issue #8: Stack buffer overflow of Event-UDN

Notice that the following issues have already been dealt by previous
work:

CVE-2012-5961 Issue #1: Stack buffer overflow of Evt-UDN
CVE-2012-5962 Issue #3: Stack buffer overflow of Evt-DeviceType
CVE-2012-5963 Issue #5: Stack buffer overflow of Event-UDN
CVE-2012-5964 Issue #6: Stack buffer overflow of Event-DeviceType
CVE-2012-5965 Issue #7: Stack buffer overflow of Event-DeviceType

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities  Exposures) ids in your changelog entry.

For further information see:

[0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5958
http://security-tracker.debian.org/tracker/CVE-2012-5958
[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5959
http://security-tracker.debian.org/tracker/CVE-2012-5959
[2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5960
http://security-tracker.debian.org/tracker/CVE-2012-5960
[3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5961
http://security-tracker.debian.org/tracker/CVE-2012-5961
[4] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5962
http://security-tracker.debian.org/tracker/CVE-2012-5962
[5] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5963
http://security-tracker.debian.org/tracker/CVE-2012-5963
[6] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5964
http://security-tracker.debian.org/tracker/CVE-2012-5964
[7] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5965
http://security-tracker.debian.org/tracker/CVE-2012-5965

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore


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

Bug#699351: linux-gd obsolete and lubupnp4

[Scott Howard]

On Thu, Jan 31, 2013 at 3:32 AM, VALETTE Eric OLNC/OLPS
eric2.vale...@orange.com wrote:
 Look at the CVE that have been filled regarding libupnp6 and the associated
 bugs.

Thanks, I'll put something on libupnp4's debian BTS so it's on their radar.


 Are there security problems with linux-igd independent of libupnp4?

 Yes fixed in UPnP IGD V2because the specification themszelves addressed the
 security concerns.


~Scott


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

Bug#699351: linux-gd obsolete and lubupnp4

[Scott Howard]

Hello Eric,

You wrote:
Linux-igd is dead code, use very old libpunp version that contains
numerous security holes. Besides this version is not compatible with
IPV6 as required by UPnP IGD V2 specification.

I believe you mean libupnp4 contains numerous security holes - have
they been reported in Debian? That could be serious with implications
beyond linux-gd and needs to be addressed immediately. I don't see any
reported [1].

Are there security problems with linux-igd independent of libupnp4?

It seems that the main bug is the linux-igd is not compatible with
UPnP IGD V2. If that is the case, I don't think this is an RC bug
(severity Grave). A normal severity seems more appropriate to me.

Regards,
Scott

[1] 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?ordering=normal;archive=0;src=libupnp4;dist=unstable;repeatmerged=0


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

Bug#672524: [Pkg-bitcoin-devel] Bug#672524: Bug#672524: bitcoin: FTBFS[any-i386]: testsuite errors

[Scott Howard]

On Mon, Jan 21, 2013 at 10:17 PM, Scott Howard showard...@gmail.com wrote:
 On Sat, Jan 19, 2013 at 3:52 PM, Petter Reinholdtsen p...@hungry.com wrote:
 [Christoph Egger]
   We'll see as soon as it builds on the buildds I'd say.

 Still fail.  I am unable to understand why:

 I have a wild guess, but would appreciate feedback. script_tests.cpp
 calls boost:filesystem:current_path(), which essentially reads in $PWD
 from the environment. Is it possible that the i386 buildds cleared the
 PWD variable prior to build? If so, we can append PWD=$(CURDIR) before
 invoking the test_script command. [1,2] Or better yet, compile while
 defining TEST_DATA_DIR (see [3]) so it doesn't depend on
 current_path() at all.

Sorry, it looks like TEST_DATA_DIR is already defined properly. From
the build log:

g++ -c 
-DTEST_DATA_DIR=/build/buildd-bitcoin_0.7.2-2-i386-2MCUBL/bitcoin-0.7.2/src/test/data
-DBOOST_TEST_DYN_LINK -O2 -pthread -Wall -Wextra -Wformat
-Wformat-security -Wno-unused-parameter -g -DBOOST_SPIRIT_THREADSAFE
-I/build/buildd-bitcoin_0.7.2-2-i386-2MCUBL/bitcoin-0.7.2/src
-I/build/buildd-bitcoin_0.7.2-2-i386-2MCUBL/bitcoin-0.7.2/src/obj
-DUSE_UPNP=0 -DUSE_IPV6=1 -DHAVE_BUILD_INFO -fno-stack-protector
-fstack-protector-all -Wstack-protector -D_FORTIFY_SOURCE=2  -MMD -MF
obj-test/script_tests.d -o obj-test/script_tests.o
test/script_tests.cpp

And it is properly set in the makefile.unix:
TESTDEFS = -DTEST_DATA_DIR=$(abspath test/data)

So I'm back to being stumped, the files it can't find are the location
that is being passed. The location is correct. It can be built in
pbuilder but failing on the buildds.

~Scott


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

Bug#672524: [Pkg-bitcoin-devel] Bug#672524: bitcoin: FTBFS[any-i386]: testsuite errors

[Scott Howard]

On Sat, Jan 19, 2013 at 3:52 PM, Petter Reinholdtsen p...@hungry.com wrote:
 [Christoph Egger]
   We'll see as soon as it builds on the buildds I'd say.

 Still fail.  I am unable to understand why:

I can't reproduce this either in pbuilder, i386 sid. I'm forwarding
this to the pkg-bitcoin ML to see if anyone there has any ideas.

The test suites are failing to find *.json files on i386 and
kfreebsd-i386 builds only.
https://buildd.debian.org/status/package.php?p=bitcoin

I can't debug it since I can't reproduce it.

The error is:
HOME=/build/buildd-bitcoin_0.7.2-2-i386-2MCUBL/bitcoin-0.7.2/debian/home
src/test_bitcoin
Running 70 test cases...
test/script_tests.cpp(106): error in base58_EncodeBase58: Cound not
find/open base58_encode_decode.json
and a bunch more failures

I have a wild guess, but would appreciate feedback. script_tests.cpp
calls boost:filesystem:current_path(), which essentially reads in $PWD
from the environment. Is it possible that the i386 buildds cleared the
PWD variable prior to build? If so, we can append PWD=$(CURDIR) before
invoking the test_script command. [1,2] Or better yet, compile while
defining TEST_DATA_DIR (see [3]) so it doesn't depend on
current_path() at all.

I'm shooting in dark, but maybe we can get lucky.
~Scott

[1] http://lintian.debian.org/tags/debian-rules-uses-pwd.html
[2] 
http://www.boost.org/doc/libs/1_52_0/libs/filesystem/doc/reference.html#current_path
[3] 
http://anonscm.debian.org/gitweb/?p=collab-maint/bitcoin.git;a=blob;f=src/test/script_tests.cpp;h=61d9a64eebb2dc3158386402250072ed0182cbe5;hb=HEAD#l94


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

Bug#696262: bitcoin FTBFS: tests fail assuming a RW $HOME

[Scott Howard]

Package: src:bitcoin
Version: 0.7.2-1
Severity: serious
Tags: sid
Justification: fails to build from source (but built successfully in the past)


Several build failures on multiple archs because buildd machines don't
have writable /home/buildd.

This affects test suites.

Exact failure:
Test setup error: std::runtime_error:
boost::filesystem::create_directory: No such file or directory:
/home/buildd/.bitcoin


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

Bug#695928: [eagle] unable to run: error loading libssl.so.0.9.8

[Scott Howard]

On Fri, Dec 14, 2012 at 8:31 AM, Arthur Magill arthur.mag...@epfl.ch wrote:
 Package: eagle
 Version: 5.10.0-2
 Severity: grave

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

 Until this week, I have been happily running Eagle. Clearly something
 changed with a recent upgrade. When I try to start Eagle, I see the
 following:

 $ eagle
 /home/magill/.eagle/bin/eagle: error while loading shared libraries:
 libssl.so.0.9.8: wrong ELF class: ELFCLASS64

It seems that the problem came about because your system is using
Wheezy multiarched ia32-libs but Squeeze non-multiarched eagle.

Eagle is a 32 bit binary, and should only be using the 32 bit
libraries (even on amd64 systems).

The squeeze version of Eagle is looking for the 32 bit libssl:
/usr/lib32/i486/libssl.so.0.9.8
and is included in package ia32-libs in squeeze. However, you have a
version of ia32-libs installed from Wheezy. Wheezy introduced
multiarch, which allowed 32 and 64 bit libraries to be co-installed.
Eagle, a 32 bit binary, depends on 32 bit libraries.


Since you've already upgraded to ia32-libs from Wheezy, you either
have to downgrade it to the squeeze version to get the library back or
install a multiarched version of eagle:

$ dpkg --add-architecture i386
$ apt-get update
$ apt-get install eagle:i386 -t unstable


More information is here:
http://wiki.debian.org/Multiarch

fixing this is going to come down to getting the right versions of
different packages working together (either all from squeeze or all
from wheezy, mixing won't work).

Cheers,
Scott


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

Bug#688813: bitcoind: CVE-2012-4683 and CVE-2012-4682, fixed in 0.7r1

[Scott Howard]

Fixed in version 0.7r1
https://bitcointalk.org/index.php?topic=104173.70;wap2


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

Bug#683021: fparser removed from archive

[Scott Howard]

fparser removed from archive
See:
http://packages.qa.debian.org/f/fparser/news/20120904T152959Z.html


We believe that the bug you reported is now fixed; the following
package(s) have been removed from unstable:

   fparser |  4.3-4 | source
   fparser |4.5-0.1 | source
libfparser-4.3 |  4.3-4 | armel, armhf
libfparser-4.3 |4.5-0.1 | amd64, hurd-i386, i386, ia64,
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x,
sparc
libfparser-4.3-dbg |  4.3-4 | armel, armhf
libfparser-4.3-dbg |4.5-0.1 | amd64, hurd-i386, i386, ia64,
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x,
sparc
libfparser-dev |  4.3-4 | armel, armhf
libfparser-dev |4.5-0.1 | amd64, hurd-i386, i386, ia64,
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x,
sparc

--- Reason ---
ROM; RC buggy, no more rdepends
--

Note that the package(s) have simply been removed from the tag
database and may (or may not) still be in the pool; this is not a bug.
The package(s) will be physically removed automatically when no suite
references them (and in the case of source, when no binary references
it).  Please also remember that the changes have been done on the
master archive and will not propagate to any mirrors (ftp.debian.org
included) until the next dinstall run at the earliest.

Packages are usually not removed from testing by hand. Testing tracks
unstable and will automatically remove packages which were removed
from unstable when removing them from testing causes no dependency
problems. The release team can force a removal from testing if it is
really needed, please contact them if this should be the case.

We try to close bugs which have been reported against this package
automatically. But please check all old bugs, if they were closed
correctly or should have been re-assigned to another package.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 686...@bugs.debian.org.

The full log for this bug can be viewed at http://bugs.debian.org/686577

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmas...@debian.org.

Debian distribution maintenance software
pp.
Alexander Reichle-Schmehl (the ftpmaster behind the curtain)


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

Bug#686173: ld segfaults when linking uncomforming ELF

[Scott Howard]

On Thu, Aug 30, 2012 at 7:03 AM, Hakan Ardo ha...@debian.org wrote:
 Thanx!
 I'm uploading a new version binutils-avr with this patch. Please
 verify that it solves the problem.

Verified on a wheezy machine, thanks Hakan.


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

Bug#683021: Help with bug 683021

[Scott Howard]

tags 683021 help
thanks

I've been playing with the code, trying to massage it to compile on
arm* with no luck. If anyone else can help, I'd appreciate it.


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

Bug#684748: Arduino Ethernet library fix, needs testing

[Scott Howard]

On Thu, Aug 23, 2012 at 11:18 AM, Marco Righi marco.ri...@gmail.com wrote:
 Hi Scott,
 I have installed the last version of Debian ISO in a Virtual box and the
 Arduino environment (after your .a8 patch) compiles with success the
 Ethernet code!

Great - was that the 32 bit or 64 bit virtual box?


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

Bug#684748: Arduino Ethernet library fix, needs testing

[Scott Howard]

On Wed, Aug 22, 2012 at 3:46 AM, Marco Righi marco.ri...@gmail.com wrote:
 Hi Scott,
 you are welcome. I use Debian 64 bit.

 Command 37 of 4 $avr-ld --version
 GNU ld (GNU Binutils) 2.20.1.20100303
 Copyright 2009 Free Software Foundation, Inc.
 This program is free software; you may redistribute it under the terms of
 the GNU General Public License version 3 or (at your option) a later
 version.
 This program has absolutely no warranty.

 Please contact me if you think I can help you. I am glad to help the
 Debian develop.

 Marco

Thanks - could you try compiling the ethernet code with the fixed
Ethernet.cpp file on a 32 bit machine (or virtual machine)? I have
it working on 32 bit machines here but don't have an AMD64 to test, so
if you can confirm that it compiles ok on 32 bit (like mine does) but
doesn't on 64 bit, then we know we fixed one bug and are now working
on a different one in avr-ld.

Cheers,
Scott


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

Bug#684748: Arduino Ethernet library fix, needs testing

[Scott Howard]

On Sat, Aug 18, 2012 at 7:29 AM, Scott Howard showard...@gmail.com wrote:
 On Sat, Aug 18, 2012 at 3:32 AM, Marco Righi marco.ri...@gmail.com wrote:
 do you ask about this?

 Command 36 of 1 $avr-gcc --verbose
 Using built-in specs.
 COLLECT_GCC=avr-gcc
 COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.7.0/lto-wrapper
 Target: avr
 Configured with: ../src/configure -v --enable-languages=c,c++
 --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man
 --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared
 --with-system-zlib --enable-long-long --enable-nls
 --without-included-gettext --disable-libssp --build=x86_64-linux-gnu
 --host=x86_64-linux-gnu --target=avr
 Thread model: single
 gcc version 4.7.0 (GCC)

 thanks, helps a lot (looks right...) - i'll keep looking at it

Sorry to bug you again, but could you try the Ethernet.cpp file you
sent me in a 32 bit VM (or machine if you have one)? I think it may be
a bug in the 64 bit ld.

Also, can you post the output of $ avr-ld --version ?

Cheers,
Scott


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

Bug#684748: Arduino Ethernet library fix, needs testing

[Scott Howard]

On Sat, Aug 18, 2012 at 3:32 AM, Marco Righi marco.ri...@gmail.com wrote:
 do you ask about this?

 Command 36 of 1 $avr-gcc --verbose
 Using built-in specs.
 COLLECT_GCC=avr-gcc
 COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.7.0/lto-wrapper
 Target: avr
 Configured with: ../src/configure -v --enable-languages=c,c++
 --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man
 --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared
 --with-system-zlib --enable-long-long --enable-nls
 --without-included-gettext --disable-libssp --build=x86_64-linux-gnu
 --host=x86_64-linux-gnu --target=avr
 Thread model: single
 gcc version 4.7.0 (GCC)

thanks, helps a lot (looks right...) - i'll keep looking at it


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

Bug#684748: Arduino Ethernet library fix, needs testing

[Scott Howard]

Hello,

I got the library to compile but don't have the hardware to test it.

Could you please edit the following file and let me know if it works?

/usr/share/arduino/libraries/Ethernet/Ethernet.cpp

Change:
W5100.setIPAddress(local_ip._address);
W5100.setGatewayIp(gateway._address);
W5100.setSubnetMask(subnet._address);



to be:
W5100.setIPAddress(local_ip._address.a8);
W5100.setGatewayIp(gateway._address.a8);
W5100.setSubnetMask(subnet._address.a8);


(that is, add a .a8 to the end of the _address)

Please try it out and report back here so I can spread the word.

Cheers,
Scott






The formal patch is:
Index: arduino/libraries/Ethernet/Ethernet.cpp
===
--- arduino.orig/libraries/Ethernet/Ethernet.cpp2012-03-11
19:09:34.421223498 -0400
+++ arduino/libraries/Ethernet/Ethernet.cpp 2012-08-17 12:14:09.845198234 
-0400
@@ -61,9 +61,9 @@
 {
   W5100.init();
   W5100.setMACAddress(mac);
-  W5100.setIPAddress(local_ip._address);
-  W5100.setGatewayIp(gateway._address);
-  W5100.setSubnetMask(subnet._address);
+  W5100.setIPAddress(local_ip._address.a8);
+  W5100.setGatewayIp(gateway._address.a8);
+  W5100.setSubnetMask(subnet._address.a8);
   _dnsServerAddress = dns_server;
 }


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

Bug#684748: Arduino Ethernet library fix, needs testing

[Scott Howard]

On Fri, Aug 17, 2012 at 1:08 PM, Marco Righi marco.ri...@gmail.com wrote:
 Hi,
 I am sorry but this change is not enougth.

 If I try to compile (I attach the modified file) I got a segmentation
 error or segmentation fault (the displayed error is [Errore di
 segmentazione]).

 collect2: error: ld terminated with signal 11 [Errore di segmentazione]

Thanks for testing. I am unable to compile with the current unstable
package on debian wheezy, but I copied your file you emailed and it
compiles without the segfault [1]. I compile both the code you posted
and the WebClient example without any errors.

I forwarded the patch upstream to the original author of the arduino
library port to gcc 4.7. I can't see which version of gcc-avr you are
using, but segfaults sometimes fall as a problem with ld. For now, I
guess we can just make sure we have an updated toolchain and see if it
was some configuration error.

[1]
{clean install of arduino}

showard@debian-testing:~$ arduino

{attempt to compile web client example}

/usr/share/arduino/libraries/Ethernet/Ethernet.cpp: In member function
‘void EthernetClass::begin(uint8_t*, IPAddress, IPAddress, IPAddress,
IPAddress)’:
/usr/share/arduino/libraries/Ethernet/Ethernet.cpp:64:39: error: no
matching function for call to
‘W5100Class::setIPAddress(IPAddress::anonymous union)’
/usr/share/arduino/libraries/Ethernet/Ethernet.cpp:64:39: note: candidate is:
In file included from /usr/share/arduino/libraries/Ethernet/Ethernet.cpp:1:0:
/usr/share/arduino/libraries/Ethernet/utility/w5100.h:392:6: note:
void W5100Class::setIPAddress(uint8_t*)
/usr/share/arduino/libraries/Ethernet/utility/w5100.h:392:6: note:
no known conversion for argument 1 from ‘IPAddress::anonymous union’
to ‘uint8_t* {aka unsigned char*}’
/usr/share/arduino/libraries/Ethernet/Ethernet.cpp:65:38: error: no
matching function for call to
‘W5100Class::setGatewayIp(IPAddress::anonymous union)’
/usr/share/arduino/libraries/Ethernet/Ethernet.cpp:65:38: note: candidate is:
In file included from /usr/share/arduino/libraries/Ethernet/Ethernet.cpp:1:0:
/usr/share/arduino/libraries/Ethernet/utility/w5100.h:368:6: note:
void W5100Class::setGatewayIp(uint8_t*)
/usr/share/arduino/libraries/Ethernet/utility/w5100.h:368:6: note:
no known conversion for argument 1 from ‘IPAddress::anonymous union’
to ‘uint8_t* {aka unsigned char*}’
/usr/share/arduino/libraries/Ethernet/Ethernet.cpp:66:38: error: no
matching function for call to
‘W5100Class::setSubnetMask(IPAddress::anonymous union)’
/usr/share/arduino/libraries/Ethernet/Ethernet.cpp:66:38: note: candidate is:
In file included from /usr/share/arduino/libraries/Ethernet/Ethernet.cpp:1:0:
/usr/share/arduino/libraries/Ethernet/utility/w5100.h:376:6: note:
void W5100Class::setSubnetMask(uint8_t*)
/usr/share/arduino/libraries/Ethernet/utility/w5100.h:376:6: note:
no known conversion for argument 1 from ‘IPAddress::anonymous union’
to ‘uint8_t* {aka unsigned char*}’

{copy the new Ethernet.cpp file}

showard@debian-testing:~$ sudo cp ~/Downloads/Ethernet.cpp
/usr/share/arduino/libraries/Ethernet/Ethernet.cpp

showard@debian-testing:~$ arduino

{attempt to compile web client example}

Binary sketch size: 12,004 bytes (of a 32,256 byte maximum)

{success}


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

Bug#684748: [arduino] unable to use ethernet library

[Scott Howard]

On Mon, Aug 13, 2012 at 10:40 AM, Marco Righi marco.ri...@gmail.com wrote:
 Package: arduino
 Version: 1:1.0.1+dfsg-4
 Severity: grave

 --- Please enter the report below this line. ---
 Hi,
 I try to compile the Arduino example

 #include Ethernet.h
 #include SPI.h

 // the media access control (ethernet hardware) address for the shield:
 byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
 //the IP address for the shield:
 byte ip[] = { 10, 0, 0, 177 };

 void setup()
 {
   Ethernet.begin(mac, ip);
 }

 void loop () {}

 that I copy from

 http://arduino.cc/en/Reference/EthernetBegin

 I patched it adding the line

 #include SPI.h

 Using the Arduino compiler under VirtualBOX I compile successfully the
 code meanwhile using the Debian package I got the followings errors:

It looks like a problem with gcc 4.7.0 that Debian recently switched
to [1, 2]. Debian Arduino is using the patches from here [3]. Hakan,
could you look at bugs.debian.org/684748 and see if anything simple
jumps out at you with this error? Source is here [4]. I'm travelling
and can't look too closely at it. Thank you!

Cheers,
Scott

[1] http://packages.qa.debian.org/g/gcc-avr.html
[2] http://arduino.cc/forum/index.php?topic=116542.0
[3] 
http://andybrown.me.uk/wk/2012/04/28/avr-gcc-4-7-0-and-avr-libc-1-8-0-compiled-for-windows/
[4] 
http://anonscm.debian.org/gitweb/?p=collab-maint/arduino.git;a=tree;f=libraries/Ethernet;h=e638934e692b79aaf75a49311684cc45593fb8e9;hb=HEAD


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

Bug#684748: [arduino] unable to use ethernet library

[Scott Howard]

On Mon, Aug 13, 2012 at 11:20 AM, Scott Howard showard...@gmail.com wrote:
 Using the Arduino compiler under VirtualBOX I compile successfully the
 code meanwhile using the Debian package I got the followings errors:

 It looks like a problem with gcc 4.7.0 that Debian recently switched
 to [1, 2]. Debian Arduino is using the patches from here [3]. Hakan,
 could you look at bugs.debian.org/684748 and see if anything simple
 jumps out at you with this error? Source is here [4]. I'm travelling
 and can't look too closely at it. Thank you!

 Cheers,
 Scott


it's related to the change to IPAddress.h, that was changed because of
gcc 4.7. We also will have to upate W5100*. i posted a comment at [1]
agreeing with a poster that has a similar problem.

It call comes down to the fact that IPAddress.h and .cpp:
Poor code quality here. The 4-octet class member is forcibly
type-punned to an incompatible type in several places. This hack
forces gcc to disable an entire class of optimisations. The new
compiler automatically enables strict-aliasing when size optimisations
are selected so we get told about this. The fix is to declare the
4-octet member as a union so it can be used in a type-safe manner.

[1] 
http://andybrown.me.uk/wk/2012/04/28/avr-gcc-4-7-0-and-avr-libc-1-8-0-compiled-for-windows/


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

Bug#679182: logkeys: FTBFS on mips*: braces around scalar initializer for type 'unsigned int'

[Scott Howard]

On Mon, Aug 6, 2012 at 7:56 PM, Vedran Furač vedran.fu...@gmail.com wrote:
 On 07/27/2012 10:33 PM, Scott Howard wrote:

 It still FTBFS with the new package from mentors/svn:

 upload.cc:87:30: error: braces around scalar initializer for type ‘unsigned 
 int’
 logkeys.cc:154:30: error: braces around scalar initializer for type
 ‘unsigned int’

 I've applied a patch that might have fixed this, could you test version
 0.1.1a+svn20120529-2 from mentors?

Looks good! Do you need a sponsor or should your normal sponsor do this?

It could be good for you to get access to a porterbox machine [1] or
set up a mips qemu emulated system [2] to test future problems.


[1] http://dsa.debian.org/doc/guest-account/
[2] http://www.aurel32.net/info/debian_mips_qemu.php


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

Bug#679182: logkeys: FTBFS on mips*: braces around scalar initializer for type 'unsigned int'

[Scott Howard]

It still FTBFS with the new package from mentors/svn:

/usr/bin/make  all-recursive
make[2]: Entering directory `/home/showard/logkeys-0.1.1a+svn20120529'
Making all in src
make[3]: Entering directory `/home/showard/logkeys-0.1.1a+svn20120529/src'
g++ -DHAVE_CONFIG_H -I. -I..   -D_FORTIFY_SOURCE=2  -Wall -O3
-DSYS_CONF_DIR=\/etc\ -c -o logkeys.o logkeys.cc
In file included from logkeys.cc:59:0:
upload.cc: In function ‘void logkeys::start_remote_upload()’:
upload.cc:87:30: error: braces around scalar initializer for type ‘unsigned int’
logkeys.cc: In function ‘void logkeys::set_signal_handling()’:
logkeys.cc:154:30: error: braces around scalar initializer for type
‘unsigned int’
make[3]: *** [logkeys.o] Error 1
make[3]: Leaving directory `/home/showard/logkeys-0.1.1a+svn20120529/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/showard/logkeys-0.1.1a+svn20120529'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/showard/logkeys-0.1.1a+svn20120529'
make: *** [debian/stamp-makefile-build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2


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

Bug#673545: sandboxgamemaker FTBFS pending

[Scott Howard]

tags 673545 pending
thanks

i committed the fix to our VCS [1]. I'll take care of hardening and
upload it soon
Thanks!

[1] 
http://anonscm.debian.org/gitweb/?p=pkg-games/sandboxgamemaker.git;a=commitdiff;h=62476042d2063b9a93b35c6984e7ecd0426c2b4e



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

Bug#667168: Thanks re: fparser bug

[Scott Howard]

Thanks Matthias, yes it's ok to upload. The version of Librecad in
wheezy uses it, and I don't know if they'll release a stable version
without fparser before it is released, so I can keep on maintaining it
for now.
~Scott



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

Bug#670565: WProgram.h header included by Arduino.mk

[Scott Howard]

thanks for using and testing the arduino-mk package.

What you're seeing isn't a bug. According to the manual (included in
the package and available here [1])
Note: If you're using version 1.0 of the Arduino software, you'll
need to make sure that the sketch's name ends in .ino and not .pde.


If your file has a .pde extension, it will include WProrgam.h. If it
has a .ino, it will include Arduino.h.

For example:

showard@esc-303123:~/sketchbook/theramin2$ make
/usr/share/arduino/Arduino.mk:513: build-cli/depends.mk: No such file
or directory
echo '#include Arduino.h'  build-cli/theramin2.cpp
cat  theramin2.ino  build-cli/theramin2.cpp
/usr/bin/avr-g++ -MM -mmcu=atmega328p -DF_CPU=1600L -DARDUINO=100
-I. -I/usr/share/arduino/hardware/arduino/cores/arduino
-I/usr/share/arduino/hardware/arduino/variants/standard  -g -Os -w
-Wall -ffunction-sections -fdata-sections -fno-exceptions
build-cli/theramin2.cpp -MF build-cli/theramin2.d -MT
build-cli/theramin2.o
cat build-cli/theramin2.d  build-cli/depends.mk
rm build-cli/theramin2.cpp
cat build-cli/theramin2.d  build-cli/depends.mk
echo '#include Arduino.h'  build-cli/theramin2.cpp
cat  theramin2.ino  build-cli/theramin2.cpp
/usr/bin/avr-g++ -c -mmcu=atmega328p -DF_CPU=1600L -DARDUINO=100
-I. -I/usr/share/arduino/hardware/arduino/cores/arduino
-I/usr/share/arduino/hardware/arduino/variants/standard  -g -Os -w
-Wall -ffunction-sections -fdata-sections -fno-exceptions
build-cli/theramin2.cpp -o build-cli/theramin2.o

[...snip...]

/usr/bin/avr-g++ -c -mmcu=atmega328p -DF_CPU=1600L -DARDUINO=100
-I. -I/usr/share/arduino/hardware/arduino/cores/arduino
-I/usr/share/arduino/hardware/arduino/variants/standard  -g -Os -w
-Wall -ffunction-sections -fdata-sections -fno-exceptions
/usr/share/arduino/hardware/arduino/cores/arduino/WString.cpp -o
build-cli/WString.o
/usr/bin/avr-ar rcs build-cli/libcore.a  build-cli/WInterrupts.o
build-cli/wiring_analog.o  build-cli/wiring.o
build-cli/wiring_digital.o  build-cli/wiring_pulse.o
build-cli/wiring_shift.o  build-cli/CDC.o  build-cli/HardwareSerial.o
build-cli/HID.o  build-cli/IPAddress.o  build-cli/main.o
build-cli/new.o  build-cli/Print.o  build-cli/Stream.o
build-cli/Tone.o  build-cli/USBCore.o  build-cli/WMath.o
build-cli/WString.o
/usr/bin/avr-gcc -mmcu=atmega328p -Wl,--gc-sections -Os -o
build-cli/theramin2.elf build-cli/theramin2.o build-cli/libcore.a  -lc
-lm
/usr/bin/avr-objcopy -O ihex -R .eeprom build-cli/theramin2.elf
build-cli/theramin2.hex

However, I found an unrelated bug with ard-parse-boards which I'll
fixing and uploading ASAP.

If I'm not understanding the bug, please reopen this one. I'm taking a
look at your other report now.

[1] http://mjo.tc/atelier/2009/02/arduino-cli.html



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

Bug#655776: scidavis: diff for NMU version 0.2.4-3.1

[Scott Howard]

tags 624752 + patch
tags 624752 + pending
tags 646190 + patch
tags 646190 + pending
tags 655776 + patch
tags 655776 + pending
tags 658644 + patch
tags 658644 + pending
thanks

Hello again,
I only really care about those bugs (especially the RC ones)
so I've stripped it down to just handle bugs.

I've prepared an NMU for scidavis (versioned as 0.2.4-3.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru scidavis-0.2.4/debian/changelog scidavis-0.2.4/debian/changelog
--- scidavis-0.2.4/debian/changelog 2011-03-16 20:40:52.0 -0400
+++ scidavis-0.2.4/debian/changelog 2012-02-07 12:15:31.0 -0500
@@ -1,3 +1,14 @@
+scidavis (0.2.4-3.1) unstable; urgency=low
+
+  * Non-maintainer upload. (Closes: #658644)
+  * Move plugins to /usr/lib (Closes: #646190)
+debian/patches/lib64.diff
+  * Fixed declaring Graph as const when it is not (Closes: #655776)
+debian/patches/graph_const.diff
+  * Recommends on qt-assistant-compat (Closes: #624752)
+
+ -- Scott Howard show...@debian.org  Tue, 07 Feb 2012 12:14:34 -0500
+
 scidavis (0.2.4-3) unstable; urgency=low
 
   * Add Build-Depends on libqtassistantclient-dev (Closes: #618199)
diff -Nru scidavis-0.2.4/debian/control scidavis-0.2.4/debian/control
--- scidavis-0.2.4/debian/control   2011-03-16 18:33:56.0 -0400
+++ scidavis-0.2.4/debian/control   2012-02-07 12:17:00.0 -0500
@@ -13,6 +13,7 @@
 Package: scidavis
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
+Recommends: qt-assistant-compat
 Description: application for scientific data analysis and visualization
  SciDAVis is a free interactive application aimed at data analysis and 
  publication-quality plotting. It combines a shallow learning curve and 
diff -Nru scidavis-0.2.4/debian/patches/graph_const.diff 
scidavis-0.2.4/debian/patches/graph_const.diff
--- scidavis-0.2.4/debian/patches/graph_const.diff  1969-12-31 
19:00:00.0 -0500
+++ scidavis-0.2.4/debian/patches/graph_const.diff  2012-02-04 
15:30:47.0 -0500
@@ -0,0 +1,25 @@
+Description: remove const qualifier from variables that are not
+Author: Scott Howard show...@debian.org
+Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655776
+Index: scidavis-0.2.4/scidavis/src/scidavis.sip
+===
+--- scidavis-0.2.4.orig/scidavis/src/scidavis.sip  2012-02-04 
15:14:55.700694486 -0500
 scidavis-0.2.4/scidavis/src/scidavis.sip   2012-02-04 15:15:41.352695571 
-0500
+@@ -926,7 +926,7 @@
+   void removeCurve(const QString);
+   void deleteFitCurves();
+   int curves() /PyName=numCurves/;
+-  QListQwtPlotCurve* curves() const /NoDerived/;
++  QListQwtPlotCurve* curves() /NoDerived/;
+ %MethodCode
+   sipRes = new QListQwtPlotCurve*();
+   for (int i = 0; isipCpp-curves(); i++)
+@@ -995,7 +995,7 @@
+   sipRes = sipCpp-d_plot-canvas();
+ %End
+ 
+-  QPointF pickPoint() const /NoDerived/;
++  QPointF pickPoint() /NoDerived/;
+ %MethodCode
+   ApplicationWindow *app = sipscidavis_app();
+   sipRes = new QPointF();
diff -Nru scidavis-0.2.4/debian/patches/lib64.diff 
scidavis-0.2.4/debian/patches/lib64.diff
--- scidavis-0.2.4/debian/patches/lib64.diff1969-12-31 19:00:00.0 
-0500
+++ scidavis-0.2.4/debian/patches/lib64.diff2012-02-06 00:53:53.0 
-0500
@@ -0,0 +1,16 @@
+Description: Install plugins in /usr/lib instead of /usr/lib64
+Author: Scott Howard show...@debian.org
+Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646190
+Index: scidavis-0.2.4/scidavis/scidavis.pro
+===
+--- scidavis-0.2.4.orig/scidavis/scidavis.pro  2012-02-04 14:43:54.884650261 
-0500
 scidavis-0.2.4/scidavis/scidavis.pro   2012-02-04 14:44:11.640650659 
-0500
+@@ -30,7 +30,7 @@
+ }
+ 
+ ### 64 Linux only suffix
+-linux-g++-64: libsuff = 64 
++#linux-g++-64: libsuff = 64 
+ 
+ ### where to install
+ unix: INSTALLBASE = /usr   # this is what is called prefix when 
using GNU autotools
diff -Nru scidavis-0.2.4/debian/patches/series 
scidavis-0.2.4/debian/patches/series
--- scidavis-0.2.4/debian/patches/series2011-03-16 19:02:30.0 
-0400
+++ scidavis-0.2.4/debian/patches/series2012-02-06 00:51:07.0 
-0500
@@ -1,2 +1,4 @@
 sourcefiles_pri.diff
 scidavis_pro.diff
+lib64.diff
+graph_const.diff



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

Bug#647161:

[Scott Howard]

notfound 647161 5.0.3-1+b1
thanks

closing per reporter's comments



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

Bug#554665: gnome-u2ps: diff for NMU version 0.0.4-4.2

[Scott Howard]

tags 554665 + patch
tags 554665 + pending
thanks

Dear maintainer,

I've prepared an NMU for gnome-u2ps (versioned as 0.0.4-4.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u gnome-u2ps-0.0.4/debian/changelog gnome-u2ps-0.0.4/debian/changelog
--- gnome-u2ps-0.0.4/debian/changelog
+++ gnome-u2ps-0.0.4/debian/changelog
@@ -1,3 +1,11 @@
+gnome-u2ps (0.0.4-4.2) unstable; urgency=high
+
+  * Non-maintainer upload
+  * Fixed FTBFS for --no-add-needed flag, binutils-gold (Closes: #554665)
+debian/patches/02_binutils_gold.patch (thanks to Mahyuddin Susanto)
+
+ -- Scott Howard show...@debian.org  Sun, 08 Jan 2012 00:11:17 -0500
+
 gnome-u2ps (0.0.4-4.1) unstable; urgency=low
 
   * Non-maintainer upload.
only in patch2:
unchanged:
--- gnome-u2ps-0.0.4.orig/debian/patches/02_binutils_gold.patch
+++ gnome-u2ps-0.0.4/debian/patches/02_binutils_gold.patch
@@ -0,0 +1,27 @@
+## Description: Fix FTBFS binutils-gold
+## Author: Mahyuddin Susanto udi...@ubuntu.com
+## Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554665
+diff -Nur -x '*.orig' -x '*~' gnome-u2ps-0.0.4/src/Makefile.am 
gnome-u2ps-0.0.4.new/src/Makefile.am
+--- gnome-u2ps-0.0.4/src/Makefile.am   2004-05-05 17:11:31.0 +0700
 gnome-u2ps-0.0.4.new/src/Makefile.am   2011-01-29 07:00:04.308243611 
+0700
+@@ -9,7 +9,7 @@
+ 
+ u2ps_LDADD = \
+   $(U2PS_LIBS) \
+-  $(BZ2_LIBS)
++  $(BZ2_LIBS) -lgnomevfs-2
+ 
+ u2ps_SOURCES = \
+   fribidi.c \
+diff -Nur -x '*.orig' -x '*~' gnome-u2ps-0.0.4/src/Makefile.in 
gnome-u2ps-0.0.4.new/src/Makefile.in
+--- gnome-u2ps-0.0.4/src/Makefile.in   2011-01-29 06:59:43.578244597 +0700
 gnome-u2ps-0.0.4.new/src/Makefile.in   2011-01-29 07:00:16.970745615 
+0700
+@@ -220,7 +220,7 @@
+ 
+ u2ps_LDADD = \
+   $(U2PS_LIBS) \
+-  $(BZ2_LIBS)
++  $(BZ2_LIBS) -lgnomevfs-2
+ 
+ u2ps_SOURCES = \
+   fribidi.c \



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

Bug#654162: Arduino 1.0 and MJO Makefile

[Scott Howard]

Hi Martin,

I got a bug on Debian about using the files from 1.0 with your
makefile. He included a breakdown of what doesn't work with 1.0 and a
patch for the makefile.

If you reply, could you keep the debian bug in the CC: please (this
way we log it there so others can see it).

@Andrea: The Makefile comes from:
http://mjo.tc/atelier/2009/02/arduino-cli.html
Now that MJO is releasing the Makefile, I think I'll separate out the
makefile from the arduino-core package and have it depend on
arduino-core. I'll downgrade the bug too since the package isn't
unusable, it works fine with the java bits and if users want the core
libraries. The Makefile, however, is unusable and will be moved to a
separate package once we figure out a working version.

Cheers,
Scott



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

Bug#654524: wmaker FTBFS on all architectures when building only arch packages

[Scott Howard]

Source: wmaker
Severity: serious
Version: 0.95.0+20111028-1
thanks

FTBFS on this line in debian/rules:
# Fix perms for /usr/share/WindowMaker/*sh
chmod +x debian/wmaker-common/usr/share/WindowMaker/autostart.sh
chmod: cannot access
`debian/wmaker-common/usr/share/WindowMaker/autostart.sh': No such
file or directory


wmaker-common is an architecture-independent package, so autostart.sh
is never installed to debian/wmaker-common/usr/share/WindowMaker since
the buildd don't rebuild indep packages (dh_install was only called
with the -a flag, not the -i flag that would be needed to install
autostart.sh)

Possible fix:
have debian/rules check if the debian/wmaker-common directory exists
before trying to change the permissions of those two scripts.

Rodolfo, you can put a fixed package up on mentors. I'll check it out
and sponsor it for you when you're ready.


~Scott



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

Bug#651331: setting ovito FTBFS to wishlist until muparser is in unstable

[Scott Howard]

severity 651331 wishlist
thanks

muparser isn't in unstable yet. I'll promote to RC when it is.



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

Bug#651331: ovito FTBFS: libmuparser transition

[Scott Howard]

Package: ovito
Version: 0.9.2-1
Severity: serious
Tags: sid

upstream muparser has released a new version of muparser which now follows
standard library naming conventions. Also, the include files in Debian have
moved from /usr/include/muParser to /usr/include.  Ovito FTBFS because of a
#include muParser/muParser.h that now must be #include muParser.h

Also, please consider adding a Depends on python in the control file, see:
http://lintian.debian.org/maintainer/pjme...@gmail.com.html#ovito



-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric')
Architecture: i386 (i686)

Kernel: Linux 3.0.0-13-generic-pae (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



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

Bug#627435: merging bugs caused by V4L1 API

[Scott Howard]

reassign 627435 xawtv
forcemerge 627435 644761
thanks

merging these two bug reports since they both are caused by V4L1 API,
no longer supported by Linux.

See:
https://bugzilla.redhat.com/show_bug.cgi?id=680813

Can be fixed by upgrading to 3.100. Also applying Fedora's patches may
help with this and other bugs.



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

Bug#646030: bug to halt transition to testing

[Scott Howard]

Package: qcad
Version: 2.0.5.0-1+090318.1-2
Severity: serious

librecad doesn't have the new fonts yet, don't force it on users until it's
ready



-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric')
Architecture: i386 (i686)

Kernel: Linux 3.0.0-12-generic-pae (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



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

Bug#375252: partlibrary removed from unstable

[Scott Howard]

partlibrary has been removed, bug has been filed against
release.debian.org to remove it from squeeze and lenny

There has been some discussion about bringing it back as a contrib
package that downloads it from the Internet, but that is a little
shady since still no one has a license to distribute it.



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

Bug#375252: we do not have a license to distribute partlibrary

[Scott Howard]

reopen 375252
severity 375252 serious
thanks

http://packages.debian.org/changelogs/pool/main/p/partlibrary/current/copyright
is incorrect, no where in the package does it say it is GPL; and no
where on the website does it say it has any license at all.

In fact, upstream (qcad) doesn't have the license to even distribute
those files.

Removal will be requested.



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

Bug#644786: qcad documentation and fonts are non free

[Scott Howard]

I'm acking this bug. I'll be uploading a qcad source package removing
it from unstable and recommending librecad because of this and bug:
604595

I'll also move to remove qcad-doc from stable/testing distributions.

Lisandro, just confirming - upstream says the fonts are non-free too,
is that correct?

If so, we'll need need to remove the qcad package as well.



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

Bug#621947: cdkxdb2 FTBFS: seems to be a gtk issue

[Scott Howard]

block 621947 by 622195
thanks

Seems to be a gtk issue, see [1, 2], and many others (e.g. Bug#621949,
Bug#622044) the location of gdk-pixbuf.h was recently moved and
causing lots of FTBFS.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621950
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622195



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

Bug#611131: libmuparser SONAME renaming

[Scott Howard]

I put muparser in git [1] and made a branch [2] so we can work on this
bug. The diff is up at [3].

Gudjon: could you take a look at it and let me know what you think?
Feel free to edit it/upload it or give me the OK and I'll Team upload
it. The other change I made was to use git vcs so we can use
pristine-tar and track/review changes in branches like this. If you
don't want to do that, change it back to svn.

I didn't make symbols files because that is an extra burden that the
maintainer should decide if they want to do or not.

~Scott

[1] http://git.debian.org/?p=debian-science/packages/muparser.git
[2] 
http://git.debian.org/?p=debian-science/packages/muparser.git;a=shortlog;h=refs/heads/SONAME_fix
[3] 
http://git.debian.org/?p=debian-science/packages/muparser.git;a=commitdiff;h=6a379e1cb1cd403a3bfff3960e0b01472f011d14



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

Bug#611131: [muparser] Upstream will reversion starting at 2.0.0

[Scott Howard]

Just got this note from upstream:

The next Version will reset the version number to 2.0.0 in order to allow
for soname compliant version numbers in the future.


So it will be fixed in the future, for now we can use the temporary
0debian1.0.0 work around



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

Bug#606120: [libmuparser] ABI change without soname bump

[Scott Howard]

Upstream releases all libraries as 0.0.0, which is quite a problem.

We can, for the time being, release libraries as
libmuparser.so.0debian1.0.0 and bump the debian revision with the ABI
changes.


not proper patches, but here's a summary:

---
Makefile.in

@COND_PLATFORM_MACOSX_0_USE_SOVERSION_1@__muParser_dll___targetsuf2 \
@COND_PLATFORM_MACOSX_0_USE_SOVERSION_1@= .$(SO_SUFFIX).0debian1

@COND_PLATFORM_MACOSX_0_USE_SOVERCYGWIN_0_USE_SOVERSION_1@  = \
@COND_PLATFORM_MACOSX_0_USE_SOVERCYGWIN_0_USE_SOVERSION_1@  
.$(SO_SUFFIX).0debian1.0.0

--
rename the package libmuparer0debian1
--
make sure libmuparser0debian1 only has the binary (it currently has
some symlinks in it which should be in -dev)
--
make debian/*.symbols file (e.g.
http://qa.debian.org/cgi-bin/mole/seedsymbols?pkgname=libmuparser0) to
make sure we don't miss another ABI bump
-
upload to experimental, confirm rdepends [1] work with the new package
-
upload to unstable, library transition time...


Gudjon, would you be interested in moving the VCS to debian-science's
git repo? It's a little more friendly to collaborative work on stuff
like this (branches, merging). If you're ok with it, I can set it up.


[1]
  Reverse Depends: libgetfem4++
  Reverse Depends: libmuparser-dev
  Reverse Depends: meshlab
  Reverse Depends: ovito
  Reverse Depends: qtiplot
  Reverse Depends: scidavis



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

Bug#620431: [qtexengine] working on arch dependent symbols fo;e

[Scott Howard]

Thanks - I'm currently working on it. Have all archs and ports except
mips and hppa done.
Cheers,
Scott



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

Bug#327894: vdkxdb2: diff for NMU version 2.4.0-3.2

[Scott Howard]

tags 327894 + patch
tags 327894 + pending
tags 356872 + patch
tags 356872 + pending
tags 601872 + patch
tags 601872 + pending
thanks

Dear maintainer,

I've prepared an NMU for vdkxdb2 (versioned as 2.4.0-3.2) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Below is an edited diff, I removed the sections updating
config.{sub,guess}

Regards.
diff -Nru vdkxdb2-2.4.0/debian/changelog vdkxdb2-2.4.0/debian/changelog
--- vdkxdb2-2.4.0/debian/changelog  2011-02-20 16:07:42.0 -0500
+++ vdkxdb2-2.4.0/debian/changelog  2011-02-20 10:26:08.0 -0500
@@ -1,3 +1,26 @@
+vdkxdb2 (2.4.0-3.2) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * dh 7 build system to use dh-autoreconf (Closes: #327894)
+- Build system now finds cairo (Closes: #356872)
+  * Lintian fixing:
+- E: removed empty manpage
+- W: Updated debian/copyright
+- W: moved libvdkxdb2.so to -dev package
+- W: Debian Policy 3.9.1
+- W: added misc:Depends to debian/control
+- W: dh 7 fixes clean errors
+- W: dh 7 removes call to dh_undocumented
+- W: added source section:libs to debian/control
+- W: debian/compat changed for version 7
+- W: use {binary:Version} in debian/control instead of {Source-version}
+  * source format 3.0 (quilt)
+  * Added Section: libs to source package (Closes: #601872)
+  * Removed Debian maintainer changes to config.{guess,sub}, 
+use autotools-dev to update (prevent further bitrot)
+
+ -- Scott Howard show...@debian.org  Sun, 20 Feb 2011 10:25:57 -0500
+
 vdkxdb2 (2.4.0-3.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru vdkxdb2-2.4.0/debian/compat vdkxdb2-2.4.0/debian/compat
--- vdkxdb2-2.4.0/debian/compat 2011-02-20 16:07:42.0 -0500
+++ vdkxdb2-2.4.0/debian/compat 2010-10-09 20:35:05.0 -0400
@@ -1 +1 @@
-4
+7
diff -Nru vdkxdb2-2.4.0/debian/control vdkxdb2-2.4.0/debian/control
--- vdkxdb2-2.4.0/debian/control2011-02-20 16:07:42.0 -0500
+++ vdkxdb2-2.4.0/debian/control2011-02-19 20:30:37.0 -0500
@@ -1,13 +1,16 @@
 Source: vdkxdb2
+Section: libs
 Priority: optional
 Maintainer: Michael Vogt m...@debian.org
-Standards-Version: 3.6.2.1
-Build-Depends: debhelper ( 4.0), libgtk2.0-dev, libglib2.0-dev , libvdk2-dev 
(= 2.4.0-3), libxbase2.0-dev, doxygen, autotools-dev, chrpath
+Standards-Version: 3.9.1
+Build-Depends: debhelper (= 7.0.50~), libgtk2.0-dev, libglib2.0-dev,
+ libvdk2-dev (= 2.4.0-3), libxbase2.0-dev, doxygen, autotools-dev,
+ dh-autoreconf, chrpath
 
 Package: libvdkxdb2-2c2
 Section: libs
 Architecture: any
-Depends: ${shlibs:Depends}, libxbase2.0-0
+Depends: ${shlibs:Depends}, ${misc:Depends}, libxbase2.0-0
 Conflicts: libvdkxdb2c102, libvdkxdb2-2
 Replaces: libvdkxdb2c102, libvdkxdb2-2
 Description: VDK data-aware widgets
@@ -20,7 +23,7 @@
 Package: libvdkxdb2-dev
 Section: libdevel
 Architecture: any
-Depends: libvdkxdb2-2c2 (= ${Source-Version}), libxbase2.0-dev, libc6-dev
+Depends: ${misc:Depends}, libvdkxdb2-2c2 (= ${binary:Version}), 
libxbase2.0-dev, libc6-dev
 Description: development files for libvdkxdb
  VDKXdb is a set of data-aware widgets made to build
  lightweight database applications using the VDK library.
diff -Nru vdkxdb2-2.4.0/debian/copyright vdkxdb2-2.4.0/debian/copyright
--- vdkxdb2-2.4.0/debian/copyright  2011-02-20 16:07:42.0 -0500
+++ vdkxdb2-2.4.0/debian/copyright  2010-10-09 22:14:26.0 -0400
@@ -8,5 +8,6 @@
 Upstream Authors:
 please see the original AUTHORS file.

-Copyright:
+Copyright 2000 Mario Motta mmo...@guest.net
+License:
 LGPL (see /usr/share/common-licenses/LGPL)
diff -Nru vdkxdb2-2.4.0/debian/dirs vdkxdb2-2.4.0/debian/dirs
--- vdkxdb2-2.4.0/debian/dirs   2011-02-20 16:07:42.0 -0500
+++ vdkxdb2-2.4.0/debian/dirs   1969-12-31 19:00:00.0 -0500
@@ -1,4 +0,0 @@
-usr/bin
-usr/lib
-usr/include
-usr/share/doc/libvdkxdb2-dev/html
diff -Nru vdkxdb2-2.4.0/debian/docs vdkxdb2-2.4.0/debian/docs
--- vdkxdb2-2.4.0/debian/docs   2011-02-20 16:07:42.0 -0500
+++ vdkxdb2-2.4.0/debian/docs   1969-12-31 19:00:00.0 -0500
@@ -1,3 +0,0 @@
-AUTHORS
-NEWS
-README
diff -Nru vdkxdb2-2.4.0/debian/libvdkxdb2-2c2.install 
vdkxdb2-2.4.0/debian/libvdkxdb2-2c2.install
--- vdkxdb2-2.4.0/debian/libvdkxdb2-2c2.install 1969-12-31 19:00:00.0 
-0500
+++ vdkxdb2-2.4.0/debian/libvdkxdb2-2c2.install 2010-10-09 22:40:29.0 
-0400
@@ -0,0 +1 @@
+debian/tmp/usr/lib/*.so.* /usr/lib
diff -Nru vdkxdb2-2.4.0/debian/libvdkxdb2-dev.docs 
vdkxdb2-2.4.0/debian/libvdkxdb2-dev.docs
--- vdkxdb2-2.4.0/debian/libvdkxdb2-dev.docs1969-12-31 19:00:00.0 
-0500
+++ vdkxdb2-2.4.0/debian/libvdkxdb2-dev.docs2010-10-09 22:28:32.0 
-0400
@@ -0,0 +1,4 @@
+AUTHORS
+NEWS
+README
+doc/doxy/html/*.html
diff -Nru vdkxdb2-2.4.0/debian/libvdkxdb2-dev.examples 
vdkxdb2-2.4.0/debian/libvdkxdb2-dev.examples
--- vdkxdb2-2.4.0/debian/libvdkxdb2-dev.examples1969-12-31

Bug#611119: eagle: FTBFS: dpkg-shlibdeps: error: couldn't find library libssl.so.0.9.8

[Scott Howard]

Thanks - I actually have an upload ready to go.

Since these packages are non-free, I build it on both i386 and amd64
using pbuilder and upload the binary packages - that's why we haven't
seen this bug before.



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

Bug#609152: Java application depending on binary dependent packages

[Scott Howard]

Since this is currently classified as an RC bug and we are close to
squeeze release, I'll post updates as they come along

The package in testing/unstable builds on powerpc [1]. However,
previous uploads before I adopted these packages FTBFS on powerpc and
thus was removed. I've filed to have it re-included [2]. Hopefully,
rxtx will be available for powerpc soon, thus closing this bug.

Francesco: if you would like to help, you can download the source
package for rxtx that is currently in testing, build and install it.
It should then let you install arduino. If you try, let us know that
it worked.

[1] 
https://buildd.debian.org/fetch.cgi?pkg=rxtxarch=powerpcver=2.2pre2-2stamp=1287926216file=logas=raw
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609227



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

Bug#609152: Java application depending on binary dependent packages

[Scott Howard]

Hello Java team,

Looking at bug #609152 [1]:

There is a Java application which depends on a JNI library which is
only built on a subset of architectures. A bug has been filed against
the java package because it is un-installable on the architectures
that the JNI library does not exist (since it cannot install the
dependency). Although I remember reading somewhere that such a
dependency is allowed, I cannot find that reference. Is the current
arrangement acceptable, or should this be fixed by making the java
application architecture: any (so it won't build on unavailable
architectures)? I think it is silly to have multiple identical
packages in order to limit the installation to architectures where the
library exists, but that will remove the binary package from affected
architectures.

Thanks, and please CC: the bug and Francesco (the reporter).

Cheers,
Scott

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609152



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

Bug#327894:

[Scott Howard]

This package is not in good shape. It should be orphaned or fixed up
and maintained. I prepared a QA upload to fix many of the lintian
errors/warnings as well as this and another FTBFS bug. It can be
found:
- URL: http://mentors.debian.net/debian/pool/main/v/vdkxdb2
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/v/vdkxdb2/vdkxdb2_2.4.0-3.2.dsc

If it is to be maintained, please feel free to use anything there
however you wish. If it is to be orphaned, you can use that as the QA
upload when the maintainer is set to the QA team.



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

Bug#599629: sandboxgamemaker: FTBFS: error: member stats endianswap(T) […] not allowed in union

[Scott Howard]

tags 599629 patch
tags 599629 upstream
forwarded 599629  http://forum.sandboxgamemaker.com/tracker.php?p=3t=63
thanks

Will need some testing, but here's a patch from upstream:

Index: src/rpggame/rpgio.cpp
===
--- src/rpggame/rpgio.cpp   (revision 2693)
+++ src/rpggame/rpgio.cpp   (revision 2694)
@@ -260,7 +260,7 @@
use_armour *arm = (use_armour *) usable;

f-read(arm-reqs, sizeof(statreq));
-   lilswap(arm-reqs);
+   lilswap(arm-reqs.attrs[0], 
sizeof(statreq));

arm-slots = f-getlilint();
arm-skill = f-getlilint();
@@ -304,7 +304,7 @@
base-mdl = readstring(f);

f-read(base-base, sizeof(stats));
-   lilswap(base-base);
+   lilswap(base-base.experience, sizeof(stats));

int items = f-getlilint();
loopi(items)
@@ -605,7 +605,7 @@

saveheader hdr;
f-read(hdr, sizeof(saveheader));
-   lilswap(hdr);
+   lilswap(hdr.version);

if(hdr.version != GAME_VERSION || strncmp(hdr.magic, 
GAME_MAGICZ, 4))
{
@@ -900,7 +900,7 @@
use_armour *use = (use_weapon *) 
item-uses[i];

statreq tmp = use-reqs;
-   lilswap(tmp);
+   lilswap(tmp.attrs[0], sizeof(statreq));
f-write(tmp, sizeof(tmp));

f-putlil(use-slots);
@@ -933,7 +933,7 @@
writestring(f, base-mdl);

stats tmp = base-base;
-   lilswap(tmp);
+   lilswap(tmp.experience, sizeof(stats));
f-write(tmp, sizeof(stats));

f-putlil(base-inventory.length());
@@ -1193,7 +1193,7 @@
memcpy(hdr.magic, GAME_MAGICZ, 4);
hdr.version = GAME_VERSION;

-   lilswap(hdr);
+   lilswap(hdr.version);
f-write(hdr, sizeof(saveheader));

lastmap = game::curmap;



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

Bug#592544:

[Scott Howard]

I don't know when it was changed, but I got that from upstream
(libevas upstream) here [1]. Debian unstable has the version with the
new license [2,3], they just haven't updated their debian/copyright
file yet even though unstable has the new license. To be clear,
libevas' license changed, not zhone.

[1] http://download.enlightenment.org/snapshots/LATEST/evas-0.9.9.49898.tar.gz
[2] 
http://git.debian.org/?p=pkg-e/libs/evas.git;a=blob;f=COPYING;h=9690c3f6f6635e76f276fa87db460daab7dbbcac;hb=HEAD
[3] 
http://git.debian.org/?p=pkg-e/libs/evas.git;a=blob;f=COPYING;h=9690c3f6f6635e76f276fa87db460daab7dbbcac;hb=621258c7dda9efebca844ae505f004354db897c6



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

Bug#592544: New license

[Scott Howard]

Upstream has changed their license [1].

They no longer require the advertising clause: In addition publicly
documented acknowledgment must be given that this software has been used if no
source code of this software is made available publicly. Does GPL's
requiring that the source code be publicly available make this license
compatible with GPL?



[1]:
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the Software), to
deal in the Software without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies of the Software and its Copyright notices. In addition publicly
documented acknowledgment must be given that this software has been used if no
source code of this software is made available publicly. Making the source
available publicly means including the source for this software with the
distribution, or a method to get this software via some reasonable mechanism
(electronic transfer via a network or media) as well as making an offer to
supply the source on request. This Copyright notice serves as an offer to
supply the source on on request as well. Instead of this, supplying
acknowledgments of use of this software in either Copyright notices, Manuals,
Publicity and Marketing documents or any documentation provided with anyad
product containing this software. This License does not apply to any software
that links to the libraries provided by this software (statically or
dynamically), but only to the software provided.

Please see the COPYING-PLAIN for a plain-english explanation of this notice
and its intent.

THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.



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

Bug#566967: Eagle crashes when opening files, moving wires, etc.

[Scott Howard]

Package: eagle
Version: 5.7.0-1
Tags: patch
Severity: grave

From Shaun Jackman:

There's a bug in the debian/bin/eagle script. If you install upgrade
from Eagle 5.6 to Eagle 5.7, it crashes when you try to move a wire. A
patch follows. I've uploaded 5.7.0-1 with this patch.

Cheers,
Shaun

--- 5.6.0/eagle-5.6.0/debian/bin/eagle  2010-01-13 23:16:20.0 -0800
+++ 5.7.0/eagle-5.7.0/debian/bin/eagle  2010-01-25 21:00:56.0 -0800
@@ -15,8 +15,6 @@
   mkdir ~/.eagle/bin
   ln -s /usr/share/eagle/bin/* ~/.eagle/bin
 fi
-if [ ! -x ~/.eagle/bin/eagle ]; then
-   cp /usr/lib/eagle/bin/eagle ~/.eagle/bin
-fi
+cp -f /usr/lib/eagle/bin/eagle ~/.eagle/bin

 exec -a ~/.eagle/bin/eagle /usr/lib/eagle/bin/eagle $@



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