Bug#954431: direwolf: Please add kissutil binary to the direwolf package

[Scott Howard]

Package: direwolf
Version: 1.5+dfsg-2
Severity: normal

Dear Maintainer,

kissutil is being built during the debian buildd, but it is not installed.
Please add it to debian/direwolf.install with the other utility programs.

Thank you!

Bug#862795: printrun: pronterface should use slic3r command instead of skeinforge

[Scott Howard]

Package: printrun
Version: 0~20150310-5ubuntu1
Severity: minor

Dear Maintainer,

the pronterface package suggests the slic3r package and does not come with
skeinforge, yet the default settings in pronterface call skeinforge.

I suggest correcting the "Settings->External Commands->Slice Command" to be:

"slic3r $s -o $o"

and the "Slicer option command" should be be

"slic3r"

as suggested by "Macros in pronsole and pronterface" at
https://github.com/kliment/Printrun/blob/master/README.md


Otherwise, perhaps suggest the sfact package and fix the Slice Command and
Option paths so they point to the correct sfact skeinforge path.



-- System Information:
Debian Release: stretch/sid
  APT prefers zesty-updates
  APT policy: (500, 'zesty-updates'), (500, 'zesty-security'), (500, 'zesty'), 
(100, 'zesty-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.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
Init: systemd (via /run/systemd/system)

Versions of packages printrun depends on:
ii  libc62.24-9ubuntu2
ii  python   2.7.13-2
ii  python-cairosvg  1.0.20-1
ii  python-dbus  1.2.4-1
ii  python-gobject   3.22.0-2
ii  python-libxml2   2.9.4+dfsg1-2.2
ii  python-numpy 1:1.12.1-1ubuntu1
ii  python-psutil5.0.1-1
ii  python-pyglet1.1.4.dfsg-3
ii  python-serial3.2.1-1
ii  python-wxgtk3.0  3.0.2.0+dfsg-4
pn  python:any   

printrun recommends no packages.

Versions of packages printrun suggests:
ii  slic3r  1.2.9+dfsg-6

-- no debconf information

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#850784: arduino: No HiDPI support in arudino 1.0.5

[Scott Howard]

Hello,
Arduino had some licensing issues that prevented it from being
upgraded in debian that were resolved last month. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780706

it looks like it can go forward again!
-Scott

On Tue, Jan 10, 2017 at 2:25 AM, solitone  wrote:
> Package: arduino
> Version: 2:1.0.5+dfsg2-4.1
> Severity: normal
>
> stretch delivers arduino 1.0.5, which is pretty old. This means
> that some of the new features are not available. Specifically, it
> doesn't work well with HiDPI displays (aka retina displays). In
> the latest version (1.8.1) there is a global preference setting
> that allows to scale the interface to e.g. 200%, which is a nice
> setting for my MacBookPro 13". Would it be possible to include in
> stretch a more up to date version, including this feature?
> --
> System Information: Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages arduino depends on:
> ii  arduino-core   2:1.0.5+dfsg2-4.1
> ii  default-jre [java6-runtime]2:1.8-57
> ii  libjna-java4.2.2-2
> ii  librxtx-java   2.2pre2-13
> ii  openjdk-8-jre [java6-runtime]  8u111-b14-3
>
> Versions of packages arduino recommends:
> ii  extra-xdg-menus  1.0-4
> ii  policykit-1  0.105-17
>
> arduino suggests no packages.
>
> -- no debconf information

Bug#846606: Found where ipython test is failing

[Scott Howard]

Autodep8 is generating the test that is failing:

https://anonscm.debian.org/cgit/collab-maint/autodep8.git/tree/support/python/generate

IPython should include its own test. Add the following lines to
debian/tests/control


Test-Command: cd "$ADTTMP" ; python -c "import IPython; print IPython"
Depends: python-ipython

Test-Command: cd "$ADTTMP" ; python3 -c "import IPython; print(IPython)"
Depends: python3-ipython

Bug#846606: ipython failing on ci.debian.net

[Scott Howard]

Package: ipython
Version: 2.4.1-1
Severity: minor

Dear Maintainer,

On https://ci.debian.net/packages/i/ipython/unstable/amd64/

ipython 5.1.0-2 is failing:
https://ci.debian.net/data/packages/unstable/amd64/i/ipython/20161107_090954.autopkgtest.log.gz

>From the log:
autopkgtest [09:21:21]: test command2: set -e ; for py in $(py3versions -r
2>/dev/null) ; do cd "$ADTTMP" ; echo "Testing with $py:" ; $py -c "import
ipython; print(ipython)" ; done

ImportError: No module named 'ipython'


The test should be:
$py -c "import IPython; print(IPython)"

(capitalization matters)

I don't know where this test is coming from... I can't find the package this is
happening in to fix it.

-Scott



-- System Information:
Debian Release: stretch/sid
  APT prefers yakkety-updates
  APT policy: (500, 'yakkety-updates'), (500, 'yakkety-security'), (500, 
'yakkety'), (100, 'yakkety-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.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
Init: systemd (via /run/systemd/system)

Versions of packages ipython depends on:
ii  python2.7.11-2
ii  python-decorator  4.0.6-1
ii  python-pexpect4.2.0-1
ii  python-simplegeneric  0.8.1-1

ipython recommends no packages.

Versions of packages ipython suggests:
pn  ipython-doc   
ii  ipython-notebook  2.4.1-1
pn  ipython-qtconsole 
ii  python [python-profiler]  2.7.11-2
ii  python-matplotlib 1.5.2~rc2-1
ii  python-numpy  1:1.11.1~rc1-1ubuntu1
ii  python-zmq15.2.0-1ubuntu1

-- no debconf information

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#824066: RM: eagle -- ROM; non-free package depends on libssl1.0.0

[Scott Howard]

Package: ftp.debian.org
Severity: normal

Hello, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804531

eagle contains a pre-compiled non-free binary that depends on libssl1.0.0.
libssl1.0.0 is planned to be removed soon.

I've informed upstream, they are working on it - but no need to hold up libssl
transition in the mean time.

Cheers,
Scott

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#780706: Update re: arduino 1.6+

[Scott Howard]

The update is there is no update. The Debian git repository is still ready
to go,. I don't have time to work on it that much at the moment (either on
following up with licensing or packaging), so if anyone is interested in
helping out in any way (including co-maintaining or adopting the package),
please let me know.
~Scott

Bug#810652: phing fails to start: default.properties needs patch

[Scott Howard]

On Sun, Jan 10, 2016 at 10:01 PM, David Prévot  wrote:
> Control: retitle -1 phing fails to start: Missing JsMinTask.php
> Control: found -1 2.9.1-1
>

Thank you for figuring it out the root cause! I don't think there is a
rush; people can easily find this report and fix it themselves if they
are using the sid version. Part of the fun of unstable
Cheers,
Scott

Bug#810201: openmw: diff for NMU version 0.37.0-1.1

[Scott Howard]

On Thu, Jan 21, 2016 at 11:17 AM, bret curtis  wrote:
> Hello there,
>
> we're about to upload 0.38 which already includes the change from
> libpng12-dev to  libpng-dev.

New version 0.38.0 has been uploaded.

Bug#810652: phing fails to start: default.properties needs patch

[Scott Howard]

Package: phing
Version: 2.13.0-1
Severity: important

Dear Maintainer,

When phing is run, it will fail:
$ phing
Buildfile: /home/showard/bootstrap/sitecake/build.xml
[PHP Error] include_once(phing/tasks/ext/jsmin/JsMinTask.php): failed to open
stream: No such file or directory [line 1272 of /usr/share/php/phing/Phing.php]
[PHP Error] include_once(): Failed opening
'phing/tasks/ext/jsmin/JsMinTask.php' for inclusion
(include_path='/usr/share/php/../classes:.:/usr/share/php:/usr/share/pear')
[line 1272 of /usr/share/php/phing/Phing.php]

BUILD FAILED
exception 'ConfigurationException' with message 'Error importing
phing/tasks/ext/jsmin/JsMinTask.php' in /usr/share/php/phing/Phing.php:1280
Stack trace:
#0 /usr/share/php/phing/Phing.php(1227): Phing::__import('phing/tasks/ext...',
NULL)
#1 /usr/share/php/phing/Project.php(630): Phing::import('phing.tasks.ext...',
NULL)
#2 /usr/share/php/phing/Project.php(163): Project->addTaskDefinition('jsmin',
'phing.tasks.ext...')
#3 /usr/share/php/phing/Phing.php(628): Project->init()
#4 /usr/share/php/phing/Phing.php(191): Phing->runBuild()
#5 /usr/share/php/phing/Phing.php(316): Phing::start(Array, NULL)
#6 /usr/share/php/phing.php(58): Phing::fire(Array)
#7 {main}

Total time: 0.0417 seconds

Error importing phing/tasks/ext/jsmin/JsMinTask.php



Why:
JsMinTask.php is non-free, and removed during the config step in debian/rules.
However /usr/share/php/data/phing/tasks/default.properties still refers to it

Fix:
Comment/delete the following line from
/usr/share/php/data/phing/tasks/default.properties

jsmin=phing.tasks.ext.jsmin.JsMinTask

