Bug#733823: RFA: dxflib
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 (Closing bug 696715)
On Tue, Dec 31, 2013 at 5:27 PM, Petter Reinholdtsen 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#737519: ftp.debian.org: cruft report does not show source packages with no binary packages
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#693673: new version of triplea Debian package
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: retitle, builds on powerpc
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)
Package: wnpp Severity: wishlist Owner: Scott Howard * 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
On Sun, Jan 19, 2014 at 8:18 PM, Julian Taylor 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)
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 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 wrote: >> Package: wnpp >> Severity: wishlist >> Owner: Scott Howard >> >> * 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#735847: closed by Scott Howard (Bug#735847: fixed in freeimage 3.15.4-3)
On Mon, Jan 20, 2014 at 7:26 PM, Julian Taylor 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#736123: ITP: sbbi-upnplib -- Java library for universal plug and play (upnp)
On Sun, Jan 19, 2014 at 10:43 PM, Jonathan Yu 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#737676: RM: openscenegraph/3.0.1-4.1 -- RoQA; was already removed from testing
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
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#734597: litecoin: Litecoin still builds with system LevelDB
Hey Dmitry, On Sun, Jan 19, 2014 at 10:34 PM, Dmitry Smirnov 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#731953: [Pkg-bitcoin-devel] Bug#731953: bitcoin: Package is allowed to build with too-new libdb, resulting in non-portability of wallets
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#732066: [Pkg-bitcoin-devel] Bug#732066: can you please also package cgminer 3.7.2 (along with the latest version)?
On Fri, Dec 13, 2013 at 9:04 AM, Ariel 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
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#718272: [Pkg-bitcoin-devel] Bug#718272: Bitcoin still not ready for stable release in Debian
On Sat, Dec 14, 2013 at 12:39 AM, Luke-Jr 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#732724: mygui: Please upgrade OGRE dependency to 1.9 when upstream ready
On Fri, Dec 20, 2013 at 1:11 PM, 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#727232: won't remember saved contacts after exiting
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
On Wed, Oct 23, 2013 at 1:25 PM, Stephen Kitt wrote: > On Wed, 23 Oct 2013 19:22:12 +0200, Stephen Kitt 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#725772: RFS: nfft -- Library for computing Non-uniform Fast Fourier Transforms
On Tue, Oct 22, 2013 at 2:42 AM, Andreas Tille 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#734597: [Pkg-bitcoin-devel] Bug#734597: litecoin: Litecoin still builds with system LevelDB
On Wed, Jan 8, 2014 at 9:31 AM, Dmitry Smirnov 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#734724: bossa arduino patches
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#735249: freeimage builds with bundled libtiff
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#735775: RM: mygui [sparc powerpc] -- ROM; FTBFS
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#724804: Arduino bugs on debian BTS
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#731189: ITP: jssc -- Library for working with serial ports from Java
Package: wnpp Severity: wishlist Owner: Scott Howard * 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#718272: [Pkg-bitcoin-devel] Bug#718272:
Thank you, Chris. I think you articulated the situation well and the options. On Wed, Jun 25, 2014 at 1:18 PM, Chris Bainbridge 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 you
Bug#718272: [Pkg-bitcoin-devel] Bug#718272:
On Wed, Jun 25, 2014 at 2:50 PM, Scott Howard 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:
On Wed, Jun 25, 2014 at 3:11 PM, Luke Dashjr wrote: > On Wednesday, June 25, 2014 6:53:57 PM Scott Howard wrote: >> On Wed, Jun 25, 2014 at 2:50 PM, Scott Howard 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#744029: [Pkg-bitcoin-devel] Bug#744029: Frightening message "Do not shutdown" on shutdown
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 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#452742: astyle: diff for NMU version 2.03-1.1
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#452742: astyle: diff for NMU version 2.03-1.1
On Tue, Mar 11, 2014 at 12:03 PM, Matteo Cypriani 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#743299: arduino: block migration to testing, jssc/bossac/libastylej validation
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#748799: ITP: dogecoin -- peer-to-peer network based anonymous digital currency
On Tue, May 20, 2014 at 5:01 PM, Keng-Yu Lin wrote: > Package: wnpp > Severity: wishlist > Owner: "Keng-Yu Lin" > > * Package name: dogecoin > Version : 1.7.0 > Upstream : Shibetoshi Nakamoto > * 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 ), 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#749157: Please add an empty #define LIBUSB_CALL in libusb.h
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=cgminer&arch=kfreebsd- amd64&ver=4.3.3-2&stamp=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#749157: forwarded libusb.h LIBUSB_CALL request upstream
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#749944: build ogre-1.9 against new boost-defaults 1.55?
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?
reopen 749944 On Fri, May 30, 2014 at 7:50 PM, Manuel A. Fernandez Montecelo wrote: > 2014-05-31 0:18 GMT+01:00 Scott Howard : >> On Fri, May 30, 2014 at 4:46 PM, Manuel A. Fernandez Montecelo >> 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?
On Fri, May 30, 2014 at 9:06 PM, Scott Howard 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#749944: build ogre-1.9 against new boost-defaults 1.55?
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 or #include 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#749157: upstream patch for 749157, LIBUSB_CALL
tags 749157 patch
thanks
Here's the patch from upstream:
http://svnweb.freebsd.org/base?view=revision&revision=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
#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?
block 744171 by 749944 thanks On Sun, Jun 1, 2014 at 12:29 PM, Manuel A. Fernandez Montecelo 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#731953: [Pkg-bitcoin-devel] Bug#731953: bitcoin: Package is allowed to build with too-new libdb, resulting in non-portability of wallets
On May 15, 2014 7:09 PM, "Brian May" 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#742418: astyle FTBFS on s390x: use -fPIC instead of -fpic when building shared libraries
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::ASStreamIterator, std::allocator > >' 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::ASStreamIterator, std::allocator > >::~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
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#698254: GCC 4.7 bug in WiFi.cpp
Package: arduino Version: 1.0.0-1 Submitter: Pascal de Bruijn Hi, I maintain the Gnoduino PPA for Ubuntu: https://launchpad.net/~pmjdebruijn/+archive/gnoduino-unstable While working on a package for Ubuntu Quantal (which has gcc 4.7), I noticed sketches which use WiFi.cpp seem to trigger a GCC bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50925 Apparently it can be worked around by passing -fno-caller-saves to avr-gcc and avr-g++. I haven't extensively tested any sketches (yet) using that fix, but at least the sketches compile again. While I haven't checked myself, it seems quite likely that Debian's Arduino package may be affected by this issue was well. I discovered this by building the ConnectWithWPA example. Regards, Pascal de Bruijn -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#476284: bullet package name/numbering
Hello, late to the party but wanted to put in a comment regarding library package naming/versioning. Please ignore this if it has already been discussed and i missed it in the thread) If your library belongs to a package that doesn't believe in sane SONAME version numbering, but instead releases based on version numbers that have nothing to do with binary compatibility, it is sometimes best to use the -release LDFLAG: >From the autotools book (but you can adjust it for whatever build system you want) [1] %-snip-% `-release' On occasion, it is desirable to encode the release number of a library into its name. By specifying the release number with this option, libtool will build a library that does this, but will break binary compatibility for each change of the release number. By breaking binary compatibility this way, you negate the possibility of fixing bugs in installed programs by installing an updated shared library. You should probably be using `-version-info' instead. libshell_la_LDFLAGS = -release 27 The above fragment might create a library called `libshell-27.so.0.0.0' for example. %-snip-% So, perhaps, libbulletcollision2.81 should really be: libbulletcollision-2.81.so.0.0.0 and package name "libbulletcollission-2.81" not "libbulletcollision2.81" (note the dash and number is in the name, the version will be appended on to it. This will, however, force everything to be rebuilt whenever upstream releases a new version. [1] http://www.sourceware.org/autobook/autobook/autobook_88.html#SEC88 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672524: [Pkg-bitcoin-devel] Bug#672524: bitcoin: FTBFS[any-i386]: testsuite errors
On Sat, Jan 19, 2013 at 3:52 PM, Petter Reinholdtsen wrote: > [Christoph Egger] >> We'll see as soon as it builds on the buildds I'd say. > > Still fail. I am unable to understand why: I can't reproduce this either in pbuilder, i386 sid. I'm forwarding this to the pkg-bitcoin ML to see if anyone there has any ideas. The test suites are failing to find *.json files on i386 and kfreebsd-i386 builds only. https://buildd.debian.org/status/package.php?p=bitcoin I can't debug it since I can't reproduce it. The error is: HOME="/build/buildd-bitcoin_0.7.2-2-i386-2MCUBL/bitcoin-0.7.2/debian/home" src/test_bitcoin Running 70 test cases... test/script_tests.cpp(106): error in "base58_EncodeBase58": Cound not find/open base58_encode_decode.json and a bunch more failures I have a wild guess, but would appreciate feedback. script_tests.cpp calls boost:filesystem:current_path(), which essentially reads in $PWD from the environment. Is it possible that the i386 buildds cleared the PWD variable prior to build? If so, we can append PWD=$(CURDIR) before invoking the test_script command. [1,2] Or better yet, compile while defining TEST_DATA_DIR (see [3]) so it doesn't depend on current_path() at all. I'm shooting in dark, but maybe we can get lucky. ~Scott [1] http://lintian.debian.org/tags/debian-rules-uses-pwd.html [2] http://www.boost.org/doc/libs/1_52_0/libs/filesystem/doc/reference.html#current_path [3] http://anonscm.debian.org/gitweb/?p=collab-maint/bitcoin.git;a=blob;f=src/test/script_tests.cpp;h=61d9a64eebb2dc3158386402250072ed0182cbe5;hb=HEAD#l94 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698705: miniupnpc uses MAXHOSTNAMELEN macro on hurd-i386
Package: miniupnpc Version: 1.5-2 The FTBFS is caused by MAXHOSTNAMELEN not being defined on Hurd. See [1] The simplest fix is to simply add: #ifndef MAXHOSTNAMELEN # define MAXHOSTNAMELEN 256 #endif but "the Hurd people recommend the code from libinetutils/localhost.c. [2]" Examples are in [1] and [3]. ~Scott [1] http://www.scsh.net/mail-archive/scsh-users/2003-06/msg1.html [2] http://www.gnu.org/software/inetutils/ [3] http://git.savannah.gnu.org/cgit/inetutils.git/tree/libinetutils/localhost.c -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672524: [Pkg-bitcoin-devel] Bug#672524: Bug#672524: bitcoin: FTBFS[any-i386]: testsuite errors
On Mon, Jan 21, 2013 at 10:17 PM, Scott Howard wrote: > On Sat, Jan 19, 2013 at 3:52 PM, Petter Reinholdtsen wrote: >> [Christoph Egger] >>> We'll see as soon as it builds on the buildds I'd say. >> >> Still fail. I am unable to understand why: > I have a wild guess, but would appreciate feedback. script_tests.cpp > calls boost:filesystem:current_path(), which essentially reads in $PWD > from the environment. Is it possible that the i386 buildds cleared the > PWD variable prior to build? If so, we can append PWD=$(CURDIR) before > invoking the test_script command. [1,2] Or better yet, compile while > defining TEST_DATA_DIR (see [3]) so it doesn't depend on > current_path() at all. Sorry, it looks like TEST_DATA_DIR is already defined properly. From the build log: g++ -c -DTEST_DATA_DIR=/build/buildd-bitcoin_0.7.2-2-i386-2MCUBL/bitcoin-0.7.2/src/test/data -DBOOST_TEST_DYN_LINK -O2 -pthread -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -g -DBOOST_SPIRIT_THREADSAFE -I/build/buildd-bitcoin_0.7.2-2-i386-2MCUBL/bitcoin-0.7.2/src -I/build/buildd-bitcoin_0.7.2-2-i386-2MCUBL/bitcoin-0.7.2/src/obj -DUSE_UPNP=0 -DUSE_IPV6=1 -DHAVE_BUILD_INFO -fno-stack-protector -fstack-protector-all -Wstack-protector -D_FORTIFY_SOURCE=2 -MMD -MF obj-test/script_tests.d -o obj-test/script_tests.o test/script_tests.cpp And it is properly set in the makefile.unix: TESTDEFS = -DTEST_DATA_DIR=$(abspath test/data) So I'm back to being stumped, the files it can't find are the location that is being passed. The location is correct. It can be built in pbuilder but failing on the buildds. ~Scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#476284: bullet package name/numbering
On Sat, Jan 26, 2013 at 10:05 AM, Markus Koschany wrote:
> Hi Scott and Vincent,
>
> thank you for your feedback. At the moment i see two alternatives
> (three if a static library is not a taboo)
Static is not taboo and can be included in -dev packages. Depending
maintainers, however, are strongly encouraged against using your
static package since it increases the burden of security and
maintenance. I think that you really should include .so to be useful
though.
> I'm using CMAKE as build system because it is better supported by
> upstream. I can achieve something similar to the autotools -release
> LDFLAG with
>
> SET_TARGET_PROPERTIES(
> BulletCollision
> PROPERTIES
> VERSION 2
> SOVERSION 2.8.1
> )
>
> although you can find the following lines in upstream's CMakelists.txt
> files:
>
> SET_TARGET_PROPERTIES(BulletCollision PROPERTIES VERSION ${BULLET_VERSION})
> SET_TARGET_PROPERTIES(BulletCollision PROPERTIES SOVERSION ${BULLET_VERSION})
Oh, well that helps - if the soversion is bumped every time then you
might be OK with upstream's build system as is (just enable shared
libraries).
> As Vincent has already said, the Release Team won't like the thought to
> make a transition every time a new Bullet version is released. But is
> this really so bad? I mean, there are only a few packages which would
> depend on Bullet like Blender, perhaps Supertuxkart and probably
> FreeOrion.
FYI: check out OpenMW, they're making good progress and may make it
into Debian in the future.
Although the release team might not like the transitions, I bet they
prefer it to statically linked code throughout the archive. You can
talk with them ahead of time to find ways of responsibly managing
transitions.
> So if i understand the choices correctly, only bumping the SONAME is a
> sane solution.
Yes, if SONAME is bumped with every release, then that is acceptable
and borderline "sane" (sane in that it avoids breakage, however it
also will trigger a large number of transitions). I'm used to projects
that either never set the SONAME or screw up the ABI but not bump
SONAME. This is a different case, where the project is bumping the
SONAME frequently.
> Provided the aforementioned assumption is true, is there really a difference
> between
>
> libbulletcollision-2.81 -> libbulletcollision-2.81.so.0.0.0
>
> libbulletcollision2.81 -> libbulletcollision.so.2.81
>
> ? In the end the name of the package has to change, correct?
Yes - both would be ok (although the first case might not have the
0.0.0, it would just be libbulletcollision-2.81.so or the package name
would have to be libbulletcollision-2.81-0). That's all I wanted, was
to make sure the package name changes.
To get really confused, see the SDL packages
libsdl1.2debian0 -> libSDL-1.2.so.0.11.4 (Lintian says should be libsdl-1.2-0)
libsdl-1.3-0 -> libSDL-1.3.so.0.0.0
libsdl2-2.0-0 -> libSDL2-2.0.so.0.0.0
> I will also talk to the Multimedia Team who maintains Blender at the
> moment, perhaps they know best what kind of library they need and which
> approach is successful in the end.
Yes, please talk with those that would build with it - their opinions
count a lot
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#487388: helping with flightgear package in Debian
Hi Ove, I can help out with flightgear, I've been looking at it and did some initial work. Some of it, at the least, was an exercise for me in trying out some stuff I haven't done before. If you don't like it, I have no problem rolling it back. Most "invasive" is listed first 1) Moved the VCS to git rationale: The SVN repo has the entire upstream source included, we might as well be using git-buildpackage to check in the source and pristine-tar deltas (and thus tagging upstream releases) makes rebuilding of any .orig.tar.gz of any release easy. Many Debian SVN repos have been moving in this direction, I think it is a good way to go. I kept SVN's history and imported the tags. http://anonscm.debian.org/gitweb/?p=collab-maint/flightgear.git I can put it in pkg-fgfs if you'd like, I'll have to join the team first. Having it in collab-maint also makes it easier for others to commit if you'd like to keep it there too. 2) Simplified debian rules to short dh style. In order to future-proof building and make rules more readable, I cleaned the packaging up. 3) Lots of lintian cleaning, removed 20+ warnings, about 10 still remain. Most were fixed by switching to dh rules. In the process of hardening the binaries I bumped the debian/compat to 9. There still is more lintian cleaning to go. TODO: get-orig-source target. Somehow the upstream tarball is screwed up (lots of warnings when building the package) and there is no definitive way of grabbing upstream source. the watch file is working, so use uscan to download current version and rename/repack at least. new upstream source: will fix the security bug Let me know if this is helpful or if any of these are out-of-bounds. I'd like to keep working in this direction and possible update simgear and fgfs-base similarly. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#695928: [eagle] unable to run: error loading libssl.so.0.9.8
On Fri, Dec 14, 2012 at 8:31 AM, Arthur Magill wrote: > Package: eagle > Version: 5.10.0-2 > Severity: grave > > --- Please enter the report below this line. --- > > Until this week, I have been happily running Eagle. Clearly something > changed with a recent upgrade. When I try to start Eagle, I see the > following: > > $ eagle > /home/magill/.eagle/bin/eagle: error while loading shared libraries: > libssl.so.0.9.8: wrong ELF class: ELFCLASS64 It seems that the problem came about because your system is using Wheezy multiarched ia32-libs but Squeeze non-multiarched eagle. Eagle is a 32 bit binary, and should only be using the 32 bit libraries (even on amd64 systems). The squeeze version of Eagle is looking for the 32 bit libssl: /usr/lib32/i486/libssl.so.0.9.8 and is included in package ia32-libs in squeeze. However, you have a version of ia32-libs installed from Wheezy. Wheezy introduced multiarch, which allowed 32 and 64 bit libraries to be co-installed. Eagle, a 32 bit binary, depends on 32 bit libraries. Since you've already upgraded to ia32-libs from Wheezy, you either have to downgrade it to the squeeze version to get the library back or install a multiarched version of eagle: $ dpkg --add-architecture i386 $ apt-get update $ apt-get install eagle:i386 -t unstable More information is here: http://wiki.debian.org/Multiarch fixing this is going to come down to getting the right versions of different packages working together (either all from squeeze or all from wheezy, mixing won't work). Cheers, Scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#696262: bitcoin FTBFS: tests fail assuming a RW $HOME
Package: src:bitcoin Version: 0.7.2-1 Severity: serious Tags: sid Justification: fails to build from source (but built successfully in the past) Several build failures on multiple archs because buildd machines don't have writable /home/buildd. This affects test suites. Exact failure: Test setup error: std::runtime_error: boost::filesystem::create_directory: No such file or directory: "/home/buildd/.bitcoin" -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689325: arduino: Ethernet Library Dns getHostByName doesn't work
On Tue, Oct 2, 2012 at 4:48 AM, Francesco Apollonio wrote: > Ok, I tried to copy all directories (arduino-1.0.1/libraries and > arduino-1.0.1/hardware/arduino) from the archive downloaded from arduino > website to the system path (/usr/share/arduino) reverting your modified > files. > > After that I tried to compile my code with the IDE installed by the debian > package and It works and the gethostbyname returns the right address. > > Maybe do we need only to revert the modified files? Thanks, can you try to compile the webserver and webclient Ethernet examples too? A user had trouble with them previously and asked to apply the patches from the blog posted above. However, I have a feeling it may be that the patch just takes advantage of some compiler optimizations and is not essential to the library's compilation. If it works without the patches, I'll revert the Ethernet library patches. Thanks again! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#690790: unblock: arduino/1:1.0.1+dfsg-7
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package arduino One of the libraries for the Arduino hardware platform did not work with the new version of avr-gcc that was bumped right before freeze. This fixes the bug. diff: http://anonscm.debian.org/gitweb/?p=collab- maint/arduino.git;a=commitdiff;h=63ebe2d261f38169ac77b8589ac208c37fc36b40 unblock arduino/1:1.0.1+dfsg-7 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.1.0-1-486 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689325: arduino: Ethernet Library Dns getHostByName doesn't work
On Mon, Oct 1, 2012 at 11:50 AM, Pietrofrancesco Apollonio wrote: > Package: arduino > Version: 1:1.0.1+dfsg-6 > Severity: important > > Dear Maintainer, > I was tring to compile a simple code to make a translation from the hostname > to > an IP address using the Arduino IDE (and libraries) included in debian sid: Thanks for the careful debugging. Long story short, the original Ethernet library has some hacks in it that don't work with the the new compiler in Debian (gcc 4.7). We patched the code so that the ipaddress class is the union of address.a8 and address.a32 depending if you wanted uint8_t or uint32_t returned. I'd really appreciate it if you could help me out since I don't have the hardware: in /usr/share/arduino/libraries/Ethernet/Dns.cpp find and replace: aResult[segment] with aResult.a8[segment] There are two occurrences of aResult[segment] that will need to be replaced with aResult.a8[segment]. Thanks for your help - it's a bit annoying now while Debian and Arduino's packages have a different toolchain, but hopefully our work with the new toolchain can pass back patches to Arduino to help them when they go to port. And in the meantime, Debian package users would have more optimized binaries on their arduinos (smaller/faster). [1] andybrown.me.uk/wk/2012/04/28/avr-gcc-4-7-0-and-avr-libc-1-8-0-compiled-for-windows/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689325: arduino: Ethernet Library Dns getHostByName doesn't work
On Mon, Oct 1, 2012 at 1:06 PM, Scott Howard wrote: > in /usr/share/arduino/libraries/Ethernet/Dns.cpp > > find and replace: > aResult[segment] > > with > > aResult.a8[segment] > > > There are two occurrences of aResult[segment] that will need to be > replaced with aResult.a8[segment]. That won't work - somewhere else in the DNS code it is looking for the uint8_t IP address using the old method. I'll keep hunting for it, if you get a chance and find it, 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#689325: arduino: Ethernet Library Dns getHostByName doesn't work
On Mon, Oct 1, 2012 at 3:11 PM, Francesco Apollonio wrote: > What are the toolchains that differ from the original arduino package? > I tried to use the original package from the website and it works well. > > So I'll be happy to help you to fix this package. > > Francesco Wonderful! Mainly, Arduino website uses avr-gcc 4.3.2, and Debian's avr-gcc is 4.7.0 [1]. Here is the patch we applied to the arduino libraries: http://patch-tracker.debian.org/patch/series/view/arduino/1:1.0.1+dfsg-6/gcc47_avr.patch It might also be good to contact the patch's author, Andy Brown, at [2]. He could probably help wrap his mind around it. [1] http://packages.debian.org/sid/gcc-avr [2] andybrown.me.uk/wk/2012/04/28/avr-gcc-4-7-0-and-avr-libc-1-8-0-compiled-for-windows/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689917: bitcoind in Debian
In response to the bug comment: "http://bitcoin.org/releases/2012/10/19/v0.7.1.html > This is a minor bug-fix release. My best guess would be that #688813 (grave) is addressed this new upstream version. What is blocking the new release? As far as I can see bitcoind will not be part of wheezy, so there is no point in waiting. On the other hand just uploading the new release should fix a number of issues. Helmut" I think part of the reason there isn't an updated release is that Debian's Berkley DB library is newer than the stock one from upstream, so wallet.dat made in debian are not compatible with upstream's "stock" precompiled binary, and vice versa. This is dangerousness for users that might expect to just be able to transfer their wallets between machines easily. They are moving away from BDB and towards leveldb, so this may fix itself soon. @Jonas @Micah, if you'd like someone to help work on the package, let me know. ~Scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684748: [arduino] unable to use ethernet library
On Mon, Aug 13, 2012 at 10:40 AM, Marco Righi wrote:
> Package: arduino
> Version: 1:1.0.1+dfsg-4
> Severity: grave
>
> --- Please enter the report below this line. ---
> Hi,
> I try to compile the Arduino example
>
> #include
> #include
>
> // the media access control (ethernet hardware) address for the shield:
> byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
> //the IP address for the shield:
> byte ip[] = { 10, 0, 0, 177 };
>
> void setup()
> {
> Ethernet.begin(mac, ip);
> }
>
> void loop () {}
>
> that I copy from
>
> http://arduino.cc/en/Reference/EthernetBegin
>
> I patched it adding the line
>
> #include
>
> Using the Arduino compiler under VirtualBOX I compile successfully the
> code meanwhile using the Debian package I got the followings errors:
It looks like a problem with gcc 4.7.0 that Debian recently switched
to [1, 2]. Debian Arduino is using the patches from here [3]. Hakan,
could you look at bugs.debian.org/684748 and see if anything simple
jumps out at you with this error? Source is here [4]. I'm travelling
and can't look too closely at it. Thank you!
Cheers,
Scott
[1] http://packages.qa.debian.org/g/gcc-avr.html
[2] http://arduino.cc/forum/index.php?topic=116542.0
[3]
http://andybrown.me.uk/wk/2012/04/28/avr-gcc-4-7-0-and-avr-libc-1-8-0-compiled-for-windows/
[4]
http://anonscm.debian.org/gitweb/?p=collab-maint/arduino.git;a=tree;f=libraries/Ethernet;h=e638934e692b79aaf75a49311684cc45593fb8e9;hb=HEAD
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684748: [arduino] unable to use ethernet library
On Mon, Aug 13, 2012 at 11:20 AM, Scott Howard wrote: >> Using the Arduino compiler under VirtualBOX I compile successfully the >> code meanwhile using the Debian package I got the followings errors: > > It looks like a problem with gcc 4.7.0 that Debian recently switched > to [1, 2]. Debian Arduino is using the patches from here [3]. Hakan, > could you look at bugs.debian.org/684748 and see if anything simple > jumps out at you with this error? Source is here [4]. I'm travelling > and can't look too closely at it. Thank you! > > Cheers, > Scott it's related to the change to IPAddress.h, that was changed because of gcc 4.7. We also will have to upate W5100*. i posted a comment at [1] agreeing with a poster that has a similar problem. It call comes down to the fact that IPAddress.h and .cpp: "Poor code quality here. The 4-octet class member is forcibly type-punned to an incompatible type in several places. This hack forces gcc to disable an entire class of optimisations. The new compiler automatically enables strict-aliasing when size optimisations are selected so we get told about this. The fix is to declare the 4-octet member as a union so it can be used in a type-safe manner." [1] http://andybrown.me.uk/wk/2012/04/28/avr-gcc-4-7-0-and-avr-libc-1-8-0-compiled-for-windows/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684748: Arduino Ethernet library fix, needs testing
On Fri, Aug 17, 2012 at 1:08 PM, Marco Righi wrote:
> Hi,
> I am sorry but this change is not enougth.
>
> If I try to compile (I attach the modified file) I got a segmentation
> error or segmentation fault (the displayed error is "[Errore di
> segmentazione]").
>
> collect2: error: ld terminated with signal 11 [Errore di segmentazione]
Thanks for testing. I am unable to compile with the current unstable
package on debian wheezy, but I copied your file you emailed and it
compiles without the segfault [1]. I compile both the code you posted
and the "WebClient" example without any errors.
I forwarded the patch upstream to the original author of the arduino
library port to gcc 4.7. I can't see which version of gcc-avr you are
using, but segfaults sometimes fall as a problem with ld. For now, I
guess we can just make sure we have an updated toolchain and see if it
was some configuration error.
[1]
{clean install of arduino}
showard@debian-testing:~$ arduino
{attempt to compile web client example}
/usr/share/arduino/libraries/Ethernet/Ethernet.cpp: In member function
‘void EthernetClass::begin(uint8_t*, IPAddress, IPAddress, IPAddress,
IPAddress)’:
/usr/share/arduino/libraries/Ethernet/Ethernet.cpp:64:39: error: no
matching function for call to
‘W5100Class::setIPAddress(IPAddress::&)’
/usr/share/arduino/libraries/Ethernet/Ethernet.cpp:64:39: note: candidate is:
In file included from /usr/share/arduino/libraries/Ethernet/Ethernet.cpp:1:0:
/usr/share/arduino/libraries/Ethernet/utility/w5100.h:392:6: note:
void W5100Class::setIPAddress(uint8_t*)
/usr/share/arduino/libraries/Ethernet/utility/w5100.h:392:6: note:
no known conversion for argument 1 from ‘IPAddress::’
to ‘uint8_t* {aka unsigned char*}’
/usr/share/arduino/libraries/Ethernet/Ethernet.cpp:65:38: error: no
matching function for call to
‘W5100Class::setGatewayIp(IPAddress::&)’
/usr/share/arduino/libraries/Ethernet/Ethernet.cpp:65:38: note: candidate is:
In file included from /usr/share/arduino/libraries/Ethernet/Ethernet.cpp:1:0:
/usr/share/arduino/libraries/Ethernet/utility/w5100.h:368:6: note:
void W5100Class::setGatewayIp(uint8_t*)
/usr/share/arduino/libraries/Ethernet/utility/w5100.h:368:6: note:
no known conversion for argument 1 from ‘IPAddress::’
to ‘uint8_t* {aka unsigned char*}’
/usr/share/arduino/libraries/Ethernet/Ethernet.cpp:66:38: error: no
matching function for call to
‘W5100Class::setSubnetMask(IPAddress::&)’
/usr/share/arduino/libraries/Ethernet/Ethernet.cpp:66:38: note: candidate is:
In file included from /usr/share/arduino/libraries/Ethernet/Ethernet.cpp:1:0:
/usr/share/arduino/libraries/Ethernet/utility/w5100.h:376:6: note:
void W5100Class::setSubnetMask(uint8_t*)
/usr/share/arduino/libraries/Ethernet/utility/w5100.h:376:6: note:
no known conversion for argument 1 from ‘IPAddress::’
to ‘uint8_t* {aka unsigned char*}’
{copy the new Ethernet.cpp file}
showard@debian-testing:~$ sudo cp ~/Downloads/Ethernet.cpp
/usr/share/arduino/libraries/Ethernet/Ethernet.cpp
showard@debian-testing:~$ arduino
{attempt to compile web client example}
Binary sketch size: 12,004 bytes (of a 32,256 byte maximum)
{success}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684748: Arduino Ethernet library fix, needs testing
On Sat, Aug 18, 2012 at 3:32 AM, Marco Righi wrote: > do you ask about this? > > Command 36 of 1 $avr-gcc --verbose > Using built-in specs. > COLLECT_GCC=avr-gcc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.7.0/lto-wrapper > Target: avr > Configured with: ../src/configure -v --enable-languages=c,c++ > --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man > --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared > --with-system-zlib --enable-long-long --enable-nls > --without-included-gettext --disable-libssp --build=x86_64-linux-gnu > --host=x86_64-linux-gnu --target=avr > Thread model: single > gcc version 4.7.0 (GCC) thanks, helps a lot (looks right...) - i'll keep looking at it -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684748: Arduino Ethernet library fix, needs testing
On Sat, Aug 18, 2012 at 7:29 AM, Scott Howard wrote: > On Sat, Aug 18, 2012 at 3:32 AM, Marco Righi wrote: >> do you ask about this? >> >> Command 36 of 1 $avr-gcc --verbose >> Using built-in specs. >> COLLECT_GCC=avr-gcc >> COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.7.0/lto-wrapper >> Target: avr >> Configured with: ../src/configure -v --enable-languages=c,c++ >> --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man >> --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared >> --with-system-zlib --enable-long-long --enable-nls >> --without-included-gettext --disable-libssp --build=x86_64-linux-gnu >> --host=x86_64-linux-gnu --target=avr >> Thread model: single >> gcc version 4.7.0 (GCC) > > thanks, helps a lot (looks right...) - i'll keep looking at it Sorry to bug you again, but could you try the Ethernet.cpp file you sent me in a 32 bit VM (or machine if you have one)? I think it may be a bug in the 64 bit ld. Also, can you post the output of "$ avr-ld --version" ? Cheers, Scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684748: Arduino Ethernet library fix, needs testing
On Wed, Aug 22, 2012 at 3:46 AM, Marco Righi wrote: > Hi Scott, > you are welcome. I use Debian 64 bit. > > Command 37 of 4 $avr-ld --version > GNU ld (GNU Binutils) 2.20.1.20100303 > Copyright 2009 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms of > the GNU General Public License version 3 or (at your option) a later > version. > This program has absolutely no warranty. > > Please contact me if you think I can help you. I am glad to help the > Debian develop. > > Marco Thanks - could you try compiling the ethernet code with the fixed "Ethernet.cpp" file on a 32 bit machine (or virtual machine)? I have it working on 32 bit machines here but don't have an AMD64 to test, so if you can confirm that it compiles ok on 32 bit (like mine does) but doesn't on 64 bit, then we know we fixed one bug and are now working on a different one in avr-ld. Cheers, Scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684748: Arduino Ethernet library fix, needs testing
On Thu, Aug 23, 2012 at 11:18 AM, Marco Righi wrote: > Hi Scott, > I have installed the last version of Debian ISO in a Virtual box and the > Arduino environment (after your .a8 patch) compiles with success the > Ethernet code! Great - was that the 32 bit or 64 bit virtual box? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#685799: unblock: arduino/1:1.0.1+dfsg-6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package arduino Two changes since Wheezy version: 1) translation fix (French "copy" was mis-translated) [1] 2) some code FTBFS due to avr-gcc was bumped to 4.7 [2] [1] http://anonscm.debian.org/gitweb/?p=collab- maint/arduino.git;a=commitdiff;h=c070f9545b3fd243bf4880ffa082f97b70426403 [2] http://anonscm.debian.org/gitweb/?p=collab- maint/arduino.git;a=commitdiff;h=070d27864263c1712ab9f0f3d90c714557880d1f unblock arduino/1:1.0.1+dfsg-6 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683021: Help with bug 683021
tags 683021 help thanks I've been playing with the code, trying to massage it to compile on arm* with no luck. If anyone else can help, I'd appreciate it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#654162: Fwd: arduino makefile for 1.0
-- Forwarded message -- From: Martin Oldfield Date: Wed, Jan 11, 2012 at 7:25 AM Subject: arduino makefile for 1.0 To: Craig Hollabaugh , Scott Howard Cc: m...@mjo.tc Gentlemen, Sorry to be slow to reply: $WORK's New Year backlog has proved time-consuming. I've not had a chance to look at the 1.0 Arduino stuff, but some kind person has sent me some patches about it. I'll try to test them by next week. If you've got more free tuits and want to seize the baton, please let me know. Cheers, -- M. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#647161:
notfound 647161 5.0.3-1+b1 thanks closing per reporter's comments -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#444813: qtiplot can open file not in folder
fixed 444813 0.9.8.8-2 thanks I just checked the most recent qtiplot, and it is at least fixed in that version. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#656565: ITP: openstereograph -- Open source stereograph ("Magic Eye") generator for desktops
X-Debbugs-Cc: debian-de...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Scott Howard
* Package name: openstereograph
Version : 0.1+20080921
Upstream Author : Gustavo de Farias
* URL : http://code.google.com/p/openstereogram
* License : BSD-2-clause
Programming Lang: Java
Description : Stereogram ("Magic Eye") generator with GUI
A desktop application written in Java to generate autostereograph, made
popular through the book "Magic Eye." Users create images which appear to
pop out in 3D when looked at cross-eyed or wall-eyed (parallel vision).
A different project, stereograph, is packaged in Debian but is much older
and without a GUI. Stereograph has been orphaned. OpenStereograph will
supersede stereograph and be under the maintenance of debian-science.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#659259: [Pkg-gmagick-im-team] Bug#659259: imagemagick: "convert" falls back to /usr/bin/rsvg which is removed upstream, potential for mass FTBFSes
On Thu, Feb 9, 2012 at 11:11 AM, roucaries bastien wrote: > Reading more the good solution is to use rsvg-convert instead of rsvg > script in delegate. Patch welcome. Attached is commit 6793 to imagemagick's svn [1]. I removed parts where they bumped rev numbers and release dates. This isn't a problem until librsvg is > 2.35.2. [1] http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=20315&sid=440fef1dfc20179228d76a46c9b2935b imagemagick_rsvg-convert_svn6793.diff Description: Binary data
Bug#659259: [Pkg-gmagick-im-team] Bug#659259: imagemagick: "convert" falls back to /usr/bin/rsvg which is removed upstream, potential for mass FTBFSes
On Fri, Feb 10, 2012 at 10:41 AM, Scott Howard wrote: > On Thu, Feb 9, 2012 at 11:11 AM, roucaries bastien > wrote: >> Reading more the good solution is to use rsvg-convert instead of rsvg >> script in delegate. Patch welcome. > > Attached is commit 6793 to imagemagick's svn [1]. I removed parts > where they bumped rev numbers and release dates. This isn't a problem > until librsvg is > 2.35.2. here's a better patch, at the right level for debian packaging and un-reversed... 0006-rsvg-convert.patch Description: Binary data
Bug#652089: Bug#679467: eagle: Please consider packaging EAGLE 6.x
forcemerge 652089 679467 thanks On Thu, Jun 28, 2012 at 6:24 PM, Fernando J. Rodríguez wrote: > Package: eagle > Version: 5.10.0-2 > Severity: wishlist > > Dear maintainers: > The version of EAGLE in the archive is 5.12.0, but upstream's latest version > is 6.2, > released on 2012-04-12. [1] Thanks, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652089 and: http://www.element14.com/community/thread/17738 The big problem is that libpng14 will never be in Debian (or any other major distro except OpenSUSE) and eagle requires libpng14. I, and many others, have tried to see if Cadsoft would comment on or change that - and their position has been that it's illegal for them to statically link or distribute libpng14 (which doesn't make sense since it uses quite an open and free license). Debian libpng maintainers aren't interested in introducing and maintaining an older version of png, so unless someone else packages it we cannot distribute eagle 6. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#658645: scidavis: diff for NMU version 0.2.4-3.1
Package: scidavis
Version: 0.2.4-3
Severity: normal
Tags: patch pending
Dear maintainer,
I've prepared an NMU for scidavis (versioned as 0.2.4-3.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards.
diff -Nru scidavis-0.2.4/debian/changelog scidavis-0.2.4/debian/changelog
--- scidavis-0.2.4/debian/changelog 2011-03-16 20:40:52.0 -0400
+++ scidavis-0.2.4/debian/changelog 2012-02-04 15:28:54.0 -0500
@@ -1,3 +1,17 @@
+scidavis (0.2.4-3.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Added --parallel flag to dh in debian/rules
+ * Move plugins to /usr/lib (Closes: #646190)
+debian/patches/lib64.diff
+ * Fixed declaring Graph as const when it is not (Closes: #655776)
+debian/patches/graph_const.diff
+ * Recommends on qt-assistant-compat (Closes: #624752)
+ * use dh_python2 since python-support is deprecated (cleaning up
+lintian error)
+
+ -- Scott Howard Sat, 04 Feb 2012 15:28:22 -0500
+
scidavis (0.2.4-3) unstable; urgency=low
* Add Build-Depends on libqtassistantclient-dev (Closes: #618199)
diff -Nru scidavis-0.2.4/debian/control scidavis-0.2.4/debian/control
--- scidavis-0.2.4/debian/control 2011-03-16 18:33:56.0 -0400
+++ scidavis-0.2.4/debian/control 2012-02-04 15:25:30.0 -0500
@@ -5,14 +5,15 @@
Build-Depends: debhelper (>= 7.0.50~), docbook-to-man, python,
pyqt4-dev-tools, libqt4-dev, libqt4-opengl-dev, libqwt5-qt4-dev,
libqwtplot3d-qt4-dev, libmuparser-dev, libgsl0-dev, zlib1g-dev,
- libglu1-mesa-dev, python-dev, python-qt4-dev, python-sip-dev,
- python-support, libqtassistantclient-dev
+ libglu1-mesa-dev, python-dev (>> 2.6.6-3~), python-qt4-dev, python-sip-dev,
+ libqtassistantclient-dev
Standards-Version: 3.9.1
Homepage: http://scidavis.sourceforge.net/
Package: scidavis
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}
+Recommends: qt-assistant-compat
Description: application for scientific data analysis and visualization
SciDAVis is a free interactive application aimed at data analysis and
publication-quality plotting. It combines a shallow learning curve and
diff -Nru scidavis-0.2.4/debian/patches/graph_const.diff
scidavis-0.2.4/debian/patches/graph_const.diff
--- scidavis-0.2.4/debian/patches/graph_const.diff 1969-12-31
19:00:00.0 -0500
+++ scidavis-0.2.4/debian/patches/graph_const.diff 2012-02-04
15:30:47.0 -0500
@@ -0,0 +1,25 @@
+Description: remove const qualifier from variables that are not
+Author: Scott Howard
+Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655776
+Index: scidavis-0.2.4/scidavis/src/scidavis.sip
+===
+--- scidavis-0.2.4.orig/scidavis/src/scidavis.sip 2012-02-04
15:14:55.700694486 -0500
scidavis-0.2.4/scidavis/src/scidavis.sip 2012-02-04 15:15:41.352695571
-0500
+@@ -926,7 +926,7 @@
+ void removeCurve(const QString&);
+ void deleteFitCurves();
+ int curves() /PyName=numCurves/;
+- QList curves() const /NoDerived/;
++ QList curves() /NoDerived/;
+ %MethodCode
+ sipRes = new QList();
+ for (int i = 0; icurves(); i++)
+@@ -995,7 +995,7 @@
+ sipRes = sipCpp->d_plot->canvas();
+ %End
+
+- QPointF pickPoint() const /NoDerived/;
++ QPointF pickPoint() /NoDerived/;
+ %MethodCode
+ ApplicationWindow *app = sipscidavis_app();
+ sipRes = new QPointF();
diff -Nru scidavis-0.2.4/debian/patches/lib65.diff
scidavis-0.2.4/debian/patches/lib65.diff
--- scidavis-0.2.4/debian/patches/lib65.diff1969-12-31 19:00:00.0
-0500
+++ scidavis-0.2.4/debian/patches/lib65.diff2012-02-04 15:31:39.0
-0500
@@ -0,0 +1,16 @@
+Description: Don't install modules to /usr/lib
+Author: Scott Howard
+Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646190
+Index: scidavis-0.2.4/scidavis/scidavis.pro
+===
+--- scidavis-0.2.4.orig/scidavis/scidavis.pro 2012-02-04 14:43:54.884650261
-0500
scidavis-0.2.4/scidavis/scidavis.pro 2012-02-04 14:44:11.640650659
-0500
+@@ -30,7 +30,7 @@
+ }
+
+ ### 64 Linux only suffix
+-linux-g++-64: libsuff = 64
++#linux-g++-64: libsuff = 64
+
+ ### where to install
+ unix: INSTALLBASE = /usr # this is what is called "prefix" when
using GNU autotools
diff -Nru scidavis-0.2.4/debian/patches/series
scidavis-0.2.4/debian/patches/series
--- scidavis-0.2.4/debian/patches/series2011-03-16 19:02:30.0
-0400
+++ scidavis-0.2.4/debian/patches/series2012-02-04 15:09:08.0
-0500
@@ -1,2 +1,4 @@
sourcefiles_pri.diff
scidavis_pro.diff
+lib65.diff
+graph_const.diff
diff -Nru scidavis-0.2.4/debian/pycompat scidavis-0.2.4/debian/pycompat
--- scidavis-0.2.4/debian/pycompat 2010-03-26 13:27:38.0 -0400
+++ s
Bug#658644: scidavis: diff for NMU version 0.2.4-3.1
Package: scidavis
Version: 0.2.4-3
Severity: normal
Tags: patch pending
Dear maintainer,
I've prepared an NMU for scidavis (versioned as 0.2.4-3.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards.
diff -Nru scidavis-0.2.4/debian/changelog scidavis-0.2.4/debian/changelog
--- scidavis-0.2.4/debian/changelog 2011-03-16 20:40:52.0 -0400
+++ scidavis-0.2.4/debian/changelog 2012-02-04 15:28:54.0 -0500
@@ -1,3 +1,17 @@
+scidavis (0.2.4-3.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Added --parallel flag to dh in debian/rules
+ * Move plugins to /usr/lib (Closes: #646190)
+debian/patches/lib64.diff
+ * Fixed declaring Graph as const when it is not (Closes: #655776)
+debian/patches/graph_const.diff
+ * Recommends on qt-assistant-compat (Closes: #624752)
+ * use dh_python2 since python-support is deprecated (cleaning up
+lintian error)
+
+ -- Scott Howard Sat, 04 Feb 2012 15:28:22 -0500
+
scidavis (0.2.4-3) unstable; urgency=low
* Add Build-Depends on libqtassistantclient-dev (Closes: #618199)
diff -Nru scidavis-0.2.4/debian/control scidavis-0.2.4/debian/control
--- scidavis-0.2.4/debian/control 2011-03-16 18:33:56.0 -0400
+++ scidavis-0.2.4/debian/control 2012-02-04 15:25:30.0 -0500
@@ -5,14 +5,15 @@
Build-Depends: debhelper (>= 7.0.50~), docbook-to-man, python,
pyqt4-dev-tools, libqt4-dev, libqt4-opengl-dev, libqwt5-qt4-dev,
libqwtplot3d-qt4-dev, libmuparser-dev, libgsl0-dev, zlib1g-dev,
- libglu1-mesa-dev, python-dev, python-qt4-dev, python-sip-dev,
- python-support, libqtassistantclient-dev
+ libglu1-mesa-dev, python-dev (>> 2.6.6-3~), python-qt4-dev, python-sip-dev,
+ libqtassistantclient-dev
Standards-Version: 3.9.1
Homepage: http://scidavis.sourceforge.net/
Package: scidavis
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}
+Recommends: qt-assistant-compat
Description: application for scientific data analysis and visualization
SciDAVis is a free interactive application aimed at data analysis and
publication-quality plotting. It combines a shallow learning curve and
diff -Nru scidavis-0.2.4/debian/patches/graph_const.diff
scidavis-0.2.4/debian/patches/graph_const.diff
--- scidavis-0.2.4/debian/patches/graph_const.diff 1969-12-31
19:00:00.0 -0500
+++ scidavis-0.2.4/debian/patches/graph_const.diff 2012-02-04
15:30:47.0 -0500
@@ -0,0 +1,25 @@
+Description: remove const qualifier from variables that are not
+Author: Scott Howard
+Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655776
+Index: scidavis-0.2.4/scidavis/src/scidavis.sip
+===
+--- scidavis-0.2.4.orig/scidavis/src/scidavis.sip 2012-02-04
15:14:55.700694486 -0500
scidavis-0.2.4/scidavis/src/scidavis.sip 2012-02-04 15:15:41.352695571
-0500
+@@ -926,7 +926,7 @@
+ void removeCurve(const QString&);
+ void deleteFitCurves();
+ int curves() /PyName=numCurves/;
+- QList curves() const /NoDerived/;
++ QList curves() /NoDerived/;
+ %MethodCode
+ sipRes = new QList();
+ for (int i = 0; icurves(); i++)
+@@ -995,7 +995,7 @@
+ sipRes = sipCpp->d_plot->canvas();
+ %End
+
+- QPointF pickPoint() const /NoDerived/;
++ QPointF pickPoint() /NoDerived/;
+ %MethodCode
+ ApplicationWindow *app = sipscidavis_app();
+ sipRes = new QPointF();
diff -Nru scidavis-0.2.4/debian/patches/lib65.diff
scidavis-0.2.4/debian/patches/lib65.diff
--- scidavis-0.2.4/debian/patches/lib65.diff1969-12-31 19:00:00.0
-0500
+++ scidavis-0.2.4/debian/patches/lib65.diff2012-02-04 15:31:39.0
-0500
@@ -0,0 +1,16 @@
+Description: Don't install modules to /usr/lib
+Author: Scott Howard
+Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646190
+Index: scidavis-0.2.4/scidavis/scidavis.pro
+===
+--- scidavis-0.2.4.orig/scidavis/scidavis.pro 2012-02-04 14:43:54.884650261
-0500
scidavis-0.2.4/scidavis/scidavis.pro 2012-02-04 14:44:11.640650659
-0500
+@@ -30,7 +30,7 @@
+ }
+
+ ### 64 Linux only suffix
+-linux-g++-64: libsuff = 64
++#linux-g++-64: libsuff = 64
+
+ ### where to install
+ unix: INSTALLBASE = /usr # this is what is called "prefix" when
using GNU autotools
diff -Nru scidavis-0.2.4/debian/patches/series
scidavis-0.2.4/debian/patches/series
--- scidavis-0.2.4/debian/patches/series2011-03-16 19:02:30.0
-0400
+++ scidavis-0.2.4/debian/patches/series2012-02-04 15:09:08.0
-0500
@@ -1,2 +1,4 @@
sourcefiles_pri.diff
scidavis_pro.diff
+lib65.diff
+graph_const.diff
diff -Nru scidavis-0.2.4/debian/pycompat scidavis-0.2.4/debian/pycompat
--- scidavis-0.2.4/debian/pycompat 2010-03-26 13:27:38.0 -0400
+++ s
Bug#658644: response re:NMU for 658644
Hi Jacob: * Scott Howard , 2012-02-04, 15:37: >+scidavis (0.2.4-3.1) unstable; urgency=high >+ >+ * Non-maintainer upload. >+ * Added --parallel flag to dh in debian/rules >This is not appropriate for an NMU. This and the other changes that are not normally good for NMU is because I was overstepping my bounds a bit since I have a prior relationship with the maintainer (we co-maintain librecad and qcad). I know his been busy and a little bit out of it, so I thought I could do him a favor for now. I'll happy to shrink it down to the minimum for now and work with to do a non-NMU for the rest of this stuff later. >+ * use dh_python2 since python-support is deprecated (cleaning up >+lintian error) >This is not appropriate for an NMU. For now I have no problem shrinking it down and taking care of the rest at a later time. Would adding a dependency on python-support (to fix the lintian error) be appropriate in this NMU or should I stick to just RC bugs? >--- scidavis-0.2.4/debian/patches/lib65.diff1969-12-31 19:00:00.0 >-0500 >+++ scidavis-0.2.4/debian/patches/lib65.diff2012-02-04 15:31:39.0 >-0500 >s/65/64/? yes >@@ -0,0 +1,16 @@ >+Description: Don't install modules to /usr/lib >Huh. I hope this is just a typo in the description. The bug report asked for something quite opposite. typo, it's actually in /usr/lib, changed from /usr/lib64 >Also, would you care to justify such short delay[0] and urgency=high? Fixing two RC bugs that are older than 7 days, thus the short delay and high urgency. from devref §5.11.1 and [1] [1] http://upsilon.cc/~zack/hacking/debian/rcbw/ I'll cancel the deferred upload and do another one now that is just the RC bugs and tell Reuben about the other stuff later. ~Scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#624752: scidavis: diff for NMU version 0.2.4-3.1
tags 624752 + patch
tags 624752 + pending
tags 646190 + patch
tags 646190 + pending
tags 655776 + patch
tags 655776 + pending
tags 658644 + patch
tags 658644 + pending
thanks
Hello again,
I only really care about those bugs (especially the RC ones)
so I've stripped it down to just handle bugs.
I've prepared an NMU for scidavis (versioned as 0.2.4-3.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.
Regards.
diff -Nru scidavis-0.2.4/debian/changelog scidavis-0.2.4/debian/changelog
--- scidavis-0.2.4/debian/changelog 2011-03-16 20:40:52.0 -0400
+++ scidavis-0.2.4/debian/changelog 2012-02-07 12:15:31.0 -0500
@@ -1,3 +1,14 @@
+scidavis (0.2.4-3.1) unstable; urgency=low
+
+ * Non-maintainer upload. (Closes: #658644)
+ * Move plugins to /usr/lib (Closes: #646190)
+debian/patches/lib64.diff
+ * Fixed declaring Graph as const when it is not (Closes: #655776)
+debian/patches/graph_const.diff
+ * Recommends on qt-assistant-compat (Closes: #624752)
+
+ -- Scott Howard Tue, 07 Feb 2012 12:14:34 -0500
+
scidavis (0.2.4-3) unstable; urgency=low
* Add Build-Depends on libqtassistantclient-dev (Closes: #618199)
diff -Nru scidavis-0.2.4/debian/control scidavis-0.2.4/debian/control
--- scidavis-0.2.4/debian/control 2011-03-16 18:33:56.0 -0400
+++ scidavis-0.2.4/debian/control 2012-02-07 12:17:00.0 -0500
@@ -13,6 +13,7 @@
Package: scidavis
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
+Recommends: qt-assistant-compat
Description: application for scientific data analysis and visualization
SciDAVis is a free interactive application aimed at data analysis and
publication-quality plotting. It combines a shallow learning curve and
diff -Nru scidavis-0.2.4/debian/patches/graph_const.diff
scidavis-0.2.4/debian/patches/graph_const.diff
--- scidavis-0.2.4/debian/patches/graph_const.diff 1969-12-31
19:00:00.0 -0500
+++ scidavis-0.2.4/debian/patches/graph_const.diff 2012-02-04
15:30:47.0 -0500
@@ -0,0 +1,25 @@
+Description: remove const qualifier from variables that are not
+Author: Scott Howard
+Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655776
+Index: scidavis-0.2.4/scidavis/src/scidavis.sip
+===
+--- scidavis-0.2.4.orig/scidavis/src/scidavis.sip 2012-02-04
15:14:55.700694486 -0500
scidavis-0.2.4/scidavis/src/scidavis.sip 2012-02-04 15:15:41.352695571
-0500
+@@ -926,7 +926,7 @@
+ void removeCurve(const QString&);
+ void deleteFitCurves();
+ int curves() /PyName=numCurves/;
+- QList curves() const /NoDerived/;
++ QList curves() /NoDerived/;
+ %MethodCode
+ sipRes = new QList();
+ for (int i = 0; icurves(); i++)
+@@ -995,7 +995,7 @@
+ sipRes = sipCpp->d_plot->canvas();
+ %End
+
+- QPointF pickPoint() const /NoDerived/;
++ QPointF pickPoint() /NoDerived/;
+ %MethodCode
+ ApplicationWindow *app = sipscidavis_app();
+ sipRes = new QPointF();
diff -Nru scidavis-0.2.4/debian/patches/lib64.diff
scidavis-0.2.4/debian/patches/lib64.diff
--- scidavis-0.2.4/debian/patches/lib64.diff1969-12-31 19:00:00.0
-0500
+++ scidavis-0.2.4/debian/patches/lib64.diff2012-02-06 00:53:53.0
-0500
@@ -0,0 +1,16 @@
+Description: Install plugins in /usr/lib instead of /usr/lib64
+Author: Scott Howard
+Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646190
+Index: scidavis-0.2.4/scidavis/scidavis.pro
+===
+--- scidavis-0.2.4.orig/scidavis/scidavis.pro 2012-02-04 14:43:54.884650261
-0500
scidavis-0.2.4/scidavis/scidavis.pro 2012-02-04 14:44:11.640650659
-0500
+@@ -30,7 +30,7 @@
+ }
+
+ ### 64 Linux only suffix
+-linux-g++-64: libsuff = 64
++#linux-g++-64: libsuff = 64
+
+ ### where to install
+ unix: INSTALLBASE = /usr # this is what is called "prefix" when
using GNU autotools
diff -Nru scidavis-0.2.4/debian/patches/series
scidavis-0.2.4/debian/patches/series
--- scidavis-0.2.4/debian/patches/series2011-03-16 19:02:30.0
-0400
+++ scidavis-0.2.4/debian/patches/series2012-02-06 00:51:07.0
-0500
@@ -1,2 +1,4 @@
sourcefiles_pri.diff
scidavis_pro.diff
+lib64.diff
+graph_const.diff
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#659259: imagemagick: "convert" falls back to /usr/bin/rsvg which is removed upstream, potential for mass FTBFSes
Package: imagemagick Severity: wishlist This is a heads up about a pending problem coming down the pipe. imagemagick's "convert" command for svg files uses an internal converter found in libmagickcore?-extra, which is recommended by imagemagick. However, the buildds do not install recommends, so it falls back to /usr/bin/rsvg to act as the converter. Many packages convert upstream's svg icon to a pixmap for debian menus (.xpm per the menu policy) rsvg upstream has removed /usr/bin/rsvg from their latest release, so builds will fail when /usr/bin/convert no longer can find /usr/bin/rsvg. "convert" will also fail on user systems that have librsvg2-bin installed and not the recommended package libmagickcore?-extra. Would it be possible to have a virtual package: libmagickcore-extra which is provided by the current SONAME of libmagickcore?-extra? This way we can depend on that and don't need to bump our build dependencies for this internal library that we don't interface. Alternatively, would it be possible to bump libmagickcore?-extra to a "depends" level relationship? If I want to convert svg files, and I don't have "Recommends:" installed by default, I could be confused as to why it doesn't just work and not easily figure out I need the libmagickcore3-extra package. I found this when the package I maintain in Debian suddenly FTBFS on ubuntu: https://launchpadlibrarian.net/92231198/buildlog_ubuntu-precise-i386.librecad_1.0.0%2Bnolibs-1_FAILEDTOBUILD.txt.gz and the imagemagick bug I filed in ubuntu: https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/929573 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#659259: [Pkg-gmagick-im-team] Bug#659259: imagemagick: "convert" falls back to /usr/bin/rsvg which is removed upstream, potential for mass FTBFSes
On Thu, Feb 9, 2012 at 11:11 AM, roucaries bastien wrote: > Reading more the good solution is to use rsvg-convert instead of rsvg > script in delegate. Patch welcome. > > And please fill a bug to libsrvg in order to get a man page for rsvg-convert. > > Thanks ok - I'll take a look at making a patch for that later. It seems like rsvg and rsvg-convert take the same arguments, but I haven't looked closely enough (and lack of manpage...) ~Scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#659259: imagemagick: "convert" falls back to /usr/bin/rsvg which is removed upstream, potential for mass FTBFSes
On Thu, Feb 9, 2012 at 11:28 AM, Jakub Wilk wrote: > * Scott Howard , 2012-02-09, 10:58: > >> Would it be possible to have a virtual package: libmagickcore-extra which >> is provided by the current SONAME of libmagickcore?-extra? > > > Do you mean this? > | $ apt-cache showpkg libmagickcore-extra > | Package: libmagickcore-extra > | Versions: > | > | Reverse Depends: > | Dependencies: > | Provides: > | Reverse Provides: > | libmagickcore4-extra 8:6.6.9.7-5+b2 > > Though it's not provided by libmagickcore5-extra anymore. I don't know why, > it's not mentioned in the changelog. > > (But it's not like this solution is very robust...) Thanks! that will do it for now. I'll look into the rsvg patch too anyways, someone needs to do it sometime... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681535: [qtiplot] qtiplot crahes on startup with siplib error message
Package: qtiplot Version: 0.9.8.8-5+b1 Followup-For: Bug #681535 I've been unable to reproduce the crash on i386. It seems we have the same python-sip version. I can also get older versions of qtiplot plot to work with the old python-sip as well. Have you tried this on a non-AMD64 machine? Perhaps that's the problem (I don't have any to test at the momemt) -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.1.0-1-486 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 qtiplot depends on: ii libalglib-2.6.0 2.6.0-6 ii libc6 2.13-34 ii libgcc1 1:4.6.2-12 ii libgl1-mesa-glx [libgl1] 7.11.2-1 ii libgl2ps0 1.3.6-1 ii libglu1-mesa [libglu1]8.0.3-1 ii libgsl0ldbl 1.15+dfsg-1 ii libmuparser2 2.1.0-3 ii liborigin2-1 2:20110117-1+b1 ii libpng12-01.2.49-2 ii libpython2.7 2.7.3-2 ii libqt4-network4:4.7.4-2 ii libqt4-opengl 4:4.7.4-2 ii libqt4-qt3support 4:4.7.4-2 ii libqt4-svg4:4.7.4-2 ii libqt4-xml4:4.7.4-2 ii libqtassistantclient4 4.6.3-3 ii libqtcore44:4.7.4-2 ii libqtexengine10.3-3 ii libqtgui4 4:4.7.4-2 ii libstdc++64.6.2-12 ii libtamuanova-0.2 0.2-2 ii python2.7.3-1 ii python-qt44.9.1-1 ii python-sip4.13.3-2 ii zlib1g1:1.2.7.dfsg-13 Versions of packages qtiplot recommends: ii qt-assistant-compat 4.6.3-3 ii qtiplot-doc 0.9.8.8-5 qtiplot 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#652089: Update with eagle and precompiled libraries
Version 6.2.1: - Linux: libpng and libjpeg directly linked into the executable to get rid of dependency and availability of according system libs. Looks like we can get eagle 6 in debian soon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#686173: ld segfaults when linking uncomforming ELF
On Thu, Aug 30, 2012 at 7:03 AM, Hakan Ardo wrote: > Thanx! > I'm uploading a new version binutils-avr with this patch. Please > verify that it solves the problem. Verified on a wheezy machine, thanks Hakan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#686533: RM: fparser/4.5-0.1 -- RoM; RC Buggy, no more rdepends
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove fparser (source) from unstable. Binary packages are libfparser- dev, libfparser-4.3, libfparser-4.3-dbg. The Debian packages that depended on it now use the muparser library, and fparser has become difficult to maintain with gcc-4.7. Upstream doesn't believe in shared libraries, so we've been maintiaing that build system. It's gotten too much to worry about for Wheezy, it's best to remove it for now. No rdepends anymore. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.1.0-1-486 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#686577: RM: fparser -- ROM; RC buggy, no more rdepends
Package: ftp.debian.org Severity: normal please remove fparser from unstable. It is RC buggy, the packages that depended on it have switched to muparser, and upstream doesn't believe in shared libraries so we've been maintaining the build system which is now giving us problems. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#685799: arduino migrated to testing already
arduino migrated to testing already http://packages.qa.debian.org/a/arduino/news/20120904T163915Z.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683021: fparser removed from archive
fparser removed from archive See: http://packages.qa.debian.org/f/fparser/news/20120904T152959Z.html We believe that the bug you reported is now fixed; the following package(s) have been removed from unstable: fparser | 4.3-4 | source fparser |4.5-0.1 | source libfparser-4.3 | 4.3-4 | armel, armhf libfparser-4.3 |4.5-0.1 | amd64, hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc libfparser-4.3-dbg | 4.3-4 | armel, armhf libfparser-4.3-dbg |4.5-0.1 | amd64, hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc libfparser-dev | 4.3-4 | armel, armhf libfparser-dev |4.5-0.1 | amd64, hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc --- Reason --- ROM; RC buggy, no more rdepends -- Note that the package(s) have simply been removed from the tag database and may (or may not) still be in the pool; this is not a bug. The package(s) will be physically removed automatically when no suite references them (and in the case of source, when no binary references it). Please also remember that the changes have been done on the master archive and will not propagate to any mirrors (ftp.debian.org included) until the next dinstall run at the earliest. Packages are usually not removed from testing by hand. Testing tracks unstable and will automatically remove packages which were removed from unstable when removing them from testing causes no dependency problems. The release team can force a removal from testing if it is really needed, please contact them if this should be the case. We try to close bugs which have been reported against this package automatically. But please check all old bugs, if they were closed correctly or should have been re-assigned to another package. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 686...@bugs.debian.org. The full log for this bug can be viewed at http://bugs.debian.org/686577 This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org. Debian distribution maintenance software pp. Alexander Reichle-Schmehl (the ftpmaster behind the curtain) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682161: unblock: arduino/1:1.0.1+dfsg-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Please unblock package arduino Fixed French translation of "Copy" in the "Edit" menu see bugs.debian.org/682079 unblock arduino/1:1.0.1+dfsg-4 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.1.0-1-486 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679182: logkeys: FTBFS on mips*: braces around scalar initializer for type 'unsigned int'
It still FTBFS with the new package from mentors/svn: /usr/bin/make all-recursive make[2]: Entering directory `/home/showard/logkeys-0.1.1a+svn20120529' Making all in src make[3]: Entering directory `/home/showard/logkeys-0.1.1a+svn20120529/src' g++ -DHAVE_CONFIG_H -I. -I.. -D_FORTIFY_SOURCE=2 -Wall -O3 -DSYS_CONF_DIR=\"/etc\" -c -o logkeys.o logkeys.cc In file included from logkeys.cc:59:0: upload.cc: In function ‘void logkeys::start_remote_upload()’: upload.cc:87:30: error: braces around scalar initializer for type ‘unsigned int’ logkeys.cc: In function ‘void logkeys::set_signal_handling()’: logkeys.cc:154:30: error: braces around scalar initializer for type ‘unsigned int’ make[3]: *** [logkeys.o] Error 1 make[3]: Leaving directory `/home/showard/logkeys-0.1.1a+svn20120529/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/showard/logkeys-0.1.1a+svn20120529' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/showard/logkeys-0.1.1a+svn20120529' make: *** [debian/stamp-makefile-build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682079: Bug not fixed
notfixed 682079 1:1.0.1+dfsg-4 reopen 682079 thanks On Sat, Jul 28, 2012 at 11:29 AM, Alain Rpnpif wrote: > Hello Scott, > > I think that the fr_fix.diff patch does not fix this bug. It is > modifying processing/app/Resources_fr.po but it is > processing/app/Resources_fr.properties in pde.jar after compiling. > And the error is still here when I run > $ LANG=fr_FR.UTF-8 arduino > > Is Resources_fr.po used (before or after compiling) ? It is not in > pde.jar. Thanks, you're right we need to patch .properties too: Index: arduino/app/src/processing/app/Resources_fr.po === --- arduino.orig/app/src/processing/app/Resources_fr.po 2012-07-30 11:01:09.695499167 -0400 +++ arduino/app/src/processing/app/Resources_fr.po 2012-07-30 11:01:39.831498549 -0400 @@ -216,7 +216,7 @@ #: Editor.java:1143 Editor.java:2660 msgid "Copy" -msgstr "Coller" +msgstr "Copier" I'll send it up in few minutes. I checked the french translation on my IDE installation and it looks correct. 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#683520: [eagle] Eagle 6.2 is now available from cadsoft. Please upgrade
forcemerge 652089 683520 thanks On Wed, Aug 1, 2012 at 7:53 AM, David Goodenough wrote: > Package: eagle > Version: 5.12.0-3 > Severity: wishlist > > --- Please enter the report below this line. --- > > The current version of Eagle at Cadsoft is 6.2, while only 5.12 is > available in Debian. While I realise not a lot is going to happen > while the freeze is in place, would it be possible to have the new > version when the freeze is over? Please see bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652089 and http://www.element14.com/community/thread/17738 CadSoft decided to release version 6 which is in compatible with nearly every distribution except OpenSuse. Even if you download it from their website you have to find and install extra libraries from someone else or ask them for extra files to get it to work. 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#681796: possible memory leak causing x.org crash?
I am not too familiar with this bug, but I can across a recent patch
[1] to x.org to fix a memory leak in XICreateDeviceProperty(), around
the same lines where this crash is happening.
Error: Memory leak (CWE 401)
Memory leak of pointer 'prop' allocated with XICreateDeviceProperty(property)
at line 774 of Xi/xiproperty.c in function 'XIChangeDeviceProperty'.
'prop' allocated at line 700 with XICreateDeviceProperty(property).
prop leaks when handler != NULL at line 768
and handler->SetProperty != NULL at line 769
and checkonly != 0 at line 772
and rc != 0 at line 772.
The patch is:
diff --git a/Xi/xiproperty.c b/Xi/xiproperty.c
index ca73104..4beedcf 100644
--- a/Xi/xiproperty.c
+++ b/Xi/xiproperty.c
@@ -771,6 +771,8 @@ XIChangeDeviceProperty(DeviceIntPtr dev, Atom
property, Atom type,
&new_value, checkonly);
if (checkonly && rc != Success) {
free(new_value.data);
+if (add)
+XIDestroyDeviceProperty(prop);
return rc;
}
}
[1] http://patchwork.freedesktop.org/patch/11531/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681796: possible memory leak causing x.org crash?
On Thu, Aug 2, 2012 at 5:39 PM, Scott Howard wrote: > I am not too familiar with this bug, but I can across a recent patch > [1] to x.org to fix a memory leak in XICreateDeviceProperty(), around > the same lines where this crash is happening. Disregard the above, the patch doesn't fix it for me. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679182: logkeys: FTBFS on mips*: braces around scalar initializer for type 'unsigned int'
On Mon, Aug 6, 2012 at 7:56 PM, Vedran Furač wrote: > On 07/27/2012 10:33 PM, Scott Howard wrote: > >> It still FTBFS with the new package from mentors/svn: >> >> upload.cc:87:30: error: braces around scalar initializer for type ‘unsigned >> int’ >> logkeys.cc:154:30: error: braces around scalar initializer for type >> ‘unsigned int’ > > I've applied a patch that might have fixed this, could you test version > 0.1.1a+svn20120529-2 from mentors? Looks good! Do you need a sponsor or should your normal sponsor do this? It could be good for you to get access to a porterbox machine [1] or set up a mips qemu emulated system [2] to test future problems. [1] http://dsa.debian.org/doc/guest-account/ [2] http://www.aurel32.net/info/debian_mips_qemu.php -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682676: patch for bitcoind DoS
tags 682676 patch thanks Since we're in freeze and I don't know if a new release is planned, I found the patches to fix the bug listed here: https://github.com/bitcoin/bitcoin/commit/469f6da8bcaf0179f1afbb5d927aae0d9b1ce610.diff https://github.com/bitcoin/bitcoin/commit/63ee422ab312ec7bb03c0f7e74308d23723e364e.diff https://github.com/bitcoin/bitcoin/commit/4d87a33eaeccfee0fc2469dcc090a47a9d086a04.diff corresponding to commits: https://github.com/bitcoin/bitcoin/commit/469f6da8bcaf0179f1afbb5d927aae0d9b1ce610 https://github.com/bitcoin/bitcoin/commit/63ee422ab312ec7bb03c0f7e74308d23723e364e https://github.com/bitcoin/bitcoin/commit/4d87a33eaeccfee0fc2469dcc090a47a9d086a04 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#660286: seperating blockchain db from wallet data
>From upstream Wladimir "This is currently not feasible due to BerkelyDB limitations. All the databases are within one 'environment', which is necessarily one directory (it can probably be hacked around, but obviously we're really careful). When LevelDB for the block chain and the custom format for the wallets is introduces, various new configurations will be possible: Multiple wallets, wallet in block chain in separate dirs, etc." -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