Reference:
https://bugzilla.redhat.com/show_bug.cgi?id=894748#c14

Cheers,
Scott



-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-23-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
Init: systemd (via /run/systemd/system)

Versions of packages phing depends on:
ii  php5-cli 5.6.11+dfsg-1ubuntu3.1
ii  php5-common  5.6.11+dfsg-1ubuntu3.1

Versions of packages phing recommends:
ii  pdepend2.1.0-2
ii  php-codesniffer2.3.3-1
ii  php-http-request2  2.2.1-2
ii  php-pear   5.6.11+dfsg-1ubuntu3.1
ii  php5-xdebug2.3.3-1ubuntu1
ii  phpmd  2.2.3-1

phing suggests no packages.

-- no debconf information

Bug#802912: nmu: openmw_0.36.1-1

[Scott Howard]

On Mon, Oct 26, 2015 at 5:12 AM, Emilio Pozuelo Monfort
<po...@debian.org> wrote:
> On 25/10/15 02:27, Scott Howard wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: binnmu
>>
>> nmu openmw_0.36.1-1 . ANY . unstable . -m "rebuild against new libbullet"
>>
>> The maintainer (Bret Curtis) is busy but asked me to request this binNMU
>>
>> Game crashes because it was compiled against an old libbullet. More info:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801914
>> https://forum.openmw.org/viewtopic.php?f=2=3053
>
> Sounds like you need a library transition.
>
> Emilio

Yes, but the discussion on the libbullet transition went another way:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790988#35

Perhaps a transition for bullet is needed after all?

Bug#802912: nmu: openmw_0.36.1-1

[Scott Howard]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu openmw_0.36.1-1 . ANY . unstable . -m "rebuild against new libbullet"

The maintainer (Bret Curtis) is busy but asked me to request this binNMU

Game crashes because it was compiled against an old libbullet. More info:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801914
https://forum.openmw.org/viewtopic.php?f=2=3053

Bug#800372: eagle in debian

[Scott Howard]

Source: eagle
Version: 6.6.0-2
Severity: wishlist

Thanks for letting me know, I haven't checked for some time. As long
as licensing hasn't changed I can update to 7.4.0

On Sun, Sep 27, 2015 at 8:00 AM, Folkert van Heusden
 wrote:
> Hi,
>
> Any plans on upgrading Eagle in Debian to the latest version? (7.4.0)
>
>
> regards
>
> --
> www.vanheusden.com

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#778034: ogre-1.9 transition, blender needs binNMU

[Scott Howard]

Looks like blender needs a binNMU to build against the v5 version of
opencolorio. Then blender, ogre-1.9, and dependencies can transition
https://packages.qa.debian.org/b/blender.html

Bug#791211: mygui uploaded to unstable (NEW)

[Scott Howard]

Hello all,
mygui uploaded to unstable. Since we're changing the package name back
to the original SONAME and appending v5, it's gone in the NEW queue
again.
Cheers,
Scott

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]

On Sun, Aug 23, 2015 at 1:36 PM, Simon McVittie s...@debian.org wrote:
 On Fri, 21 Aug 2015 at 17:21:33 -0400, Scott Kitterman wrote:
 Since this has no C++ build-deps is can go ahead to unstable without RT ack.

 This is now fixed in unstable too.

I'm going through and requesting NMUs as needed on depending packages.
There are a couple other libraries that also need to finish their
transitions in order to build of muparser's reverse depends (e.g.,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791046)

Bug#791046: getfem++ and GCC 5 transition

[Scott Howard]

user release.debian@packages.debian.org
usertag 791046 + transition
block 791046 by 790756
reassign 791046 release.debian.org
thanks

I have prepared a team upload to experimental using the previously posted patch.
http://anonscm.debian.org/cgit/debian-science/packages/getfem.git
This is part of a bug-fix update of the upstream source from
4.2.1~beta1~svn4635~dfsg
to
4.3+dfsg

However, it's blocked by:
 libstdc++6 : Breaks: python-scipy (= 0.14.1-1) but 0.14.1-1 is to be
installed.

That's there because it was built from cpython and required c++ support:
https://lists.debian.org/debian-gcc/2015/08/msg00046.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793227

I'll submit a separate binNMU request for python-scipy that blocks this

Bug#791046: getfem++ and GCC 5 transition

[Scott Howard]

On Sun, Aug 23, 2015 at 3:58 PM, Anton Gladky gl...@debian.org wrote:
 Hi Scott,

 thanks for the pushing it.
 I think there is no need to upload it into experimental, let`s
 upload it directly into unstable. The only problem is that
 there is already a newer version of getfem than in our git, 5.0.
 So I do not think there is a need to push the previous
 svn-version.


Hi Anton, I was just writing you about this, thanks for catching it earlier
The push to experimental was to get the new package name through the
NEW queue, trigger an auto-transition tracker, and give time for you
to review changes without changing the library interface. I haven't
tested reverse-depends against libgetfem5++ so I'm not comfortable
enough with this library to bump the soversion. But you're right, it
would be ideal to do push the version released last month if possible.
Cheers,
Scott

Bug#791209: Patched muparser for gcc 5 transitio

[Scott Howard]

On Sun, Aug 23, 2015 at 3:50 PM, Scott Howard showard...@gmail.com wrote:
 I'm going through and requesting NMUs as needed on depending packages.
 There are a couple other libraries that also need to finish their
 transitions in order to build of muparser's reverse depends (e.g.,
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791046)

No, I'm not filiing binNMUs
Julien Cristau: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794989#10
Please don't go around filing binNMU bugs for the libstdc++ transition.
Stuff will be rebuilt as we get to it.

Bug#791209: Patched muparser for gcc 5 transitio

[Scott Howard]

On Fri, Aug 14, 2015 at 4:05 AM, Simon McVittie s...@debian.org wrote:
 On Tue, 11 Aug 2015 at 18:47:58 -0400, Scott Howard wrote:
 Package renamed to libmuparser2v5.
 See patch:
 http://anonscm.debian.org/cgit/debian-science/packages/muparser.git/patch/?id=5fb47ad4af6a7e4cdddbb078b7159d552c0e1f86

 This is unusual: you've changed the SONAME to libmuparser.so.2v5.
 For other packages in this transition, the approach that has been taken
 (as recommended in the mass bug filing) was to rename the *package* to
 libmuparser.so.2v5, but leave the SONAME at libmuparser.so.2.

 For instance, here's a similar change to liborigin2:
 http://launchpadlibrarian.net/213540578/liborigin2_2%3A20110117-1build4_2%3A20110117-1ubuntu1.diff.gz
 (Note that the lintian override in that patch is unnecessary in Debian;
 lintian has been changed to not complain about the v5 suffix.)

 Release team: is it a problem that the transition has been done differently
 in this way?

Thank you - this is my mistake, I modelled it after this NMU:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;filename=libbitcoin.nmu.debdiff;bug=791092;msg=19
Which I originally thought bumped the SONAME as well. We can restore
it before upload to unstable.
~Scott

Bug#791211: bump mygui soname for gcc5 transition

[Scott Howard]

On Wed, Aug 12, 2015 at 1:17 PM, Scott Howard showard...@gmail.com wrote:
 soname bumped for gcc transition.
 Patch:
 http://anonscm.debian.org/cgit/collab-maint/mygui.git/patch/?id=24f1d486b2db47e7d301d3f0b112a6180ea355fe

soname should not have been bumped, will set it back and follow this example:
http://launchpadlibrarian.net/213540578/liborigin2_2%3A20110117-1build4_2%3A20110117-1ubuntu1.diff.gz
in upload to unstable

Bug#791209: gcc 5 transitions: mygui and muparser uploaded to experimental NEW queue

[Scott Howard]

The package has been uploaded to experimental, NEW queue

Bug#791211: bump mygui soname for gcc5 transition

[Scott Howard]

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

soname bumped for gcc transition.
Patch:
http://anonscm.debian.org/cgit/collab-maint/mygui.git/patch/?id=24f1d486b2db47e7d301d3f0b112a6180ea355fe

ready for upload:
http://anonscm.debian.org/cgit/collab-maint/mygui.git/

just let me know when it's clear. NMU is fine too if it is easier
Cheers,
Scott

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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#733823: Adopting dxflib

[Scott Howard]

On Aug 8, 2015 2:12 AM, Alastair McKinstry alastair.mckins...@sceal.ie
wrote:

 Hi,

 I'm willing to step in as responsible uploader for dxflib, as it is now
 a dependency of a package I maintain, terralib.

Great! Thank you.
Scott

Bug#793218: bitcoin: change of type in system_error might break with GCC-5

[Scott Howard]

Yes, bitcoin is affected by this - thank you!


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#789461: ITP: runescape -- Complete quests and win enormous treasures in RuneScape

[Scott Howard]

On Sun, Jun 21, 2015 at 4:04 AM, Carlos Donizete corin...@riseup.net wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Carlos Donizete corin...@riseup.net

 * Package name: runescape
   Version : 0.1
   Upstream Author : Jagex Limited advertis...@jagex.com
 * URL : http://www.runescape.com/
 * License : GPL-2+
   Programming Lang: Java
   Description : Complete quests and win enormous treasures in RuneScape

  The game is a unofficial Linux client Java-based. It makes sure that
  OpenGL works when using Java7/OpenJDK7.
  .
  RuneScape offers players a huge variety of benefits such as hundreds
  of additional quests and adventures, a larger game world to explore,
  exclusive skills and master and access to a whole host of minigames.
  .
  Players can also access the most powerful weaponry and armour in the game,
  create clan citadels with their friends and even build their very own house.

thanks for looking in to this, here are some comments

I agree with what Johannes Schauer asked (who is the author, where is
it from, what does this package actually do), and the short and long
description should be updated accordingly. The first paragraph of the
long description should be more informative to potential users.
1) I also don't like calling open source software official or
unofficial. It just is what it is. If it is just checking for
library compatibilities, then you actually are playing the official
(proprietary) game anyways.
2) Whether it is java-based or not doesn't really matter for someone
installing the package (unless there is a non-java alternative,
perhaps).
3) The mechanisms of checking for OpenGL working with Java7 doesn't
really matter to someone wanting to play the game/

If the code is DFSG, but requires non-free content to be useful, it is
at best contrib.


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

Bug#780706: arduino: Request for Arduino IDE 1.6.1 package

[Scott Howard]

On Wed, Mar 18, 2015 at 1:23 AM, Martin Stoufer mcstou...@speakeasy.net wrote:
 I am having a miserable time getting the current 1.5.2 unstable release to 
 patch properly
 for 1.6.0 release on my Raspberry Pi (jessie/main). Is it all possible to get 
 this in the pipeline (and even skip 1.5.2 release?)

Hello - the plan is to have 1.6+ after jessie and it is already to go.
However, we need updated licensing info from arduino:
https://github.com/arduino/Arduino/pull/2703

Also, the arduino-mk tool will have to be updated to the 1.5+ branch,
which that project has not done yet.

In the meantime, 1.5.6rc2 is packaged in experimental:
https://packages.debian.org/experimental/arduino

Hope that help
~Scott


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

Bug#726062: update

[Scott Howard]

Hello,
An update on this bug to add due support to the arduino package:
the arduino sam support relies on CMSIS, which is not DFSG free (you
are only allowed to use it with ARM development)

SAM support will end up in non-free as a package arduino-hardware-sam,
and will probably not land until after Jessie is released.

I'm working on 1.6.0, but have also asked for an updated license from arduino:
https://github.com/arduino/Arduino/pull/2703

~Scott


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

Bug#780559: scan-build doesn't handle -isystem compile arguments correctly

[Scott Howard]

Source: clang
Version: 1:3.5-26
Severity: normal
Tags: upstream patch

From:
https://llvm.org/bugs/show_bug.cgi?id=13237

clang mirrors gcc in that it allows an optional space when specifying include
paths, i.e. it supports both `-I/DIR and `-I /DIR` or along the same line
`-isystem/DIR` and `-isystem /DIR`.

scan-build understands most of these as well, but not the `-isystem/DIR` form
without the extra space.

a simple patch to scan-build will allow for -isystem arguments

patch from:
Thomas Hauth
https://llvm.org/bugs/attachment.cgi?id=13705

not committed yet, and it still present in all versions of clang. This is
especially a problem using cmake as it uses -isystem for system libraries by
default.


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

Bug#769026: unblock: cgminer/4.7.0-2

[Scott Howard]

)
+.TP
+\fB\-\-temp\-cutoff\fR   
+Temperature where a device will be automatically disabled, one value or comma separated list (default: 0)
+.TP
+\fB\-\-text\-only\fR|\-T  
+Disable ncurses formatted screen output
+.TP
+\fB\-\-url\fR|\-o arg  
+URL for bitcoin JSON\-RPC server
+.TP
+\fB\-\-usb\fR arg 
+USB device selection
+.TP
+\fB\-\-user\fR|\-u arg 
+Username for bitcoin JSON\-RPC server
+.TP
+\fB\-\-userpass\fR|\-O arg 
+Username:Password pair for bitcoin JSON\-RPC server
+.TP
+\fB\-\-verbose\fR   
+Log verbose output to stderr as well as status output
+.TP
+\fB\-\-widescreen\fR
+Use extra wide display without toggling
+.TP
+\fB\-\-worktime\fR  
+Display extra work time debug information
+.SS
+Options for command line only:
+.TP
+\fB\-\-config\fR|\-c arg   
+Load a JSON\-format configuration file
+See example.conf for an example configuration.
+.TP
+\fB\-\-default\-config\fR arg 
+Specify the filename of the default config file
+Loaded at start and used when saving without a name.
+.TP
+\fB\-\-help\fR|\-h   
+Print this message
+.TP
+\fB\-\-ndevs\fR|\-n  
+Display all USB devices and exit
+.TP
+\fB\-\-version\fR|\-V
+Display version and exit
diff -Nru cgminer-4.7.0/debian/changelog cgminer-4.7.0/debian/changelog
--- cgminer-4.7.0/debian/changelog	2014-10-26 10:20:53.0 -0400
+++ cgminer-4.7.0/debian/changelog	2014-11-08 13:16:20.0 -0500
@@ -1,3 +1,11 @@
+cgminer (4.7.0-2) unstable; urgency=medium
+
+  * Only build with recommended configuration on all archs (Closes: #767719)
+- Updated manpage since the new binary will have same configuration
+  on all archs
+
+ -- Scott Howard show...@debian.org  Sat, 08 Nov 2014 11:10:48 -0500
+
 cgminer (4.7.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru cgminer-4.7.0/debian/clean cgminer-4.7.0/debian/clean
--- cgminer-4.7.0/debian/clean	2014-04-16 10:13:47.0 -0400
+++ cgminer-4.7.0/debian/clean	2014-11-08 10:53:58.0 -0500
@@ -1,4 +1,3 @@
 API.class
 *.1
 cgminer-api
-debian/cgminer.1
diff -Nru cgminer-4.7.0/debian/rules cgminer-4.7.0/debian/rules
--- cgminer-4.7.0/debian/rules	2014-10-26 10:27:57.0 -0400
+++ cgminer-4.7.0/debian/rules	2014-11-09 17:55:52.0 -0500
@@ -5,13 +5,9 @@
 #export DH_VERBOSE=1
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie
-DEB_BUILD_ARCH_OS := $(shell dpkg-architecture -qDEB_BUILD_ARCH_OS)
-DEB_BUILD_ARCH := $(shell dpkg-architecture -qDEB_BUILD_ARCH)
 DRIVERS= --enable-avalon \
  --enable-avalon2 \
- --enable-bab \
  --enable-bflsc \
- --enable-bitforce \
  --enable-bitfury \
  --enable-blockerupter \
  --enable-cointerra \
@@ -19,18 +15,7 @@
  --enable-hashfast \
  --enable-hashratio \
  --enable-icarus \
- --enable-klondike \
- --enable-minion \
- --enable-modminer
-
-ifeq ($(DEB_BUILD_ARCH_OS),linux)
-#   --enable-ants2 \ only one of ants1 or ants2 allowed
-DRIVERS+= --enable-ants1 \
-   --enable-bitmine_A1 \
-   --enable-knc \
-   --enable-sp10 \
-   --enable-sp30
-endif
+ --enable-klondike
 
 %:
 	dh $@ --with autoreconf
@@ -45,12 +30,11 @@
 $(shell dpkg-buildflags --get CPPFLAGS) \
 -I /usr/include/libusb-1.0/ -o cgminer-api
 
-
-#generates manpage, done during build since each arch has different config flags
+#generates manpage, make sure package is installed first
 MAN_NAME=multi-threaded multi-pool GPU, FPGA and CPU bitcoin miner.
-debian/cgminer.1:
-	help2man --no-discard-stderr --no-info --name=$(MAN_NAME) ./cgminer #for debugging bug #757381
-	help2man --no-discard-stderr --no-info --name=$(MAN_NAME) ./cgminer  debian/cgminer.1
+debian/cgminer.1: /usr/bin/cgminer
+	help2man --no-discard-stderr --no-info --name=$(MAN_NAME) $? #for debugging bug #757381
+	help2man --no-discard-stderr --no-info --name=$(MAN_NAME) $?  $@
 	perl \
  -E 's{\s+(It was generated by help2man)}{ $$1};   # correcting help2man comment'   \
  -E 's{^cgminer\s+[\d.]+$$}{$(MAN_NAME)};  # correcting DESCRIPTION section'\
@@ -60,9 +44,6 @@
  -E 's{(?:arg\s+|\s\s+|\\fR\s+(?!arg))\K}{\n}; # separate arguments and their descriptions' \
   -pi $@
 
-override_dh_installman: debian/cgminer.1
-	dh_installman
-
 override_dh_installchangelogs:
 	dh_installchangelogs NEWS
 

Bug#767719: [Pkg-bitcoin-devel] Bug#767719: cgminer: failed to connect to minergate service

[Scott Howard]

severity: important
thanks


On Sun, Nov 2, 2014 at 1:14 AM, Shawn L. Djernes sdjer...@gmail.com wrote:
 After reading the ReadMe from the upstream again, I found that their are
 modules that should not be built on anything but special systems. I
 removed all those --enable options from debian/rules and it seems to be
 stable.

We can update the package to only support:
--enable-avalon
--enable-avalon2
--enable-bflsc
--enable-bitfury
--enable-blockerupter
--enable-cointerra
--enable-drillbit
--enable-hashfast
--enable-hashratio
--enable-icarus
--enable-klondike

Do you know if this list is kept up-to-date? I wouldn't want to miss
out on supporting new hardware. Perhaps we can request a build option
--enable-distributable that will build all that make sense (or parse
README to extract the build flags that make sense).

Also, we will lose spondoolies support if we use the above list. If
helpful, we could build additional packages (e.g., cgminer-sp30) that
is configured with only one of the hardware configurations.

So, for jessie - what do you think of only using the above
configuration options exclusively?

~Scott


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

Bug#757381: [Pkg-bitcoin-devel] Bug#757381: cgminer: autobotched manpage

[Scott Howard]

On Thu, Aug 7, 2014 at 10:48 AM, Jaakko Niemi li...@debian.org wrote:
 Package: cgminer
 Version: 4.4.2-1
 Severity: normal

 Contents of manpage here:

 -
 .\ DO NOT MODIFY THIS FILE! It was generated by help2man 1.46.1.
 .TH LIBUSB_INIT() 1 July 2014 libusb_init() failed err -99 [2014-07-31 
 04:21:07] libusb_init() failed User Commands
 .SH NAME
 libusb_init() \- multi-threaded multi-pool GPU, FPGA and CPU bitcoin miner.
 .SH DESCRIPTION
 libusb_init() failed err \fB\-99\fR
 [2014\-07\-31 04:21:07] libusb_init() failed
 -

 Looks like help2man needs some verification features..

   --j

Thanks for pointing this out.

Since the build/manpage is different on each architecture, we need to
build the manpage at build time. However, libusb (and thus cgminer)
requires usb devices to be mounted, which the builds don't have. When
I build on my own machine, it's fine since I have usb devices.

A fix similar to this should work:
https://gitorious.org/bitcoin/bfgminer/commit/1a4cfde10e914437a7eed49dd4a215c31db58b62

I'll look into it, but if you want to give a fix a try please go
ahead. thanks again
~Scott


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

Bug#749157: [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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#754356: [Pkg-bitcoin-devel] Bug#754356: Missing build dependencies

[Scott Howard]

On Thu, Jul 10, 2014 at 5:21 AM, Vicente J. Ruiz Jurado
v...@ourproject.org wrote:
 Package: bitcoin-qt
 Version: 0.9.2

 Some build dependencies are missing: libboost-chrono-dev and imagemagick
 (because convert is used).

Thanks - libboost-chrono-dev is missing. Somehow it is getting pulled
in by something else, but it should be added as a BD.

I don't think we need imagemagick since the package doesn't use
convert but uses icotool instead:
http://anonscm.debian.org/gitweb/?p=collab-maint/bitcoin.git;a=blob;f=debian/rules
https://buildd.debian.org/status/fetch.php?pkg=bitcoinarch=armelver=0.9.2-1stamp=1402984161

~Scott


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749944: build ogre-1.9 against new boost-defaults 1.55?

[Scott Howard]

block 744171 by 749944
thanks

On Sun, Jun 1, 2014 at 12:29 PM, Manuel A. Fernandez Montecelo
manuel.montez...@gmail.com wrote: I don't know if I mention this to
them in the past.  It happened in a
 time when development was not very active and the old leader had to
 retire for some reason, I think.

 Since then, I submitted bugs that they fixed like inclusion of 3rd
 party library code, co-installability of different versions, support
 for new ports, etc.

 I will forward this to them hopefully soonish (but not now).  If
 somebody beats me to it, I will not complain! :-)


 Cheers and thanks for your help.

Thank you, sounds reasonable.
FYI: freeorion FTBFS too. Putting a block on the transition bug so it
shows up on their radar too.
https://buildd.debian.org/status/package.php?p=freeorion


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

Bug#749157: upstream patch for 749157, LIBUSB_CALL

[Scott Howard]

tags 749157 patch
thanks

Here's the patch from upstream:
http://svnweb.freebsd.org/base?view=revisionrevision=24

--- head/lib/libusb/libusb.h Sun May 25 18:06:28 2014 (r23)
+++ head/lib/libusb/libusb.h Sun May 25 18:06:32 2014 (r24)
@@ -33,6 +33,8 @@
 #include sys/types.h
 #endif

+#define LIBUSB_CALL
+
 #ifdef __cplusplus
 extern C {
 #endif


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

Bug#749944: build ogre-1.9 against new boost-defaults 1.55?

[Scott Howard]

Thanks for all the info, sorry to make you spend time rehashing this!

For my own sanity, I'll try to summarize the technical problem:
It looks like the troublesome functions are defined in headers [1], so
ogre gets the definitions hardcoded if it pulls in the headers. Those
functions are now statically included and may only be compatible with
a specific version of boost threads.

Because of this, programs can break since ogre is no longer binary
compatible after a binNMU that bumps boost.

The currently implemented fix solution is to define a build depends to
a specefic the version of boos. That prevents ogre from secretly
becoming binary incompatible with a binNMU, but it doesn't prevent it
from happening manually. For example, even if ogre depended on boost
1.47 explicitly, this bug would have happened when ogre was bumped to
1.48 manually. I think, technically, it seems the the libogre package
name should therefore have an indication of what boost version it was
compiled against since policy says that if a new version of a library
is not binary compatible with previous versions, it must have a name
change. libogre-1.9 might have to be libogre-1.9-b1.54, and then the
next version when compiled against boost 1.55 will be
libogre-1.9-b1.55. That is awkward, but it looks like the only way to
ensure binary compatibility.

Longer term, maybe someone should talk with ogre upstream and see what
they think of this. Should ogre be doing anything differently as to
not expose those boost functions without a compiler error that there
is a mismatch?

Maybe ogre is missing [2]:
#include boost/config/abi_prefix.hpp
or
#include boost/config.hpp
in [3]?

or something with:
http://www.boost.org/development/separate_compilation.html


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674633#31
[2] http://www.boost.org/doc/libs/1_55_0/boost/config/abi_prefix.hpp
[3] 
http://anonscm.debian.org/gitweb/?p=pkg-games/ogre-1.9.git;a=blob;f=OgreMain/include/Threading/OgreThreadHeadersBoost.h;hb=HEAD


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

Bug#749944: build ogre-1.9 against new boost-defaults 1.55?

[Scott Howard]

Source: ogre-1.9
Severity: wishlist

Hello,
Ogre-1.9 builds against boost 1.54. Debian just bumped boost-defaults to 1.55.
Is it possible to bump debian/control BDs such that it builds against
libboost-dev instead of libboost1.54-dev?

It will make future transitions easier. Thank you.

https://release.debian.org/transitions/html/boost1.55.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744171

~Scott


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

Bug#749944: build ogre-1.9 against new boost-defaults 1.55?

[Scott Howard]

reopen 749944

On Fri, May 30, 2014 at 7:50 PM, Manuel A. Fernandez Montecelo
manuel.montez...@gmail.com wrote:
 2014-05-31 0:18 GMT+01:00 Scott Howard showard...@gmail.com:
 On Fri, May 30, 2014 at 4:46 PM, Manuel A. Fernandez Montecelo
 manuel.montez...@gmail.com wrote:
 The versions are hardcoded to force reverse build-depends using the
 same versions, due to problems in the past (incompatibilities causing
 deadlocks when starting the application):

 Thank you for explaining. I'll update my package to follow ogre's
 hardcoded version of boost manually to prevent that bug from
 happening.

 Is that MyGui?

mygui and openmw.

I'm CC:ing Bret to this email, he's been maintaining them.

Bret: Ogre exposes the boost ABI, so to prevent situations where
previously compiled programs break when boost is bumped, ogre-1.9 is
hardcoded to a specefic library version.

Manuel, what do you think of this (please correct me if I'm wrong):
Since packages depending on ogre-1.9 are built against other libraries
that use boost-defaults, that causes them to FTBFS when the boost
transition occurs. Ogre-1.9 does not transition with the rest of the
archive. Packages really should depend on the version of boost in
boost-defaults otherwise the archive might become inconsistent (you
can see that 350 packages in the archive depend on boost, and ogre is
one one of 4 that do not depend on the default version defined by
boost-defaults). To keep the archive consistent and support the user
case defined in bug 674633 I propose
1) ogre-1.9 depend on libboost-dev
2) libogre-1.9-dev depend on: libboost-dev (which would pull in the
proper version and conflict for those users that are developing with
another library, addressing bug 674633).


Also:
But it takes a bit of time, disk space (several GBs) of which I don't
have much at the moment, and probably binNMUs to reverse dependencies
just in case that something like that bug happens again (ogre-1.9
compiled with 1.55 and rdeps having been compiled with 1.54 from the
previous versions forced by ogre-1.9 could cause a problem similar to
the previous bug).

That is what is supposed to happen when the whole archive transitions
to a new version of boost. If ogre had a BD on boost-defaults
(libboost*-dev), ogre and ogre's dependencies would have been binNMUed
by the team performing the transition. Instead, the whole archive
transitions, except ogre. Ogre's rdepends that also depend on either
libboost-default or any other library that depends on libboost-default
FTBFS and have to be removed from testing in order for the boost
transition to complete. This isn't very important now, since few
packages depend on ogre-1.9, but as the number of packages depending
on ogre-1.9 increase, it will become increasingly important to depend
on boost-defaults (libboost-dev).

The bug described in 674633 is unfortunate, it will never occur in a
stable release (were boost versions are not changing). I believe the
emphasis should be on maintaining archive consistency which will mean
users using unstable/testing as a development environment will break
on occasion. You can reduce the effects of that breakage by
build-depending on libboost-dev, thus forcing those users to also
upgrade their code/compilation to the new versions of boost as well.


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

Bug#749944: build ogre-1.9 against new boost-defaults 1.55?

[Scott Howard]

On Fri, May 30, 2014 at 9:06 PM, Scott Howard showard...@gmail.com wrote:
 You can reduce the effects of that breakage by
 build-depending on libboost-dev, thus forcing those users to also
 upgrade their code/compilation to the new versions of boost as well.

typo: you can reduce the effects of that breakage by having
libogre-1.9-dev DEPEND on libboost-dev, thus forcing those users to
also upgrade their code/compilation to the new versions of boost as
well.


update: 99.2% of the packages in the archive build against
boost-defaults (libboost-dev). Every library in the archive except one
builds against boost-defaults. The one that does not only compiles
against boost  1.54 and thus is manually set. They are probably going
to switch to libboost-dev now that debian is at 1.55. That means that
any package that depends on ogre-1.9 and also depends on any other
library that is an rdepends of boost will FTBFS.


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

Bug#749157: forwarded libusb.h LIBUSB_CALL request upstream

[Scott Howard]

forwarded 749157 http://www.freebsd.org/cgi/query-pr.cgi?pr=190204
thanks

Forwarded the bug to
http://www.freebsd.org/cgi/query-pr.cgi?pr=190204


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

Bug#749157: Please add an empty #define LIBUSB_CALL in libusb.h

[Scott Howard]

Package: freebsd-libs
Version: 10.0-5
Severity: normal
Tags: upstream

libusb should have ane empty #define LIBUSB_CALL
See:
http://libusb.sourceforge.net/api-1.0/group__misc.html#gaa7d6035eb2692d455d27144560a0f68d

This is implemented in libusb.h:
http://git.libusb.org/?p=libusb.git;a=blob;f=libusb/libusb.h;hb=7634714aa696175b08016b6f2185a75a2f55a113;js=1#l100

The lack of this #define is causing cgminer to FTBFS on kfreebsd*
https://buildd.debian.org/status/fetch.php?pkg=cgminerarch=kfreebsd-
amd64ver=4.3.3-2stamp=1400816257

usbutils.c:2687:25: error: expected '=', ',', ';', 'asm' or '__attribute__'
before 'transfer_callback'
 static void LIBUSB_CALL transfer_callback(struct libusb_transfer *transfer)

Probably should go upstream too. However, I'm not familiar with their bug
reporting policies. I also don't know which API version this should be in.

Thank you.



-- 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-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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#748799: ITP: dogecoin -- peer-to-peer network based anonymous digital currency

[Scott Howard]

On Tue, May 20, 2014 at 5:01 PM, Keng-Yu Lin ken...@lexical.tw wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Keng-Yu Lin ken...@lexical.tw

 * Package name: dogecoin
   Version : 1.7.0
   Upstream  :  Shibetoshi Nakamoto billym2k@gmail
 * URL : http://dogecoin.com/
 * License : MIT/X
   Programming Lang: C, C++
   Description : peer-to-peer network based anonymous digital currency

It's great that you're looking into dogecoin. Just be aware of the
problems with litecoin and bitcoin in the archive, namely that
upstream developers for those projects have concerns over how Debian
does stable releases. Network fixes can't be released/patched and
users end up with broken and potentially network damaging nodes.

Both litecoin and bitcoin cannot propagate to testing because of those
issues. I do not know about dogecoin's development, but if there are
similar concerns you should look into filing an RC bug against
dogecoin to prevent it from migrating to testing.

Also, there is a bitcoin packaging team (Debian Bitcoin Packaging Team
pkg-bitcoin-de...@lists.alioth.debian.org), you can maintain it
under that umbrella if you'd like so that others can help sponsor/bug
fix/update if you'd like them too.

Cheers,
Scott


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

Bug#731953: [Pkg-bitcoin-devel] Bug#731953: bitcoin: Package is allowed to build with too-new libdb, resulting in non-portability of wallets

[Scott Howard]

On May 15, 2014 7:09 PM, Brian May br...@microcomaustralia.com.au wrote:


 Hello,

 Is this bug still relevant?

 My understanding is that upstream switched from bdb to leveldb:
 https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki

The blockchain uses leveldb but the wallet still uses bdb. I remember some
talk about switching but nothing happened yet.

Cheers,
Scott

Bug#744029: [Pkg-bitcoin-devel] Bug#744029: Frightening message Do not shutdown on shutdown

[Scott Howard]

tags 744029 upstream
forwarded 744029 https://github.com/bitcoin/bitcoin/issues/4036
thanks

On Wed, Apr 9, 2014 at 9:32 AM, Jean-Michel Nirgal Vourgère
jmv_...@nirgal.com wrote:
 Using xfce, when I press logout then shutdown, bitcoin is poping up a
 window Do not shutdown this computer until that windows disapears.

 Maybe it only means Do not power off the computer... ?
 Then I suggest the message be fixed.

 If it really means do not shutdown, then it is weird to display that
 message every single time a shutdown starts. Does it mean I did not
 loose my wallet by pure luck, and that I should back it up every day?

Thanks for reporting and testing the package. Great report and catch.

This text comes from upstream, and has been forwarded to them
https://github.com/bitcoin/bitcoin/issues/4036

Cheers,
Scott


--
To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-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#452742: astyle: diff for NMU version 2.03-1.1

[Scott Howard]

On Tue, Mar 11, 2014 at 12:03 PM, Matteo Cypriani m...@lm7.fr wrote:
 Hi Scott,
 That looks good to me, thank you for your work. And sorry for not having taken
 care of this old bug before...

no problem, I'm happy to help

Regards,
Scott


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

Bug#452742: astyle: diff for NMU version 2.03-1.1

[Scott Howard]

tags 452742 + patch
tags 452742 + pending
thanks

Dear maintainer,

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

The changes are described in two patches:
1) 
http://anonscm.debian.org/gitweb/?p=collab-maint/astyle.git;a=commitdiff;h=6bef7b649a197f6714ee202f11ba12604331ac68
builds shared library

2) 
http://anonscm.debian.org/gitweb/?p=collab-maint/astyle.git;a=commitdiff;h=00aff422e4ec7d5afb4f372ae5987a7990499302
lintian cleaning, fixes several lintian errors

Regards.


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

Bug#737519: ftp.debian.org: cruft report does not show source packages with no binary packages

[Scott Howard]

this also happens to fgfs-base. All binary packages that used to be
built by fgfs-base have been taken over by flightgear-data. The
maintainer of flightgear-data, which has all the packages in testing,
cannot upload since he get's the DM's can't hijack packages error
after uploading even though he is the maintainer of every package that
is in testing.


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

Bug#734597: litecoin: Litecoin still builds with system LevelDB

[Scott Howard]

Hey Dmitry,

On Sun, Jan 19, 2014 at 10:34 PM, Dmitry Smirnov only...@debian.org wrote:
 Hi Scott,

 Thanks for the relevant links to the discussion that I wasn't aware of.

 On Thu, 9 Jan 2014 10:02:37 Scott Howard wrote:
 If you disagree, I'd be interested in hearing why.

 Mostly my decision is based on our policy. I'm convinced that
 discouraging linking to private libraries is one of the best practices
 that we have in Debian. No only it benefit security but also it helps
 to maintain coherent up-to-date distribution, encourage communication
 and cooperation between maintainers as well as compartmentalise
 development without unnecessary duplication.

I totally agree re: discouraging linking to private libraries as one
of the best practices in Debian. I spent a weekend, not too long ago,
pulling libtiff out of freeimage. I agree that long term, bitcoin
should use system libraries. I think upstream's (and my own personal)
opinion is that bitcoin protocol and network isn't evolved enough for
widespread stable releases using system libraries. For example, see
the current MtGox controversy where their implementation and the
satoshi implementation is clashing (there are no standards) [1]. That
has nothing to do with system libraries, but it illustrates the fact
that even the experts are having trouble understanding and predicting
the effects of changes to network implementation.

 I'd be interested to know if there are any additional steps to ensure
 its proper functioning.

I asked this of upstream too, at one point, and the response was that
there is nothing to ensure proper functioning yet. They can't make
tests for problems they don't know will come up because of changes to
things outside of their control (including modification of the
reference client, per [1]). The do know that such problems may be
catastrophic to the network (any loss of faith in the network can
cause the loss of billions of dollars). In my opinion, the risk does
not outweigh the reward - but as the network standardizes (note: there
is no bitcoin protocol specification: the satoshi reference client
*is* the protocol specification) and things such as blockchain
self-healing is studied and understood better. I think, at this point,
the whole bitcoin experiment is still fragile and is under rapid
development, I believe building with embedded libraries will help
nurture the experiment (and is one of the reasons it should not be in
testing yet). At some point, bitcoin will be mature enough to walk on
its own - and we can do the normal debian things: build with system
libraries, migrate to testing, updates to backports/jessie-updates,
etc.

At some point we should move to system libraries and help bitcoin
developers with the appropriate tests and mechanisms so they can trust
system libraries as well. I don't think we are at that point yet. When
we reach that point, we also will probably have safe enough packages
for inclusion in Debian and Ubuntu.

~Scott


[1] 
http://www.reddit.com/r/Bitcoin/comments/1x93tf/some_irc_chatter_about_what_is_going_on_at_mtgox/cf99yac


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

Bug#737676: RM: openscenegraph/3.0.1-4.1 -- RoQA; was already removed from testing

[Scott Howard]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Something odd is up with the openscenegraph package in testing. It was removed
from testing and is preventing migration to testing.

See:
http://packages.qa.debian.org/o/openscenegraph.html

1) openscenegraph was removed from testing on 2013-11-15
http://packages.qa.debian.org/o/openscenegraph/news/20131115T163918Z.html

2) Stable has version 3.0.1-4

3) Unstable has version 3.2.0~rc1-3

4) Testing migration is blocked because libopenscenegraph80 is out of date
(from 3.0.1-4.1). That version should not be in any release or testing, and the
new version of the library is libopenscenegraph99.
http://packages.qa.debian.org/o/openscenegraph/news/20131115T163918Z.html

I could be wrong, but it looks like libopenscenegraph80 was not properly
removed from testing, and it is now blocking the transition.

Thanks!


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

Bug#737676: RM: openscenegraph/3.0.1-4.1 -- RoQA; was already removed from testing

[Scott Howard]

reassign 737676 ftp.debian.org
usertag 737676 -rm
thanks

Nevermind re: testing, it was -4 removed from testing, then -4.1 was
uploaded to unstable.

libopenscenegraph80 binaries from openscenegraph/3.0.1-4.1 need to be
removed from unstable.
Moving this over to the ftp.debian.org package, instead of release.debian.org.

please remove libopenscenegraph80* from unstable.


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

Bug#736123: ITP: sbbi-upnplib -- Java library for universal plug and play (upnp)

[Scott Howard]

On Sun, Jan 19, 2014 at 10:43 PM, Jonathan Yu jaw...@cpan.org wrote:
 Does apt-get source expect the source package name, or will it also
 work with binary package names? If I do apt-get source libupnp-java,
 will it download the sbbi-upnplib package? If so, then this seems to
 be an especially trivial point, and I'd be happy with either name. In
 any case, since I'm not an expert here, let's see if someone on the
 debian-java list chimes in :-)

apt-get source does resolve source package names.
e.g., source package rxtx produces librxtx-java
$ sudo apt-get source librxtx-java
[sudo] password for showard:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Picking 'rxtx' as source package instead of 'librxtx-java'

Thanks all, I'll prepare an upload shortly
~Scott


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

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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#735775: retitle, builds on powerpc

[Scott Howard]

retitle 735775 RM: mygui [sparc] -- ROM; FTBFS
thanks

gcc-defaults now have gcc-4.8 for powerpc. ogre-1.9 now builds, which
means mygui now builds on powerpc.


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

Bug#736123: ITP: sbbi-upnplib -- Java library for universal plug and play (upnp)

[Scott Howard]

Package: wnpp
Severity: wishlist
Owner: Scott Howard show...@debian.org

* Package name: sbbi-upnplib
  Version : 1.0.4
  Upstream Author : SuperBonBon Industries
* URL :  http://sourceforge.net/p/triplea/code/HEAD/tree/upnp/
* License :  Apache-1.1
  Programming Lang: Java
  Description : Java library for universal plug and play (upnp)

This is a dependency of the newest versions of the triplea package. To be
maintained under the java team umbrella.
Initial repo:
http://anonscm.debian.org/gitweb/?p=pkg-java/sbbi-upnplib.git


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#736123: ITP: sbbi-upnplib -- Java library for universal plug and play (upnp)

[Scott Howard]

Hi all,
The binary package is named libupnp-java, seen here:
http://anonscm.debian.org/gitweb/?p=pkg-java/sbbi-upnplib.git;a=blob;f=debian/control;h=8014fb5b4d2c3eb60968caaa6c239562002dd9f7;hb=HEAD

I named the source package to match the name of the upstream tarball
file (sbbi-upnplib-1.0.4.tar.gz) I struggled with either naming the
source package the same as the binary package, or to name it like I
suggest here. Since upstream refers to the project as sbbi-upnplib and
their tarball had that in it, I'm leaning toward keeping the name what
they call it. It will be discoverable since the binary package has the
proper java library package name. I was worried about it not being
discoverable if I didn't put the sbbi-upnplib source package name.

Given that, do you still think it should be renamed? I don't mind either way.

~Scott

On Sun, Jan 19, 2014 at 8:50 PM, Jonathan Yu jaw...@cpan.org wrote:
 Hey Scott,

 I don't presume to be an expert here, but I wanted to mention that the
 package name specified in your ITP does not match the usual
 conventions for libraries in Debian, nor for Java libraries
 specifically:

 Java libraries packages must be named libXXX[version]-java (without
 the brackets) [0]

 Might you consider renaming this package to make it more easily discoverable?

 Cheers,

 Jonathan

 [0] http://www.debian.org/doc/packaging-manuals/java-policy/x104.html

 On Sun, Jan 19, 2014 at 5:33 PM, Scott Howard show...@debian.org wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Scott Howard show...@debian.org

 * Package name: sbbi-upnplib
   Version : 1.0.4
   Upstream Author : SuperBonBon Industries
 * URL :  http://sourceforge.net/p/triplea/code/HEAD/tree/upnp/
 * License :  Apache-1.1
   Programming Lang: Java
   Description : Java library for universal plug and play (upnp)

 This is a dependency of the newest versions of the triplea package. To be
 maintained under the java team umbrella.
 Initial repo:
 http://anonscm.debian.org/gitweb/?p=pkg-java/sbbi-upnplib.git


 --
 To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: 
 http://lists.debian.org/20140119223359.15198.7602.report...@esc-303123.ee.nd.edu



 --
 To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: 
 http://lists.debian.org/camdxsejlkidda__v6lfzbe+iaf0j5yocl6uoaongoq0rr3z...@mail.gmail.com



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

Bug#693673: new version of triplea Debian package

[Scott Howard]

Hello,

version 1.7+ requires the sbbi upnp java library. TripleA, however,
uses a different code base than upstream's code base - so the
triplea's version would have to be used. This could cause problems for
people that expect sbbi behavior but get triplea behavior.

Either way, upnp will need to be packaged to get the newest version of
triplea into Debian.

see:
http://tripleadev.1671093.n2.nabble.com/upnp-jar-questions-td7583613.html

~Scott


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

Bug#735775: RM: mygui [sparc powerpc] -- ROM; FTBFS

[Scott Howard]

Package: ftp.debian.org
Severity: normal

please remove sparc and powerpc builds of mygui from unstable.

mygui depended on ogre-1.8 which used to build on sparc and powerpc. Now it
depends on ogre-1.9 which does not build those architectures, so it is in an
indefinite BD-Uninstallable wait.

from [1], the ogre-1.9 maintainer wrote:
Reverse-depends can ask to remove old versions of packages from testing in
problematic arches to get their new version to migrate.  Virtually nobody will
be using OGRE or their packages in those arches anyway.

Thanks

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


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

Bug#735249: freeimage builds with bundled libtiff

[Scott Howard]

Package: freeimage
Version: 3.9.3-1
Severity: normal

freeimage's Source/FreeImage/PluginTIFF.cpp #includes tiffiop.h, which is a
private header file that should not be used to interface with a library. This
prevents us from using system tiff library.

See:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596076



-- 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-15-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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#734724: bossa arduino patches

[Scott Howard]

Thanks so much for your work!
I'll use your patches. Please send any more patches, and if you'd like
to help out with the the package (maintain, co-maintain, help when you
can) let me know too. I'll probably upload them when I start
incorporating bossa with arduino 1.5+
Cheers,
Scott


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

Bug#734597: [Pkg-bitcoin-devel] Bug#734597: litecoin: Litecoin still builds with system LevelDB

[Scott Howard]

On Wed, Jan 8, 2014 at 9:31 AM, Dmitry Smirnov only...@debian.org wrote:
 On Wed, 8 Jan 2014 23:22:37 Micha wrote:
 It would be better to change Litecoin to use the bundled LevelDB,
 for the same reason as that is already being done with Bitcoin.

 Actually I disagree that it would be better to use bundled LevelDB.

See:
https://docs.google.com/document/d/1naenR6N6fMWSpHM0f4jpQhYBEkCEQDbLBs8AXC19Y-o/edit#heading=h.i7tz3gqh65mi
and
http://sourceforge.net/mailarchive/message.php?msg_id=31207353
for detailed discussion and justification from upstream.

If you disagree, I'd be interested in hearing why.
Cheers,
Scott


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

Bug#733823: RFA: dxflib

[Scott Howard]

Package: wnpp
Severity: normal

This package used to be a dependency of LibreCAD and QCAD. QCAD has been
removed (but is now ok to be reintroduced if someone is interested), but
LibreCAD no longer uses this dependency, so I no longer have an interest nor
use this package.

This is maintained by Debian Science, so I am looking for someone to take over
being the responsible uploader of this package.


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

Bug#696715: closed by Scott Howard showard...@gmail.com (Closing bug 696715)

[Scott Howard]

On Tue, Dec 31, 2013 at 5:27 PM, Petter Reinholdtsen p...@hungry.com wrote:
 [Scott Howard]
 This bug is better handled upstream than in Debian.

 But that do not seem like a reason to close the bug in Debian, as the
 problem still exist in the Debian package.  I thought this kind of
 situation is what the 'forward' flag in the BTS was for?

How to use the BTS is at the discretion of the maintainer [1]. As
bitcoin gets more popular, we should use the Debian BTS for Debian
bugs and upstream's issue tracker for upstream bugs. Theoretically all
357 open upstream bugs also apply to Debian's package. Duplicating
them just because they exist in both isn't useful to either project.
Any patches done to bitcoin must be done very carefully, and the best
way is by upstream - so even if we could fix this in Debian, we
wouldn't want to until we can cherry pick the exact patch upstream
uses.

[1] https://wiki.debian.org/HowtoUseBTS


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

Bug#732724: mygui: Please upgrade OGRE dependency to 1.9 when upstream ready

[Scott Howard]

On Fri, Dec 20, 2013 at 1:11 PM,  manuel.montez...@gmail.com wrote:
 Source: mygui
 Severity: wishlist

 Hello,

 mygui depends on OGRE v1.8, which is discontinued and unsupported
 after 1.9.0 was released, and so it should not be present in future
 releases of Debian.

Thanks for the update. There's a package in the NEW queue (openmw)
that is built against mygui and ogre-1.8. Once it's cleared from NEW,
they can build against 1.9 and we can update mygui to 1.9.
I think, for now, that is my plan unless there is a precessing reason
why we should update sooner.

Cheers,
Scott


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#732066: [Pkg-bitcoin-devel] Bug#732066: can you please also package cgminer 3.7.2 (along with the latest version)?

[Scott Howard]

On Fri, Dec 13, 2013 at 9:04 AM, Ariel asdeb...@dsgml.com wrote:
 As you know CGMiner no longer works with GPUs or litecoin.

 Can you please add a second cgminer package? (Not as a replacement, as an 
 addition.) Perhaps call it cgminer-gpu or cgminer-old and package 
 specifically version 3.7.2.

Hello,
bfgminer is in the NEW queue, it's pending acceptance into Debian:
http://ftp-master.debian.org/new/bfgminer_3.6.0-1.html

Once bfgminer is in Debian, could you try it and see if that fits your
needs? You can find old packages here:
http://snapshot.debian.org/package/cgminer/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#731953: [Pkg-bitcoin-devel] Bug#731953: bitcoin: Package is allowed to build with too-new libdb, resulting in non-portability of wallets

[Scott Howard]

severity 731952 wishlist
tags 731952 wontfix
thanks

 In the bitcoin_0.8.6-1.dsc file, the Build-Depends: section includes the 
 entry libdb++-dev | libdb4.8++-dev. This results in the package potentially 
 being built with BDB version 5.1. The recommended version, and the one that 
 the upstream release binaries for all platforms (including Windows, OS X, and 
 Linux) are built with, is 4.8. BDB is used in the Bitcoin software for the 
 bitcoin wallet. BDB 5.1 databases are not backwards-compatible with BDB 4.8. 
 The result of this is any wallet.dat files that are created by, or even 
 opened with, a Bitcoin binary compiled with BDB 5.1, that wallet will become 
 incompatible with most other bitcoin binaries out there.

This text is well written and should be added to README.Debian and a
summary of this statement added to the package description.

Debian removed libdb4.8, so this is unfixable. The severity is minor
since this only shows up when you try to mix upstream and Debian
binaries. Additionally, you can work around it by importing/exporting
private keys to and from wallets of any version. You can open
wallet.dat with the client that created/modified it in order to export
keys.

Backing up wallet.dat is very important for this and many other reasons.


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

Bug#731189: ITP: jssc -- Library for working with serial ports from Java

[Scott Howard]

Package: wnpp
Severity: wishlist
Owner: Scott Howard show...@debian.org

* Package name: jssc
  Version : 2.6.0
  Upstream Author : scream3r@gmail.com
* URL : http://code.google.com/p/java-simple-serial-connector/
* License : LGPL-3+
  Programming Lang: Java
  Description : Library for working with serial ports from Java

This package replaces the dependency of librxtx-java in future version of
Arduino.


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

Bug#724804: Arduino bugs on debian BTS

[Scott Howard]

retitle 724804 raspbian package of arduino doesn't work with arduino micro
thanks

Thanks for the bug, I'm a little confused as to the problem you are
trying to report.

First, Debian doesn't support Raspbian (they are separate projects),
but it is possible that a bug in one is affecting the other so it's ok
to discuss it here.

I'm trying to figure out what you're reporting, is it:

*you have raspbian
* you have an arduino micro board

*micro on ttyACM0 is greyed out, but you still selected it?

Then the serial monitor crashes?

Question:
Why is arduino as ISP selected? Are you trying to program an AVR
chip using the arduino as an in circuit serial programmer?

Serial monitor crashing happens if the wrong serial port is selected,
there is permission problems, or rxtx can't find the serial device.

It sounds like there is something wrong with the serial port when you
connect? I can't follow what you're trying to say with the code.

I can develop Sketches in the IDE, Upload them to the Micro board,
and they do work.
So what is the bug you are reporting? Is it that the serial monitor is
crashing but everything else works?

It might be a bug with rxtx (the serial port library). Does arduino
from upstream work? Could you try the debian experimental packages
(version 1.5+)?

Regards,
Scott


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

Bug#725772: RFS: nfft -- Library for computing Non-uniform Fast Fourier Transforms

[Scott Howard]

On Tue, Oct 22, 2013 at 2:42 AM, Andreas Tille andr...@an3as.eu wrote:
  d/*.install:
The files are starting by a line #!/usr/bin/dh-exec   I admit
I have never seen this before even if I suspect this might be
somewhere in the docs which you have definitely read in a way more
recent version than me.  The line does not harm but to the best of
my knowledge you can safely remove it.

I just wanted to point out that line extends dh_install. From the manpage:

The purpose of the program is to extend dh_install(1)'s functionality,
 by allowing to specify a destination filename.

This can be accomplished by a special syntax: the  =  mark between a
source and a destination means that the source file should be installed
with the specified destination name.

Lintian is supposed to pick up on if you are using it superfluously
http://lintian.debian.org/tags/dh-exec-script-without-dh-exec-features.html


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

Bug#727232: won't remember saved contacts after exiting

[Scott Howard]

Package: electrum
Version: 1.8-1
Severity: important
Tags: upstream

Version 1.8 of electrum will not save contacts. If you add them and then exit
/re-open the client, the contacts are gone.

Version 1.8.1 fixes this (among others).

https://bugs.launchpad.net/ubuntu/+source/electrum/+bug/1233373



-- 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-12-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

Versions of packages electrum depends on:
ii  python   2.7.5-5ubuntu1
ii  python-electrum  1.8-1

electrum recommends no packages.

electrum suggests no packages.

-- no debconf information


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

Bug#727195: Bug#727194: ITP: OpenMW -- Reimplementation of The Elder Scrolls III: Morrowind game engine

[Scott Howard]

On Wed, Oct 23, 2013 at 1:25 PM, Stephen Kitt sk...@debian.org wrote:
 On Wed, 23 Oct 2013 19:22:12 +0200, Stephen Kitt sk...@debian.org wrote:
 Would you be interested in packaging this within the Games Team?

 Also, it would be great if game-data-packager could be enhanced to build a
 package for the data files (and we can help you with that).

(this should go on the new bug Jon just filed, but I can't find it yet)

I'd really like to see gdp support for openmw.

Bret is the upstream expert in packaging, I've just been helping him
make it policy compliant and navigate debian's resources. He knows the
issue better than me, but at least I'd appreciate help figuring out
how to use gdp.

Here's the situation:

game content is available from commercial CDs (several editions:
vanilla, game of the year edition, and there is are two expansions
tribunal bloodmoon) and also via steam (game of the year edition,
includes both expansions). I only have the vanilla version.

Originally, users either installed the game via wine and then pointed
openmw to the content or they used unshiled [1]. Recently, openmw's
launcher has added the capability to run the unshield scripts from the
launcher with the click of a button, making it much easier for users
to install content.

I don't know what is needed for gdp - but if that could help manage
content files, that would be great.

The openmw packaging is in pkg-games repo, and Bret is a member of the
games team.

~Scott

[1] http://wiki.openmw.org/index.php?title=Getting_Data_Files_for_Linux_Install


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

Bug#726060: RFP: adk2tool -- Android accessory development kit tools

[Scott Howard]

Package: wnpp
Severity: wishlist

* Package name: adk2tool
  Version : 2012.06.22
  Upstream Author : Copyright (C) 2012 The Android Open Source Project
* URL :  http://code.google.com/p/android-source-browsing
* License : ASL-2.0
  Programming Lang: C
  Description : Android accessory development kit tools

tools for installing and uploading code to android accessories. Useful for
programming arduino-powered android accessories.

http://code.google.com/p/android-source-browsing/source/browse/?repo=device--
google--accessory--adk2012r=297247f0e8f7011740031a0e2c7420fa99a3315e


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

Bug#726061: RFP: bossa -- Atmel SAM ARM microcontroller flash programming utility

[Scott Howard]

Package: wnpp
Severity: wishlist

* Package name: bossa
  Version : 1.2.1
  Upstream Author : ShumaTech http://www.shumatech.com/
* URL : http://www.shumatech.com/web/products/bossa
* License : GPL-3+
  Programming Lang: C++
  Description : Atmel SAM ARM microcontroller flash programming utility

BOSSA is a flash programming utility for Atmel's SAM family of flash-based ARM
microcontrollers.  The motivation behind BOSSA is to create a simple, easy-to-
use, open source utility to replace Atmel's SAM-BA software.


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

Bug#726062: arduino: doesn't support ADK or SAM ARM devices

[Scott Howard]

Package: arduino
Version: 1:1.5.4.2+dfsg-1
Severity: wishlist

to program ADK or SAM ARM devices (due), we need adk2tool and bossa
packaged in debian.


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

Bug#723929: arduino: Arduino IDe menu item does nothing when clicked arduino in termulator gives erro

[Scott Howard]

On Sat, Sep 21, 2013 at 7:09 AM, Andrew Atkinson a...@wotcc.org.uk wrote:
 Exception in thread main java.lang.ExceptionInInitializerError
 at processing.app.Preferences.setColor(Preferences.java:851)
 at processing.app.Preferences.init(Preferences.java:273)
 at processing.app.Base.main(Base.java:117)
 Caused by: java.awt.HeadlessException
 at
 sun.awt.HeadlessToolkit.getMenuShortcutKeyMask(HeadlessToolkit.java:237)
 at processing.core.PApplet.clinit(Unknown Source)
 ... 3 more


Thanks Andrew, to help us debug could you try the following and report
back with what happens?

1) what is the output of:

java -version

2) edit (as superuser) /usr/bin/arduino and change the last line from:

java -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel
processing.app.Base $@

to
java -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel
-Djava.awt.headless=true processing.app.Base $@

then try running the arduino command from the menu or command line

3) change the default JRE to openjdk

$ update-alternatives --config java

then try running arduino


I think it might have something to do with having both the sun and
openjdk jres installed.

~Scott


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

Bug#487388: [pkg-fgfs-crew] Bug#714260: Helping with flightgear package

[Scott Howard]

All the new packages have cleared the NEW queue and are in
experimental. Markus has been granted DM-upload access to those
packages and is a DM, so it looks like it's ready for him to upload to
experimental when it's ready.

Thanks for your contribution, Markus! If you need anything else, let me know.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#668505: dwarf fortress debian package

[Scott Howard]

On Tue, Sep 3, 2013 at 5:45 AM, Beren Minor
beren.minor+deb...@gmail.com wrote:
 BTW, I also have a GemRB package that requires sponsorship. I've
 recently joined the Debian Games Team to maintain it, but I have
 little time to chase sponsors. So, if you have some time to spend and
 want to have a look at it, it would be awesome. The sources of the
 package are in the pkg-games source repo [2].
 [2] http://anonscm.debian.org/gitweb/?p=pkg-games/gemrb.git;a=summary

Thanks for your work, here are some comments:

1) Changelog is confusing, there are multiple entries claiming upload
to unstable that has never been uploaded. The ITP bug is closed very
low on the list. Also, this is labeled as 0.8.0-3, but this is the
first upload to Debian. For the sake of clarity in the Debian archive,
I think you should reduce the debian/changelog to a single entry:
0.8.0-1, First packaging for Debian (Closes: #658887). (or close
which ever of the ITP bugs you want to close)

2) It appears that several of the packages depends on non-free data,
but it also appears that the engine can run free content. Is the
package usable without any content, or does it depend on non-free
content? (i.e., if a user downloads the package, will they be able to
do something with it out of the box)? I'm trying to see if this
should be in main or contrib. Looking at the upstream website, it
appears that the package should be contrib.

3) Lintian report:
I: gemrb: desktop-entry-lacks-keywords-entry
usr/share/applications/gemrb.desktop
I: libgemrb: hardening-no-fortify-functions usr/lib/gemrb/plugins/2DAImporter.so
I: libgemrb: hardening-no-fortify-functions usr/lib/gemrb/plugins/BAMImporter.so
I: libgemrb: hardening-no-fortify-functions usr/lib/gemrb/plugins/CREImporter.so
W: libgemrb: postinst-has-useless-call-to-ldconfig
W: libgemrb: postrm-has-useless-call-to-ldconfig

the first 4 are minor and can be fixed if you'd like to whenever you
get a chance.

The last two should be overridden for being a bug in debhelper.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=205142

4) the debian/control VCS-Git and VCS don't match the one you gave me
(http://anonscm.debian.org/gitweb/?p=pkg-games/gemrb.git;a=summary)

5) I was a little uneasy about the vvc files, they are binary blobs so
I was worried about where they came from (copyright and license), but
I found:
http://gemrb.org/iesdp/file_formats/ie_formats/vvc_v1.htm
I think it is ok, they seem to be from gemrb and not taken from
closed-source game content. You don't need to do anything about them.

Cheers,
Scott


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

Bug#588377: dwarf fortress debian package

[Scott Howard]

Hello Beren,
I'd like to check in to see the status of the package.The mentors link
is dead. Let me know if you're still interested in sponsorship.
~Scott


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

Bug#487388: [pkg-fgfs-crew] Bug#714260: Helping with flightgear package

[Scott Howard]

On Mon, Aug 19, 2013 at 10:50 AM, Markus Wanner mar...@bluegap.ch wrote:
 I'm a DM and would also appreciate upload permissions. Shall I add
 myself as an uploader on these packages?

Yes, please add yourself as an uploader. I can add DM permissions once
it goes through the new queue, but I think you're taking on the
appropriate responsibility to be an uploader.

I'll check out the packages and upload once you add yourself to debian/control.

Cheers
Scott


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

Bug#718892: thansk for arduino-mk NMU

[Scott Howard]

On Wed, Aug 14, 2013 at 10:58 AM, Scott Howard showard...@gmail.com wrote:
 Control: forwarded 718892 https://github.com/sudar/Arduino-Makefile/issues/115


 On Tue, Aug 13, 2013 at 3:22 PM, Bas Wijnen she...@fmf.nl wrote:
 Yes, I heard that it wouldn't be needed anymore.  However, the library
 dependency bug is still half-present: it doesn't crash on it anymore,
 but it doesn't track .cc, .hh and .hpp files for libraries.

 I forwarded it to:
 https://github.com/sudar/Arduino-Makefile/issues/115

reply from upstream:
they rewrote that section of the code since release 12, so that line
doesn't appear anymore:
https://github.com/sudar/Arduino-Makefile

Could you try upstream's master and see if that works? I think they're
still doing lots of rewrites now that the new development team is
taking over.

Cheers,
Scott


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

Bug#718892: thansk for arduino-mk NMU

[Scott Howard]

Control: forwarded 718892 https://github.com/sudar/Arduino-Makefile/issues/115


On Tue, Aug 13, 2013 at 3:22 PM, Bas Wijnen she...@fmf.nl wrote:
 Yes, I heard that it wouldn't be needed anymore.  However, the library
 dependency bug is still half-present: it doesn't crash on it anymore,
 but it doesn't track .cc, .hh and .hpp files for libraries.

I forwarded it to:
https://github.com/sudar/Arduino-Makefile/issues/115

If you ever want to do an upload or help co-maintain this, please do -
it's a team package so you could do a Team Upload (you don't need to
NMU). or add yourself to the unloaders, I appreciate the help.


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

Bug#487388: [pkg-fgfs-crew] Bug#714260: Helping with flightgear package

[Scott Howard]

On Sun, Aug 11, 2013 at 7:55 AM, Eddy Petrișor eddy.petri...@gmail.com wrote:
 2013/7/29 Scott Howard show...@debian.org:
 On Mon, Jul 29, 2013 at 8:43 AM, Markus Wanner mar...@bluegap.ch wrote:
 You can use it if it helps, or ignore it if it doesn't. It was mostly
 for my own use. I've been really busy lately and haven't gotten around
 to packaging and uploading newer versions.

 Scott, if the package is prepared by Markus, would you be able to
 upload it to the official archive?

I'll be happy to upload, just let me know when everything is ready
(flightgear, simgear, libraries, etc.)
I cannot test the package myself, my hardware isn't good enough - but
I can make sure it is debian policy compliant and rely on your own
testing.

~Scott


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