Bug#1061743: Gramps in Debian
Hi both, Thanks so much for doing this. On 27.05.2024 19.49, Dr. Tobias Quathamer wrote: Am 27.05.24 um 15:38 schrieb IOhannes m zmölnig (Debian GNU|Linux): On 5/26/24 23:56, Dr. Tobias Quathamer wrote: The package builds on my machine, although I had to disable a single test for now. You'll find it in the newly created patch. Maybe you have an idea what's causing the failure, so it can be fixed properly. https://gramps-project.org/bugs/view.php?id=13305 i think this is just a wrong assumption on the side of the upstream testsuite (shadowed by their workflows). upstream evades this by ensuring that "~/.gramps/" is there before running the tests (both in their GitHub action, and in their debian/ packaging). i think that for now the proper resolution for the problem is to simply do a `mkdir "$CURDIR)/build/.gramps` before running the tests. (which i've now pushed to the 'experimental' branch) Great, thanks! That's a cleaner approach. as a sidenote: the testsuite now creates a *very* verbose buildlog (~420MB). is that ok? gf,madsr IOhannes Hm, I guess that's because of the "--verbose" option when running the tests. However, the buildlog has been similarly large in v5.1.6 as well. Could that to be due to the switch from nosetest to unittest? Maybe the --verbose option should be dropped? The buildlog gets shrinked to 1.4 MB, but the tests are only displayed as dots. Yes the build log is huge, and has been for a while. If you try and view it in a browser it never loads! I would be happy to turn the --verbose option off until it is needed one day. Regards, Tobias I will try and take a look this week. But if I fail, either of you are welcome to lose patience, merge it to master, and upload it for me. :-) Regards Ross
Bug#1061743: Gramps in Debian
Hi Tobias, There are no blockers other than real life getting in the way. I did start working on 5.2.0 in the experimental branch on Salsa. From memory, there was a problem with fuzzy patches, and the tedious checking of copyrights still to do. But I should probably merge the changes into master, and then import 5.2.2. If you have some spare cycles you are welcome to help move things along. I use gbp + quilt. Regards, Ross On 28.04.2024 17.40, Dr. Tobias Quathamer wrote: Hi Ross, I'd like to get gramps back into Debian, and from my (very limited) research it seems that gramps v5.2.1 fixed the build failure on Debian. Are you planning to update the package? Or is there another blocker which I didn't spot? Thanks for taking care of gramps in Debian! Regards, Tobias
Bug#1061743: Try again
forwarded 1061743https://gramps-project.org/bugs/view.php?id=13212 thanks
Bug#1061743: Forwarded upstream
forwarded 1061743https://gramps-project.org/bugs/view.php?id=13212 thanks This is also a problem for Gramps in the next release of Ubuntu (24.04 Noble). Gramps has been removed from Ubuntu Noble because Noble has python 3.12.
Bug#1031258: Removal from unstable
Hi Petter, Thanks for doing this. Removal from unstable is the right thing to do I think. Regards, Ross
Bug#939951: Link upstream bug
forwarded 939951 https://github.com/kupferlauncher/keybinder/issues/16 thanks Looks like upstream have committed a fix, but have not confirmed it by closing the issue. Ross
Bug#947556: marked as pending in create-resources
Control: tag -1 pending Hello, Bug #947556 in create-resources reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/multimedia-team/create-resources/-/commit/7060a8daf2e7de54ffa173fa186d9f4fbfd54cee Apply patch to fix FTBFS with Python3 Scons Closes: #947556 Thanks: Reiner Herrmann (this message was generated automatically) -- Greetings https://bugs.debian.org/947556
Bug#936463: python3-ecasound: Upstream are working on Python 3 support
Hi, There is a pull request to add Python3 support: https://github.com/kaivehmanen/ecasound/pull/1 It was updated 18 hours ago. We should keep an eye on that. Ross signature.asc Description: OpenPGP digital signature
Bug#936891: python3-libmapper: latest upstream release supports Python 3
Hi, According to the upstream Github repo, Python 3 support was added in 2017. https://github.com/libmapper/libmapper We should package the latest release. Regards, Ross signature.asc Description: OpenPGP digital signature
Bug#938072: python-pyknon latest upstream release supports Python 3
Hi. It looks like the watchfile needs fixing. According to upstream, Python 3 is supported in the latest release. https://github.com/kroger/ Regards, Ross signature.asc Description: OpenPGP digital signature
Bug#947723: Devede: dropping python-scour from Build Depends
Hi, Further to Jonas's suggestion, I found this in the changelog for scour: scour (0.37-2) unstable; urgency=medium [ Jeremy Bicha ] * Add Provides: dh-sequence-scour. Packages can now Build-Depend on dh-sequence-scour instead of scour and then drop "--with scour" from debian/rules (Requires debhelper 12) [ Martin Pitt ] * Bump Standards-Version to 4.3.0. No changes necessary. * Move to debhelper compat level 12. -- Martin Pitt https://launchpad.net/~pitti>> Sun, 13 Jan 2019 12:01:02 + So build-depending on dh-sequence-scour and dropping "--with scour" from debian/rules would seem to be the best option. Devede is already using debhelper-compat (= 12). Regards, Ross
Bug#875038: [lmms] Future Qt4 removal from Buster
Hi All, On 25/08/2019 21:18, Boyuan Yang wrote: > A stable lmms 1.2.0 with Qt5 support is already released several months ago= > I have imported 1.2.0 into salsa. I have been through all of the patches. I need to update copyrights. The potential snag is a FTBFS with gcc 9: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925771 I have not checked if the new version builds with gcc9 yet. My day job means I probably won't get back onto this until the weekend. Feel free to test, and offer up patches/merge requests. Regards, Ross signature.asc Description: OpenPGP digital signature
Bug#874857: marked as pending in dssi
Control: tag -1 pending Hello, Bug #874857 in dssi reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/multimedia-team/dssi/commit/69527d4d0eaf559ba1ce4944a6560d95c495969d Stop building Qt4 examples (Closes: #874857) (this message was generated automatically) -- Greetings https://bugs.debian.org/874857
Bug#897806: Lmms fix uploaded
On 1/22/19 4:41 PM, Boyuan Yang wrote: > Hi all, > > 在 2019-01-21一的 00:26 +0100，Ross Gammon写道： >> tag 891756 + pending >> tag 897806 + pending >> tag 918242 + pending >> thanks >> >> I have uploaded a fix. It is unfortunately waiting for my new signing >> sub-key to be rolled into the Debian Keyring. > I've prepared an upload from git packaging repo onto DELAYED/3. Please let me > know if there's any other issues. > > -- > Thanks, > Boyuan Yang Thanks Boyuan. As long as that was from the new Debian Multimedia Team repo, that should be OK. signature.asc Description: OpenPGP digital signature
Bug#897806: Lmms fix uploaded
tag 891756 + pending tag 897806 + pending tag 918242 + pending thanks I have uploaded a fix. It is unfortunately waiting for my new signing sub-key to be rolled into the Debian Keyring. Regards, Ross signature.asc Description: OpenPGP digital signature
Bug#902505: Bug #902505 in node-cross-spawn marked as pending
Control: tag -1 pending Hello, Bug #902505 in node-cross-spawn reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/js-team/node-cross-spawn/commit/54bf04a4b8c0d6c55a85223d0d85d2c3544a7820 Fix FTBFS by adding which & lru-cache to Build-Depends Closes: #902505 (this message was generated automatically) -- Greetings https://bugs.debian.org/902505
Bug#896305: laditools: diff for NMU version 1.1.0-3.1
On 08/04/2018 09:05 PM, Adrian Bunk wrote: > Control: tags 896305 + patch > Control: tags 896305 + pending > > Dear maintainer, > > I've prepared an NMU for laditools (versioned as 1.1.0-3.1) and uploaded > it to DELAYED/15. Please feel free to tell me if I should cancel it. > > cu > Adrian > Thanks Adrian for fixing this, and following up on the original incorrect fix. My spare time is very limited at the moment. I really appreciate it. signature.asc Description: OpenPGP digital signature
Bug#890023: abcmidi fails autopkg tests on 32bit architectures
Control: tags -1 pending
Hi James,
As usual, thanks for your help in tracking this down. I had noticed that
abcmidi was stuck in ubuntu -proposed, but I had not had time to
investigate.
As the changes seem to have been about fixing a windows problem, I am
sure the patch will be fine for Debian/Ubuntu. Seymour (upstream) will
no doubt consider applying the patch, or something better if it causes a
regression on Windows.
I hope to apply the patch in Debian, and upload with the latest upstream
release sometime this week.
Regards,
Ross
On 02/12/2018 02:28 PM, James Cowgill wrote:
> Control: tags -1 patch
>
> Hi,
>
> On 10/02/18 08:52, Matthias Klose wrote:
>> Package: src:abcmidi
>> Version: 20180125-1
>> Severity: serious
>> Tags: sid buster
>>
>> abcmidi fails autopkg tests on 32bit architectures, midi2abc crashing. Is
>> there
>> a reason why the tests are not run at build time?
>>
>>
>> MIDI to ABC conversion test
>>
>> Convert the araber47.mid file back to abc
>> Aborted (core dumped)
>> autopkgtest [14:08:29]: test conversions: ---]
>> autopkgtest [14:08:33]: test conversions: - - - - - - - - - - results - - -
>> - -
>> - - - - -
>> conversions FAIL non-zero exit status 134
>> autopkgtest [14:08:33]: test conversions: - - - - - - - - - - stderr - - -
>> - -
>> - - - - -
>> *** Error in `midi2abc': free(): invalid pointer: 0x00c43f28 ***
>> Aborted (core dumped)
> Caused by a buffer overflow in midi2abc.c:329
>> char* addstring(s)
>> /* create space for string and store it in memory */
>> char* s;
>> {
>> char* p;
>>
>> p = (char*) checkmalloc(strlen(s)+1);
>> strncpy(p, s,strlen(s)+2); /* [SS] 2017-08-30 */
>> return(p);
>> }
> strncpy writes to exactly n bytes to the output buffer, so the call will
> always overflow the buffer allocated one line above by 1 byte.
>
> Attached patch fixes this. I think using strcpy is safe here because the
> size of the buffer allocated is always greater than the string length.
>
> I think the comment on that line refers to this (from doc/CHANGES):
>> August 30 2017
>>
>> Midi2abc - The metatext string is not terminated with a 0 and
>> as a result can contain random junk, in particular on the Windows
>> operating system. Fix in midifile.c, the Msgbuff is initialized to
>> 0 when it is allocated.
> Some old code I found shows the code originally used strcpy. I'm not I
> understand how using strncpy was supposed to fix this. I've copied
> upstream who might be able to shed some light on this.
>
> Thanks,
> James
Bug#876937: missing build dependency
Control: tags -1 pending Hi Petter, I have just tested, and yes - adding node-mkdirp as a build dependency fixes it. Unfortunately I have to go out, but expect a team upload with the fix from me later today. Regards, Ross signature.asc Description: OpenPGP digital signature
Bug#877212: [Pkg-javascript-devel] Bug#877212: Bug#877212: node-d3-color: B-D npm not available in testing
On 10/04/2017 05:50 AM, Sean Whitton wrote: > Hello Jérémy, > > On Tue, Oct 03 2017, Jérémy Lal wrote: > >> It might be a good idea to make policy more explicit about downloads >> during build. > I'm not sure how it could be more explicit: > > For packages in the main archive, no required targets may attempt > network access. > > Some people could read "in the main archive" as not applying to contrib & non-free?
Bug#876597: goocanvas FTBFS with gtk-doc-tools 1.26: gtkdoc-mktmpl is no longer available
Hi Berto, On 10/02/2017 01:22 PM, Alberto Garcia wrote: > On Sun, Sep 24, 2017 at 01:08:34AM +0300, Adrian Bunk wrote: >> Source: goocanvas-2.0 >> Version: 2.0.2-2 >> Severity: serious >> Tags: buster sid > This seems to have been fixed in the most recent upstream version > (2.0.3). Packaging it should be enough to fix this bug. > > Berto > I just updated the bug at the same time as you :-) Actually, I had the next version almost ready (I was going to try and add an autopkgtest). Unfortunately, the new version still FTBFS, but I have worked out a patch today. Hopefully an upload will happen today or tomorrow to fix it. Regards, Ross
Bug#876597: Fix in preparation
Control: tags -1 pending Hi, I have prepared a fix. It just needs a quick test, and the patch forwarding upstream. An upload will follow shortly after. Regards, Ross
Bug#784619: Linked my Qt4-Qt5 fork to upstream Creepy issue
Removal bug submitted: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869366 On 22/07/17 12:32, Petter Reinholdtsen wrote: > [Ross Gammon] >> As Creepy looks totally unmaintained upstream these days, I recommend we >> remove it from unstable. > As both you and me seem to lack the spare time required to get creepy > into a releasable state, and response from upstream is hard to get, I > agree. > > Lets ask for its removal and revisit the topic if upstream become more > active and make the task easier. :) > signature.asc Description: OpenPGP digital signature
Bug#784619: Linked my Qt4-Qt5 fork to upstream Creepy issue
tag 784619 - |fixed-upstream thanks |Hi, I just pushed my unfinished Qt4 > Qt5 work to my fork of creepy on Github (https://github.com/RossGammon/creepy/tree/qt4-qt5) and added a link to the upstream issue (No. 9 - which was closed as "Won't fix"). They are the same patches I pushed to the Debian GIS repo on Alioth. As Creepy looks totally unmaintained upstream these days, I recommend we remove it from unstable. I will keep watching the Github repo, and if I ever see some commits, and a release we can work with, then we can always ITP > NEW queue again. But is doesn't look likely. I know Bas will probably support this - he is no doubt tired of seeing Creepy at the top of the GIS Team Dashboard. What do you think Petter? Regards, Ross signature.asc Description: OpenPGP digital signature
Bug#863481: [Pkg-javascript-devel] Bug#863481: [node-concat-stream] Uninitialized Memory Exposure
Hi Bastien, If you would like me to prepare an upload to unstable for this (& unblock request), let me know. I have some time today & tomorrow - but travelling with work next week. I have DM upload rights for it. Only asking in case you are already working on it. Cheers, Ross On 05/27/2017 04:51 PM, Bastien ROUCARIÈS wrote: > Package: node-concat-stream > Version: 1.5.1-1 > Severity: grave > Tags: patch security fixed-upstream fixed-in-experimental > X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org > forwarded: https://snyk.io/vuln/npm:concat-stream:20160901 > > Overview > > concat-stream is writable stream that concatenates strings or binary data and > calls a callback with the result. Affected versions of the package are > vulnerable to Uninitialized Memory Exposure. > > A possible memory disclosure vulnerability exists when a value of type number > is provided to the stringConcat() method and results in concatination of > uninitialized memory to the stream collection. > > This is a result of unobstructed use of the Buffer constructor, whose > insecure > default constructor increases the odds of memory leakage. > >
Bug#784619: Creepy: Still some work to do
Hi, I just found time to test Creepy after the last lot of QString changes. The QString import error is no longer there, although there is no guarantee that my changes were correct. Unfortunately now I get: $ creepy -v Traceback (most recent call last): File "/usr/bin/creepy", line 14, in from PyQt5.QtCore import QThread, SIGNAL, QUrl, QDateTime, QDate, QRect, Qt ImportError: cannot import name SIGNAL I am getting way out of my league here! I see this on the PyQt4/5 differences website: PyQt4’s old-style signals and slots are not supported. Therefore the following are not implemented in PyQt5: QObject.connect() QObject.emit() SIGNAL() SLOT() All methods that had arguments that are usually the results of calls to SIGNAL() or SLOT() are no longer supported. Any help appreciated. I don't have a lot of spare time to go reading the PyQt5 docs, and there are many other packages needing my attention. Cheers, Ross signature.asc Description: OpenPGP digital signature
Bug#784619: creepy: Qt5 conversion in progress
Hi, I have spent the day doing the Qt4 > Qt5 conversion following the tips from Dmitry. See the latest on alioth. Unfortunately, I get an import error when running creepy after installation: $ creepy -v Traceback (most recent call last): File "/usr/bin/creepy", line 14, in from PyQt5.QtCore import QString, QThread, SIGNAL, QUrl, QDateTime, QDate, QRect, Qt ImportError: cannot import name QString According to http://pyqt.sourceforge.net/Docs/PyQt5/pyqt4_differences.html: "PyQt4 supports a number of different API versions (QString, QVariant etc.). With the exception of QVariant, PyQt5 only implements v2 of those APIs for all versions of Python." I need to do some other stuff now. But will come back to this later in the week. Any advice to speed things up will be appreciated. Regards, Ross signature.asc Description: OpenPGP digital signature
Bug#844938: The new node-tap is causing FTBFS in node-inline-source-map
On 11/23/2016 11:43 PM, Jérémy Lal wrote: > 2016-11-23 21:47 GMT+01:00 Ross Gammon : >> tag 844938 + upstream >> forwarded 844938 https://github.com/thlorenz/inline-source-map/issues/18 >> thanks >> >> Hi, >> >> I have just investigated what has changed that might be causing this >> failure of the upstream testsuite, and it appears to be the recent >> update of node-tap to Version 8.0.0. >> >> The bug has been passed upstream >> (https://github.com/thlorenz/inline-source-map/issues/18), but if there >> are any node-tap experts reading this, I would be grateful for a patch >> to send there (as the Stretch release is looming). > > Done ! > Thanks Jeremy! I would have worked it out in the end, looking at the tap docs. But that saved me a bundle of time. Cheers, Ross signature.asc Description: OpenPGP digital signature
Bug#844922: [Pkg-javascript-devel] Bug#844922: Bug#844922: Node-string-decoder
On 11/23/2016 08:59 AM, Jérémy Lal wrote: > 2016-11-23 8:53 GMT+01:00 Ross Gammon : >> Hi, >> >> This node module was originally packaged as it was a dependency of something >> (I can't remember). >> >> If there is nothing depending on it, we should probably remove it from the >> archive. The string-decoder function from the core nodejs should be used >> instead (patching the module that needs it if required). Node-string-decoder >> is mainly used when a nodejs project wants to stick to an old version of >> this function. >> >> Regards, > > All right, can you fill the ftp.debian.org RM request please ? > > Jérémy > Done! signature.asc Description: OpenPGP digital signature
Bug#844938: The new node-tap is causing FTBFS in node-inline-source-map
tag 844938 + upstream forwarded 844938 https://github.com/thlorenz/inline-source-map/issues/18 thanks Hi, I have just investigated what has changed that might be causing this failure of the upstream testsuite, and it appears to be the recent update of node-tap to Version 8.0.0. The bug has been passed upstream (https://github.com/thlorenz/inline-source-map/issues/18), but if there are any node-tap experts reading this, I would be grateful for a patch to send there (as the Stretch release is looming). Regards, Ross signature.asc Description: OpenPGP digital signature
Bug#844922: Node-string-decoder
Hi, This node module was originally packaged as it was a dependency of something (I can't remember). If there is nothing depending on it, we should probably remove it from the archive. The string-decoder function from the core nodejs should be used instead (patching the module that needs it if required). Node-string-decoder is mainly used when a nodejs project wants to stick to an old version of this function. Regards, Ross
Bug#845012: grunt: Grunt is missing the rimraf dependency
Package: grunt Version: 1.0.1-2 Severity: grave Justification: renders package unusable Dear Praveen & helpers, Thank you so much for all the hard work on grunt, and for putting up with so much criticism in the process! I am just building my first package with grunt, and hit a small snag. node- rimraf is missing from grunt's dependencies in debian/control. When building my package with grunt, I got the same error as that appearing on the as-installed testing page for grunt: https://ci.debian.net/data/packages/unstable/amd64/g/grunt/20161118_032242.autopkgtest.log.gz The fix is quite simple, so forgive me if I don't provide a patch :-) Regards, Ross Gammon -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial'), (100, 'xenial-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-24-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#844014: node-js-yaml
Thanks Jeremy, I am trying to finish off kosmtik packaging, and there are several dependencies that are either too old or too new. Just want to ping the other package maintainers (where the dependency is too old) first. For js-yaml, it is an easy fix, and I just need to ask Gianfranco (previous sponsor) for DM upload rights to do it. Cheers, Ross On 12/11/16 00:25, Jérémy Lal wrote: 2016-11-11 20:48 GMT+01:00 Ross Gammon <mailto:rossgam...@mail.dk>>: Package: node-js-yaml Version: 3.6.1+dfsg-1 Severity: grave Justification: renders package unusable Dear Maintainer, Node-js-yaml is currently uninstallable in unstable due to a tight dependency on node-esprima (< 3.0.0), when the current version of node-esprima in unstable is 3.1.0. The upstream testsuite passes fine with v3.1.0 of node-esprima, so it should be fine to just drop the (<3.0.0) dependency. Regards, Ross You're the node-js-yaml maintainer - do you need help ? Jérémy
Bug#844014: node-js-yaml
Package: node-js-yaml Version: 3.6.1+dfsg-1 Severity: grave Justification: renders package unusable Dear Maintainer, Node-js-yaml is currently uninstallable in unstable due to a tight dependency on node-esprima (< 3.0.0), when the current version of node-esprima in unstable is 3.1.0. The upstream testsuite passes fine with v3.1.0 of node-esprima, so it should be fine to just drop the (<3.0.0) dependency. Regards, Ross -- System Information: Debian Release: stretch/sid APT prefers xenial-updates APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 'xenial'), (100, 'xenial-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-24-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#820312: python-laditools: fails to upgrade from 'jessie': does not find an upgrade path
reassign 820312 python-enum34 1.1.2-1 retitle 820312 python-enum34: should conflict/replace python-enum thanks Hi, I have tried having python-laditools conflict with python-enum, but this is not enough to allow python-laditools to upgrade. I suspect the only way to fix this is to have python-enum34 conflict with (and maybe replace) python-enum. For your information, python-enum already conflicts with python-enum34, and is hopefully going to be removed from the archive soon (there is one package remaining that blocks removal). Old bug on python-enum for your information: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795444 Regards, Ross signature.asc Description: OpenPGP digital signature
Bug#820291: node-seq: uninstallable in sid: Depends: node-chainsaw (< 0.1) but 0.1.0-1 is to be installed
Hi, I am not to worried about node-seq being removed from testing at the moment, as there are many other dependencies requiring packaging for browserify first. It looks like it is is not a simple matter of updating the Depends: field in debian/control. Cloning the upstream repo, merging some fixes for the testsuite from a fork, npm install'ing the dependencies gives me a passing test (Expresso is required for the tests - I must file a bug about that). npm update'ing the chainsaw dependency to 0.1.0 gives me the following test failure when running "npm test": uncaught undefined: RangeError: Maximum call stack size exceeded at action (/home/ross/github/node-seq/index.js:76:11) at call (/home/ross/github/node-seq/index.js:236:17) at Array.forEach (native) at Object.parEach (/home/ross/github/node-seq/index.js:230:17) at EventEmitter.saw.next (/home/ross/github/node-seq/node_modules/chainsaw/index.js:62:18) at Object.extend (/home/ross/github/node-seq/index.js:491:13) at EventEmitter.saw.next (/home/ross/github/node-seq/node_modules/chainsaw/index.js:62:18) at EventEmitter.saw.jump (/home/ross/github/node-seq/node_modules/chainsaw/index.js:143:13) at Function.cb (/home/ross/github/node-seq/index.js:39:21) at next (/home/ross/github/node-seq/index.js:266:26) I will need to see what changed in chainsaw. But I will probably concentrate on all the other browserify dependencies first. Regards, Ross signature.asc Description: OpenPGP digital signature
Bug#742347: [Pkg-javascript-devel] Bug#742347: overview of the tilemill situation and alternatives (mapbox, kosmtik)
Hi Antoine, Thanks for that excellent summary! It has cleared up a confusion that I had. More below: On 03/13/2016 04:40 PM, Antoine Beaupré wrote: > 1. Mapbox people have released a new product in september 2014 named > [Mapbox studio classic][]. the code is a > [still freely available][] and seems to be a > [fork of tilemill][]. mapbox classic still has releases on github, > last one is from november 2015 > > [Mapbox studio classic]: https://www.mapbox.com/mapbox-studio-classic/#linux > [still freely available]: https://github.com/mapbox/mapbox-studio-classic > [fork of tilemill]: > https://github.com/mapbox/mapbox-studio-classic/blob/mb-pages/docs/-01-01-common-questions.md#how-is-mapbox-studio-related-to-tilemill#user-content-how-is-mapbox-studio-classic-related-to-tilemill Actually, it looks like mapbox-studio was renamed mapbox-studio-classic when they released the new mapbox-studio [3] which runs online (after sign up). > > 2. It looks like Mapbox studio classic has some sort of > [Mapbox.com lock-in][], and there are certainly new copyright > issues, if only with the [bundled fonts][]. but it could probably > be packaged. > > [Mapbox.com lock-in]: > https://github.com/mapbox/mapbox-studio-classic/blob/mb-pages/docs/-01-01-common-questions.md#can-i-use-git-with-a-style-or-source-project > [bundled fonts]: > https://github.com/mapbox/mapbox-studio-classic/blob/mb-pages/docs/-01-01-common-questions.md#what-cancant-i-do-with-pro-fonts Yes. Mapbox-studio (classic) needs a log in, but is probably worthwhile for access to all the datasets. I have not signed up yet :-) > > 3. Then there's [mapbox studio][], which is a > [full rewrite of mapbox][]. You need to "signup" somehow to get > access, even though parts of the code are free, namely the > [Mapbox GL studio][] project > > [Mapbox GL studio]: https://github.com/mapbox/mapbox-gl-native/ > [full rewrite of mapbox]: https://www.mapbox.com/help/upgrading-from-classic/ > [mapbox studio]: https://www.mapbox.com/mapbox-studio/ > > 4. The [Openstreetmap-carto][] developpers have mostly switched to > [kosmtik][] instead of Mapbox. > > [Openstreetmap-carto]: https://github.com/gravitystorm/openstreetmap-carto > [kosmtik]: https://github.com/kosmtik/kosmtik Kosmtik will be the quickest to package. But as stated in the readme: "Alpha version, installable only from source". We would need to create an executable (which upstream themselves believe they are not ready for). > 6. Ross has an [ITP for kosmtik][]. The package is waiting on other > node dependencies to be uploaded (yes, again). > > [ITP for kosmtik]: https://bugs.debian.org/805308 Feel free to help out by picking up one of the RFP's :-) > > 7. There is also an [ITP for Mapbox-studio][] yet it is unclear to me > what that one means because the source code to Mapbox-studio > doesn't seem to be available, as far as i can tell (and the ITP > doesn't say either). > > [ITP for Mapbox-studio]: https://bugs.debian.org/#761914 This is where the confusion was. $ npm install mapbox-studio gets you: https://www.npmjs.com/package/mapbox-studio This points you to the source at github.com/mapbox/mapbox-studio which redirects to github.com/mapbox/mapbox-studio-classic! > > 8. There's no WNPP bug for Mapbox studio *classic* that I can > found. So now there is! I will retitle the mapbox-studio RFP to mapbox-studio-classic, and the relevant Javascript Team task page: https://wiki.debian.org/Javascript/Nodejs/Tasks/mapbox-studio There is plenty here that needs packaging. there's still an [RFP for tilemill][], which should > probably be closed now because the project seems dead and plenty > of alternatives exist. I wonder if node some dependencies that > were packaged for Tilemill actually now need to be *removed* from > Debian, because they have become useless leaf packages... I am > leaving the Tilemill RFP open for someone to clean that up. > > [RFP for tilemill]: https://bugs.debian.org/644767 We should not be too hasty here. Some of the dependencies may still be required by other mapping apps. Also, tilemill is not completely dead. The mapbox employees are not allowed to work on tilemill during work time, but they will merge pull requests, and are happy to give wider commit access. Someone stated on one of their bugs that their personal fork of tilemill is working and is willing to push those changes back. So it could be resurrected yet. Of course, some packages may get removed from stretch automatically (RC) anyway. Cheers, Ross signature.asc Description: OpenPGP digital signature
Bug#804558: marked as pending
tag 804558 pending thanks Hello, Bug #804558 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://git.debian.org/?p=python-modules/packages/tweepy.git;a=commitdiff;h=d6486ad --- commit d6486ad58f1a06de39c2d694b4108ca0ee9f7566 Author: Ross Gammon Date: Wed Feb 10 22:37:42 2016 +0100 Finalise changelog & set distribution to unstable diff --git a/debian/changelog b/debian/changelog index 4ba8b5f..65dac44 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,13 @@ +tweepy (3.4.0-2) unstable; urgency=medium + + * Team upload. + * Disable upstream tests (Closes: #804558) +The tests fail as they need internet access + * Use secure URL for Vcs + * Make Python 3 package short description unique + + -- Ross Gammon Wed, 10 Feb 2016 22:33:26 +0100 + tweepy (3.4.0-1) unstable; urgency=medium [ Carl Chenet ]
Bug#804558: Failing Unittests on Tweepy [RC]
Hi, Adding python(3)-unittest2, vcr & nose to the build dependencies get you past all the Import Errors. But unfortunately, all (except a few) tests then fail with "CONNECTION REFUSED". As most of the tests seem to need an internet connection, it may be best to disable the tests in Debian. Regards, Ross signature.asc Description: OpenPGP digital signature
Bug#770591: Creepy Flickr plugin - Severity of serious no longer justified
Control: severity -1 normal Now that we have at least one plugin working Creepy (twitter), the grave severity of this bug is no longer justified because Creepy can now be used for something. Thanks for all your work on this Petter. signature.asc Description: OpenPGP digital signature
Bug#805202: gramps: FTBFS - fix is pending
Control: tags -1 pending Hi, I was expecting this issue as I had a preview of a similar failure in Ubuntu when Python 3.5 is the default. I had been waiting for Django 1.8, and now we have Django 1.9 and the failure still exists. As the Django webapp in Gramps is not yet enabled (not used), the simplest thing to do is to exclude nose from looking in that directory for now. Regards, Ross
Bug#742347: [Pkg-javascript-devel] Bug#742347: Fwd: Re: Bug#742347: Bug#742347: tilemill vs mapbox studio?
On 11/06/2015 04:16 PM, Ross Gammon wrote: > I will do an ITP & create a task page over the weekend. But please jump > in when/if any of you like. My current work rate is not very high (one > package every other day). Sorry it took so long. I had problems with creating the Task page (python script borking due to some string substitution problem I couldn't track down). So I have created an ITP for kosmtik, and blocked it with some RFPs & existing ITPs (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805308). We should probably move any further discussion of kosmtik there. Feel free to chip in with some packaging (including any of my ITPs if I am too slow). Cheers, Ross signature.asc Description: OpenPGP digital signature
Bug#742347: Fwd: Re: [Pkg-javascript-devel] Bug#742347: Bug#742347: tilemill vs mapbox studio?
Sorry - dropping the bug and Antoine was unintentional, so forwarding my reply to javascript list. Also not sure if Bas is still readiing Javascript list (so cc'd). Forwarded Message Subject: Re: [Pkg-javascript-devel] Bug#742347: Bug#742347: tilemill vs mapbox studio? Date: Fri, 6 Nov 2015 15:57:58 +0100 From: Ross Gammon To: pkg-javascript-de...@lists.alioth.debian.org On 11/05/2015 05:11 PM, Jérémy Lal wrote: > > > 2015-11-05 17:04 GMT+01:00 Bas Couwenberg <mailto:sebas...@xs4all.nl>>: > > On 2015-11-05 16:59, Antoine Beaupré wrote: > > On 2015-11-05 09:52:19, Bas Couwenberg wrote: > > The openstreetmap-carto developers have mostly switched to > kosmtic: > > https://github.com/kosmtik/kosmtik > > > is that a fork of tilemill? how does it differ? > > > It's not a fork. It's not a Mapbox project. > > maybe a new ITP should be opened for this then? > > > It's still alpha, but shows much more promise than mapbox-studio as > an alternative to tilemill. > > If you want to spend time packaging an alternative for tilemill, I > think kosmtik is your best option. > > > Indeed it looks like an alternative to tilemill. > Mapbox studio classic is not really as good, and to be released mapbox > studio (but i don't know when) > is very promising. Every now and then I try running tilemill from the github source tree to see if it is close to something that could be packaged. But I didn't have success the last couple of times. There is certainly no sniff of a coming release. It is a shame considering all of the hard work Dave put in to package all the dependencies. Not knowing about kosmtk, I started working on mapbox (the one released in npm): https://wiki.debian.org/Javascript/Nodejs/Tasks/mapbox-studio Feel free to grab one of the dependencies to package if you are looking for work. But kosmtik certainly looks like it would be a much quicker win, and a better place to start: $ npm2deb depends kosmtik Dependencies: NPM Debian kosmtik (0.0.12) None ââ carto (^0.15.2)node-carto (0.9.5-2) ââ generic-pool (^2.2.0) node-generic-pool (2.0.3-1) ââ js-yaml (^3.4.2) None ââ json-localizer (0.0.3) None ââ leaflet (^0.7.3) None ââ leaflet-formbuilder (^0.2.0) None ââ leaflet-hash (^0.2.1) None ââ mapnik (^3.4.7)node-mapnik (1.2.3-1build1) ââ nomnom (^1.8.1)None ââ npm (^3.3.5) None ââ request (^2.64.0) node-request (2.26.1-1) ââ semver (^5.0.3)node-semver (2.1.0-2) Build dependencies: NPM Debian mocha (^2.2.5)node-mocha (1.20.1-1) I will do an ITP & create a task page over the weekend. But please jump in when/if any of you like. My current work rate is not very high (one package every other day). Cheers, Ross ___ Pkg-javascript-devel mailing list pkg-javascript-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel signature.asc Description: OpenPGP digital signature
Bug#770591: Creepy: Flickr plugin not working
Control: retitle -1 Creepy: "Flickr plugin not working" Hi, So lets try and push to get Creepy working for Stretch. I am going to try and concentrate on one plugin. Hence the retitle. I will create separate bugs for the other plugins. Regards, Ross signature.asc Description: OpenPGP digital signature
Bug#791240: pktools: symbols file update needed for GCC 5
Control: unblock 791240 by 790351 On Fri, 7 Aug 2015 21:20:57 +0100 Dimitri John Ledkov wrote: > Hello, > > The block on boost bug is incorrect. 1.55 will not support libstdc++6 c++11 > abi. > > Instead one should build against boost 1.58, which is now the default in > unstable, and uses the new abi. > > So transition to new boost is needed, but otherwise you should be good to > go. > > Regards, > > Dimitri. Sorry - my mistake. So it should also be possible to install libdap now, as I discovered the bug had not been closed properly in the changelog (now closed manually). Cheers, Ross signature.asc Description: OpenPGP digital signature
Bug#792568: closing 792568
close 792568 3.14.0-3~exp2 thanks -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793856: node-coffeeify: New version fixing dependency problem is ready
Control: tags -1 pending A new version of node-coffeeify is ready for upload (can be found on mentors: http://mentors.debian.net/package/node-coffeeify). This new version requires ^1.1.0 of node-convert-source-map, so I have updated the dependency in Debian to <<2.0.0. Most sponsors are busy with the GCC5 transition at the moment, so I will wait a little bit before chasing. Regards, Ross signature.asc Description: OpenPGP digital signature
Bug#779308: Gramps: Upgrade to Python 3 Gramps causing multiple serious database errors
Package: gramps Version: 4.1.1~dfsg-2 Severity: serious Tags: pending Hi, I have been made aware of several upstream bugs that render Gramps unusable for users that have special characters in their database (i.e. languages other than English). For example: https://gramps-project.org/bugs/view.php?id=8134 https://gramps-project.org/bugs/view.php?id=8258 https://gramps-project.org/bugs/view.php?id=8357 https://gramps-project.org/bugs/view.php?id=8360 https://gramps-project.org/bugs/view.php?id=8117 The bugs occur in Gramps 4.1.1 when users are asked to upgrade their database because of the switch to Python 3. This is the explanation from Nick Hall from the Gramps Project: "The database contains a mix of unicode and strings. When a record in python2 format is loaded into python3, unicode gets converted into a str, but the way strings are converted depends on the encoding setting. If "bytes" is specifies then strings are converted into bytes, otherwise they are also converted to str. By default strings are converted into str using the ASCII encoding. This will cause errors if the strings contain utf-8 encoded unicode." I have cherry picked the commits from upstream that fix the problem, and it should be uploaded soon. Regards, Ross signature.asc Description: OpenPGP digital signature
Bug#772573: Update prepared in git
Control: tags -1 pending Hi, I have pushed the fix to git, and will try and arrange an upload soon. Regards, Ross signature.asc Description: OpenPGP digital signature
Bug#772573: gramps: clean target failing
Control: found -1 4.1.1~dfsg-1 On 12/08/2014 06:37 PM, Ross Gammon wrote: > Package: gramps > Version: 4.0.4+dfsg-1~ubuntu14.04.1 > Severity: serious > Justification: Policy 4.9 > > Dear Maintainer, > > Whilst investigating #771095 I noticed that the clean target for Gramps is > failing, leaving behind the following files: > data/tips.xml > gramps/plugins/lib/holidays.xml > po/.intltool-merge-cache > > This is a breach of Debian Policy and should be fixed for Jessie. > > Regards, > > Ross > > > > -- System Information: > Debian Release: jessie/sid > APT prefers trusty-security > APT policy: (990, 'trusty-security'), (900, 'trusty-updates'), (500, > 'trusty'), (400, 'trusty-proposed'), (200, 'utopic-proposed'), (100, 'trusty- > backports') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.13.0-40-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 gramps depends on: > ii gir1.2-gtk-3.0 3.10.8-0ubuntu1.2 > ii librsvg2-2 2.40.2-1 > ii python 2.7.5-5ubuntu3 > ii python-gi3.12.0-1ubuntu1 > ii python-gi-cairo 3.12.0-1ubuntu1 > pn python:any > ii xdg-utils1.1.0~rc1-2ubuntu7.1 > > Versions of packages gramps recommends: > pn gir1.2-gexiv2-0.4 > ii gir1.2-osmgpsmap-1.0 1.0.2-2 > ii graphviz 2.36.0-0ubuntu3 > ii python-pyicu 1.5-2ubuntu4 > > Versions of packages gramps suggests: > ii fonts-freefont-ttf20120503-4 > ii gir1.2-gtkspell3-3.0 3.0.4-1 > ii gir1.2-webkit-3.0 2.4.4-1~ubuntu1 > ii python-pil2.3.0-1ubuntu3 > pn rcs > > signature.asc Description: OpenPGP digital signature
Bug#772573: gramps: clean target failing
Package: gramps Version: 4.0.4+dfsg-1~ubuntu14.04.1 Severity: serious Justification: Policy 4.9 Dear Maintainer, Whilst investigating #771095 I noticed that the clean target for Gramps is failing, leaving behind the following files: data/tips.xml gramps/plugins/lib/holidays.xml po/.intltool-merge-cache This is a breach of Debian Policy and should be fixed for Jessie. Regards, Ross -- System Information: Debian Release: jessie/sid APT prefers trusty-security APT policy: (990, 'trusty-security'), (900, 'trusty-updates'), (500, 'trusty'), (400, 'trusty-proposed'), (200, 'utopic-proposed'), (100, 'trusty- backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13.0-40-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 gramps depends on: ii gir1.2-gtk-3.0 3.10.8-0ubuntu1.2 ii librsvg2-2 2.40.2-1 ii python 2.7.5-5ubuntu3 ii python-gi3.12.0-1ubuntu1 ii python-gi-cairo 3.12.0-1ubuntu1 pn python:any ii xdg-utils1.1.0~rc1-2ubuntu7.1 Versions of packages gramps recommends: pn gir1.2-gexiv2-0.4 ii gir1.2-osmgpsmap-1.0 1.0.2-2 ii graphviz 2.36.0-0ubuntu3 ii python-pyicu 1.5-2ubuntu4 Versions of packages gramps suggests: ii fonts-freefont-ttf20120503-4 ii gir1.2-gtkspell3-3.0 3.0.4-1 ii gir1.2-webkit-3.0 2.4.4-1~ubuntu1 ii python-pil2.3.0-1ubuntu3 pn rcs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#770591: Creepy: Plugins update
On Mon, 24 Nov 2014 08:08:10 +0100 Ross Gammon wrote: [...] > > I am also close to a working patch for the remaining plugins, but > my final tweak last night went backwards. If I don't crack it > tonight, I will attach the patch as it is and ask for help. > Okay - some progress. I have pushed a patch that reads the plugin config from /usr/share, then writes changes to ~/.creepy to keep the original config intact. Unfortunately, I missed the fact that the "labels" always need to be read from /usr/share, so the patch needs restructuring a bit to achieve this. Then twitter.py needs to be fixed to write the authentication information to ~/.creepy as well. The final thing once I can get some locations read in, is to make sure the "export to file" code writes somewhere sensible as well. Cheers, Ross -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#770591: Creepy: Plugins update
Hi, I just pushed a commit disabling the instagram plugin. There is an RFS/ITP bug for python-instagram (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770149), but it is too late for jessie. Disabling the instagram plugin significantly reduces the noise in the Creepy logs. I am also close to a working patch for the remaining plugins, but my final tweak last night went backwards. If I don't crack it tonight, I will attach the patch as it is and ask for help. Cheers, Ross -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#770591: Creepy: Plugins not working
Package: creepy Version: 1.2~alpha Severity: grave Hi Team, The twitter and flickr plugins are not working in this version of Creepy due to Creepy trying to write to the *.config & *.labels files in usr/share/* without the correct permissions. Petter Reinholdtsen and I have been working (well Petter mainly) on Creepy to get it upgraded to the latest version after it was removed from testing due to a dependency on an old version of osmgpsmap. It took a lot of patching due to the non-portability of the creepy code. Several pull requests have been submitted upstream. Anyway, here are the errors from the creepy.main.log when the current version in unstable is installed and you try to configure the twitter & flickr plugins: 2014-11-20 18:00:01,625 - yapsy_loaded_plugin_Twitter_Plugin_0 - DEBUG - Trying to load the labels file for the twitter plugin . 2014-11-20 18:00:01,770 - yapsy_loaded_plugin_Flickr_Plugin_0 - DEBUG - Trying to load the labels file for the flickr plugin . 2014-11-20 18:01:22,340 - yapsy_loaded_plugin_Twitter_Plugin_0 - ERROR - [Errno 13] Permission denied: '/usr/share/creepy/plugins/twitter/twitter.conf' 2014-11-20 18:01:24,584 - yapsy_loaded_plugin_Twitter_Plugin_1 - DEBUG - Trying to load the labels file for the twitter plugin . 2014-11-20 18:01:24,586 - yapsy_loaded_plugin_Flickr_Plugin_1 - DEBUG - Trying to load the labels file for the flickr plugin . 2014-11-20 18:02:20,901 - yapsy_loaded_plugin_Twitter_Plugin_1 - ERROR - [Errno 13] Permission denied: '/usr/share/creepy/plugins/twitter/twitter.conf' 2014-11-20 18:02:27,458 - yapsy_loaded_plugin_Twitter_Plugin_2 - DEBUG - Trying to load the labels file for the twitter plugin . 2014-11-20 18:02:27,460 - yapsy_loaded_plugin_Flickr_Plugin_2 - DEBUG - Trying to load the labels file for the flickr plugin . 2014-11-20 18:02:47,547 - models.InputPlugin - ERROR - Could not save the configuration for the flickr plugin. 2014-11-20 18:02:47,547 - models.InputPlugin - ERROR - [Errno 13] Permission denied: '/usr/share/creepy/plugins/flickr/flickr.conf' Traceback (most recent call last): File "/usr/share/creepy/models/InputPlugin.py", line 70, in saveConfiguration config.write() File "/usr/lib/python2.7/dist-packages/configobj.py", line 2128, in write with open(self.filename, 'wb') as h: IOError: [Errno 13] Permission denied: '/usr/share/creepy/plugins/flickr/flickr.conf' 2014-11-20 18:02:47,582 - models.InputPlugin - ERROR - Could not save the configuration for the twitter plugin. Petter suggests the sensible approach of rewriting the config file handling to only write changed (non-default) values to ~/.creepy/ somewhere and load setup from both /usr/share/creepy/ and ~/.creepy/ when using the plugin. See https://lists.debian.org/debian-devel/2005/11/msg00017.html > for some details on the idea. Regards, Ross signature.asc Description: OpenPGP digital signature
Bug#739121: Status of Creepy?
On Sun, 16 Nov 2014 15:25:10 +0100 Ross Gammon wrote: [snip] > > Applying your patch to v1.1 results in this: > ross@debian-sid:~$ creepy > Traceback (most recent call last): > File "/usr/bin/creepy", line 13, in > from PyQt4.QtCore import QString, QThread, SIGNAL, QUrl, QDateTime, > QDate, QRect, Qt > ImportError: No module named PyQt4.QtCore > > So we don't make it to the patched bit :-) > > I can see the latest commits upstream are about QT4, so I will git > rebase on your import of the latest alpha release and try again. > Unfortunately the same error with version 1.2~alpha -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739121: Status of Creepy?
On 11/15/2014 11:48 PM, Petter Reinholdtsen wrote:
[snip]
[dropping Andreas (vacation) & Daniel (previously stated was happy for
someone me to try and move it forward)]
>
> Probably a good idea. Does this untested patch work for you?
>
> --- a/creepy/CreepyMain.py
> +++ b/creepy/CreepyMain.py
> @@ -35,7 +35,12 @@ from utilities import GeneralUtilities
> # set up logging
> logger = logging.getLogger(__name__)
> logger.setLevel(logging.DEBUG)
> -fh = logging.FileHandler(os.path.join(os.getcwd(),'creepy_main.log'))
> +userdir = os.path.expanduser('~/.creepy')
> +try: os.makedirs(userdir)
> +except OSError as e:
> +if e.errno == errno.EEXIST and os.path.isdir(userdir): pass
> +else: raise
> +fh = logging.FileHandler(os.path.join(userdir,'main.log'))
> fh.setLevel(logging.DEBUG)
> formatter = logging.Formatter('%(asctime)s - %(name)s - %(levelname)s -
> %(message)s')
> fh.setFormatter(formatter)
>
I took me a while to get my sid installing machine working again - sorry.
Applying your patch to v1.1 results in this:
ross@debian-sid:~$ creepy
Traceback (most recent call last):
File "/usr/bin/creepy", line 13, in
from PyQt4.QtCore import QString, QThread, SIGNAL, QUrl, QDateTime,
QDate, QRect, Qt
ImportError: No module named PyQt4.QtCore
So we don't make it to the patched bit :-)
I can see the latest commits upstream are about QT4, so I will git
rebase on your import of the latest alpha release and try again.
Cheers,
Ross
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739121: Status of Creepy?
On 11/15/2014 10:38 PM, Petter Reinholdtsen wrote: > > What is the latest development regarding the creepy package in > Debian? I just noticed it did not make it into testing thanks to > this RC bug, and find that really sad. > > What is needed to get the version in > git://anonscm.debian.org/pkg-grass/creepy.git uploaded into > unstable, at least? > Hi Petter, Unfortunately, when you install this version of creepy it does not work. If you install it, and then run the python script you get: ross@debian-sid-install:/usr/share/creepy$ python CreepyMain.py Traceback (most recent call last): File "CreepyMain.py", line 38, in fh = logging.FileHandler(os.path.join(os.getcwd(),'creepy_main.log')) File "/usr/lib/python2.7/logging/__init__.py", line 911, in __init__ StreamHandler.__init__(self, self._open()) File "/usr/lib/python2.7/logging/__init__.py", line 936, in _open stream = open(self.baseFilename, self.mode) IOError: [Errno 13] Permission denied: '/usr/share/creepy/creepy_main.log' The program runs fine from within the source directory. I have not tried to patch creepy to write the log to a better place to see if it is the only problem, but I did contact upstream to tell him of the problem. He seemed to be willing to make try and use a build system and tweak the code so that creepy is more flexible about the installed location. I suggested distutils which would make for a simple d/rules file. Checking upstream again, there does not seem to be many recent commits. There is a constant battle to keep up to date with all the API changes from the services that are used as plugins (instagram etc.). A 1.2 alpha version was uploaded, but the promised final release has not yet appeared. We could try patching CreepyMain.py? Regards, Ross -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#769237: mipp: FTBFS in jessie/i386: Tests failures
On 11/15/2014 06:19 PM, Antonio Valentino wrote: > Hi Ross, hi Lucas, > > On Fri, 14 Nov 2014 22:51:18 +0100 Ross Gammon wrote: >> On 11/14/2014 09:26 PM, Ross Gammon wrote: >> >> >>> I will try once more to build from source in a Jessie VM. I would like >>> to understand what is going on here. >>> >> >> $ apt-get source mipp >> # apt-get build-dep mipp >> $ apt-get --build source mipp >> >> Works fine in a freshly created Jessie VM. >> > > > This issue seems to be related to a precision issue that is triggered > only in particular cases. > I have just pushed to the git repository of > (git.debian.org/git/pkg-grass/mipp.git) of the package a fix for this > issue bacported from upstream. > > Can you please let me know if it works for you? > I can't reproduce the issue on my laptop. > > cheers > Hi Antonio, Whoops - now I read the bug title properly, I see my mistake. I was trying in a Jessie chroot, but not a Jessie "i386" chroot. Sorry about that, and the misleading information as a result. So, this time I tested the build as the repository was yesterday (without pulling your updates) in a jessie "i386" chroot . And the build fails as Lucas found. After pulling your changes, I can confirm that the build succeeds! Thanks for the fast fix Antonio. Before you go for the upload though, lintian complained that the "Closes" part of the d/changelog was missing a colon. Regards, Ross -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#769237: mipp: FTBFS in jessie/i386: Tests failures
On 11/14/2014 09:26 PM, Ross Gammon wrote: > I will try once more to build from source in a Jessie VM. I would like > to understand what is going on here. > $ apt-get source mipp # apt-get build-dep mipp $ apt-get --build source mipp Works fine in a freshly created Jessie VM. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#769237: mipp: FTBFS in jessie/i386: Tests failures
On 11/12/2014 11:17 AM, Lucas Nussbaum wrote: > Source: mipp Version: 0.9.1-1 Severity: serious Tags: jessie sid > User: debian...@lists.debian.org Usertags: qa-ftbfs-20141112 > qa-ftbfs Justification: FTBFS in jessie on i386 > > Hi, > > During a rebuild of all packages in jessie (in a jessie chroot, not > a sid chroot), your package failed to build on i386. > Hmm. I just built mipp in a jessie chroot and it builds fine. > Relevant part (hopefully): >> >> == >> >> FAIL: test_mtsat (test_xrit.Test) >> -- >> >> Traceback (most recent call last): >> File "/«PKGBUILDDIR»/tests/test_xrit.py", line 119, in >> test_mtsat cross_sum, mtsat_sum)) AssertionError: MTSAT image >> reading/slicing failed, wrong cross_sum (11148104.000 != >> 11148074.000) >> >> -- >> >> Ran 9 tests in 1.220s >> >> FAILED (failures=2) ['/«PKGBUILDDIR»/build/lib.linux-i686-2.7', >> '/«PKGBUILDDIR»/tests', '', '/«PKGBUILDDIR»', >> '/usr/lib/python2.7', '/usr/lib/python2.7/plat-i386-linux-gnu', >> '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', >> '/usr/lib/python2.7/lib-dynload', >> '/usr/local/lib/python2.7/dist-packages', >> '/usr/lib/python2.7/dist-packages'] make[1]: *** >> [override_dh_auto_test] Error 1 debian/rules:21: recipe for >> target 'override_dh_auto_test' failed > I will try once more to build from source in a Jessie VM. I would like to understand what is going on here. If all else fails we might have to bypass the failing test. Regards, Ross -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#768216: libgeographic-dev: fails to upgrade from 'wheezy' - trying to overwrite /usr/include/GeographicLib/TransverseMercatorExact.hpp
Control: tags -1 pending On 11/06/2014 02:15 AM, Andreas Beckmann wrote: > during a test with piuparts I noticed your package fails to upgrade from > 'wheezy'. > It installed fine in 'wheezy', then the upgrade to 'jessie' fails > because it tries to overwrite other packages files without declaring a > Breaks+Replaces relation. > > See policy 7.6 at > http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces > >>From the attached log (scroll to the bottom...): > > Selecting previously unselected package libgeographic13. > Unpacking libgeographic13 (from .../libgeographic13_1.37-2_amd64.deb) ... > Selecting previously unselected package libgeographic-dev. > Unpacking libgeographic-dev (from .../libgeographic-dev_1.37-2_amd64.deb) > ... > dpkg: error processing > /var/cache/apt/archives/libgeographic-dev_1.37-2_amd64.deb (--unpack): >trying to overwrite > '/usr/include/GeographicLib/TransverseMercatorExact.hpp', which is also in > package libgeographiclib-dev 1.21-1 > dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) > Errors were encountered while processing: >/var/cache/apt/archives/libgeographic-dev_1.37-2_amd64.deb > Hi Andreas, Thanks for reporting this. I have uploaded a fixed package to d.mentors.net, and I am awaiting sponsorship. Regards, Ross -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#764176: josm-plugins update to fix RC bug
Control: tags -1 help Hi, I have managed to successfully download and import the latest josm-plugin tarball (svn30708). After adjusting all the dependencies to suit the latest version of josm, I failed to get it building. One of the patches did not apply cleanly. It turns out that the part of build-common.xml which was being removed in the previous patch, has now been split into 3 (revision-svn, revision-svn2git & revision-git). I hoped that deleting all 3 in the same way would do the job - but no. My knowledge of ant and it's build system is zero, so it will take me some time to investigate further. Maybe someone else would see the answer faster! I would like to be able to "git push" what I have done so far, but I do not have permissions for pkg-osm. My plan (if I succeeded) was to ask if anyone had any objections switching this package to pkg-grass. Should I create a new respository and stick it there anyway so anyone able to help can jump in? Cheers, Ross PS: In case it helps, the build fails in this way: debian/rules override_dh_auto_clean make[1]: Entering directory `/home/ross/debian/build-area/josm-plugins-0.0.svn30708+ds1' dh_auto_clean -Sant -- -f /home/ross/debian/build-area/josm-plugins-0.0.svn30708+ds1/debian/master.xml Buildfile: /home/ross/debian/build-area/josm-plugins-0.0.svn30708+ds1/debian/master.xml clean: BUILD FAILED /home/ross/debian/build-area/josm-plugins-0.0.svn30708+ds1/debian/master.xml:60: The following error occurred while executing this line: Target "revision" does not exist in the project "colorscheme". It is used from target "dist". Total time: 1 second dh_auto_clean: ant clean -f /home/ross/debian/build-area/josm-plugins-0.0.svn30708+ds1/debian/master.xml returned exit code 1 make[1]: *** [override_dh_auto_clean] Error 1 make[1]: Leaving directory `/home/ross/debian/build-area/josm-plugins-0.0.svn30708+ds1' make: *** [clean] Error 2 dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2 gbp:error: Couldn't run 'git-pbuilder': git-pbuilder returned 2 signature.asc Description: OpenPGP digital signature
Bug#762485: geographiclib: FTBFS on hppa: symbols
severity 762485 important thanks On Wed, 1 Oct 2014 20:12:03 -0400 John David Anglin wrote: > Package: geographiclib Version: 1.37-2 Followup-For: Bug #762485 > > See build log: > http://buildd.debian-ports.org/status/fetch.php?pkg=geographiclib&arch=hppa&ver=1.37-2&stamp=1412084220 > > -- System Information: Debian Release: jessie/sid APT prefers > unreleased APT policy: (500, 'unreleased'), (500, 'unstable') > Architecture: hppa (parisc64) > > Kernel: Linux 3.16.3+ (SMP w/4 CPU cores) Locale: LANG=C, > LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) > Shell: /bin/sh linked to /bin/dash > > Thanks John, I am dropping the severity, as hppa is not a release architecture. But I will hopefully get a new version uploaded in the next few days. Upstream have released a new minor version that fixes some other things that I would like to get into Jessie. Next time I will also check the other ports before uploading with symbol changes! Regards, Ross -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#761629: Quick response from upstream!
Received this today:
Hi Ross,
I'm currently unable to check this issue directly on Debian Unstable,
anyway I discovered in the meanwhile that the same identical problem
affects Debian Testing and Ubuntu 14.04: all them ships wxWidgets 3.0.x
the real cause of this bug is really puzzling: immediately after
selecting the Shapefile path the app will then attempt to identify
the appropriate platform charset name.
the actual code supporting this task is located on libspatialite
in -/src/gaiaaux/gg_utf8.c - gaiaGetLocaleCharset()
on every Linux this simply ends up in calling nl_langinfo(CODESET)
and here happens the puzzling issue: e.g. Fedora (wxGTK-2.8) will
return 'UTF-8' exactly as expected.
Ubuntu wxGTK-3.0 will return insead 'ANSI_X3.4-1968': AFAIK this
simply is an alias name for US-ASCII, anyway it's *not* defined in
the standard list of well-known charsets supported by spatialite_gui
(based on common iconv definitions) and this causes an invalid pointer
to be returned, thus finally causing the reported crash.
counter-check: I've just applied this brutal patch on Main.cpp
near line 280:
- LocaleCharset = wxString::FromUTF8(gaiaGetLocaleCharset());
+ LocaleCharset = wxT("UTF-8");
this seems to succesfully eradicate the crash (indirectly confirming
that the crash cause is to be identified in the crazy charset name
returned bu Ubuntu, and I strongly suspect from Debian as well).
I'm absolutely unaware if this odd issue is caused by Debian/Ubuntu
or by wxGTK-3.0.x; the ubunu shell apparently reports "UTF-8" as
the default charset currently used, and this focuses the strongest
suspects on wxGTK-3.0
surely to be investigated in more depth
bye Sandro
---
And then:
Hi Ross,
there is an interesting follow-up: googling around I've found this
old Debian ticket:
https://lists.debian.org/debian-glibc/2008/08/msg00146.html
so it looks that on Debian (and Debian-derived such as Ubuntu)
"ANSI_X3.4-1968" is the expected default charset name until the
program explicitly asks to import all Locale definitions from
the environment.
after this the charset name will become "UTF-8" as usually expected.
accordingly to all this the most appropriate patch seems to be the
following one (to be placed on the very first line of the Main ctor):
{
//
// main GUI frame constructor
//
+ setlocale(LC_ALL, "");
it's just a suspect of my own, but probably wxGTK-2.8 automatically
performed this task during its own initialization, whilst wxGTK-3.x
doesn't
bye Sandro
signature.asc
Description: OpenPGP digital signature
Bug#761629: spatialite-gui crash reported upstream
Control: tags -1 upstream Due to the upstream ticket tracker not accepting new tickets (problem with website), I have emailed with the problem. Ross signature.asc Description: OpenPGP digital signature
Bug#761629: spatialite-gui confirmed, with full backtrace
Control: tags -1 confirmed I can confirm this crash in unstable. Full backtrace with -dbg package installed: (gdb) bt #0 0x74521084 in std::basic_string, std::allocator >::assign(std::basic_string, std::allocator > const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #1 0x00456854 in operator= (__str=, this=0x7fff9a90) at /usr/include/c++/4.8/bits/basic_string.h:547 #2 operator= (stringSrc=..., this=0x7fff9a90) at /usr/include/wx-3.0/wx/string.h:1883 #3 LoadShpDialog::LoadPKFields (this=this@entry=0x7fffb010) at Dialogs.cpp:2393 #4 0x00457135 in LoadShpDialog::Create (this=this@entry=0x7fffb010, parent=parent@entry=0x92bea0, path=..., table=..., srid=0, column=..., defCs=...) at Dialogs.cpp:2201 #5 0x004a4a26 in MyFrame::OnLoadShp (this=0x92bea0) at Main.cpp:2702 #6 0x75cd51ae in wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #7 0x75e71f08 in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #8 0x75e722f6 in wxEvtHandler::SearchDynamicEventTable(wxEvent&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #9 0x75e7237e in wxEvtHandler::TryHereOnly(wxEvent&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #10 0x75e721c3 in wxEvtHandler::DoTryChain(wxEvent&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #11 0x75e724a5 in wxEvtHandler::ProcessEvent(wxEvent&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #12 0x76a4fe58 in wxWindowBase::TryAfter(wxEvent&) () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0 #13 0x75e72217 in wxEvtHandler::SafelyProcessEvent(wxEvent&) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #14 0x76a24403 in wxToolBarBase::OnLeftClick(int, bool) () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0 #15 0x72e47474 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #16 0x72e61057 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #17 0x72e61efa in g_signal_emit_by_name () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #18 0x72e47474 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #19 0x72e61057 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #20 0x72e619af in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #21 0x733ca735 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #22 0x72e47474 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #23 0x72e61057 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #24 0x72e619af in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #25 0x733c9689 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #26 0x7346b01f in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #27 0x72e47245 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #28 0x72e58e32 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #29 0x72e61255 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #30 0x72e619af in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #31 0x7357b40c in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #32 0x73469774 in gtk_propagate_event () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #33 0x73469beb in gtk_main_do_event () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #34 0x730e303c in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 #35 0x72702c5d in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 ---Type to continue, or q to quit--- #36 0x72702f48 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #37 0x72703272 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #38 0x73468bc7 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #39 0x76825825 in wxGUIEventLoop::DoRun() () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0 #40 0x75d1ace0 in wxEventLoopBase::Run() () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #41 0x75cd7556 in wxAppConsoleBase::MainLoop() () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #42 0x75d722ed in wxEntry(int&, wchar_t**) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0 #43 0x004220e2 in main (argc=1, argv=) at Main.cpp:82 Regards, Ross signature.asc Description: OpenPGP digital signature
Bug#762485: Ready to test
Hi, An updated symbols file has been pushed to Debian GIS repository. Unfortunately I cannot test the change yet because of a build failure due to recent bug in doxygen/libclang: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762959 Regards, Ross -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#762485: geographiclib: FTBFS on 32-bit architectures: symbols not quite as expected
On 09/22/2014 08:42 PM, Aaron M. Ucko wrote: > Source: geographiclib Version: 1.37-1 Severity: serious > Justification: fails to build from source (but built successfully > in the past) > > Builds of geographiclib for all 32-bit architectures have been > failing because they yield different (mangled) symbol names than > expected, as detailed at > > https://buildd.debian.org/status/logs.php?pkg=geographiclib&ver=1.37-1 > > Could you please account for these differences? > > Thanks! Hmmm. The symbols file was created new for this version, so I have probably made a mistake :-( I will be away from my computer for a couple of days, but will take a look when I get back. Ross -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748386: NMU waiting on mentors.net for sponsorship
Hi, I have prepared an NMU and it has been uploaded to mentors.net. The debiff is attached so that it can be incorporated in your next upload (should it get sponsored). Regards, Ross diff -Nru subsurface-4.0.3/debian/changelog subsurface-4.0.3/debian/changelog --- subsurface-4.0.3/debian/changelog 2014-05-05 15:21:27.0 +0200 +++ subsurface-4.0.3/debian/changelog 2014-08-11 20:29:05.0 +0200 @@ -1,3 +1,10 @@ +subsurface (4.0.3-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Remove osmgpsmap as dependency (Closes: #748386) + + -- Ross Gammon Mon, 11 Aug 2014 20:25:14 +0200 + subsurface (4.0.3-2) unstable; urgency=medium * Make sure subsurface builds on all archs (Closes: #738438) diff -Nru subsurface-4.0.3/debian/control subsurface-4.0.3/debian/control --- subsurface-4.0.3/debian/control 2014-02-27 11:55:36.0 +0100 +++ subsurface-4.0.3/debian/control 2014-08-11 20:27:22.0 +0200 @@ -11,7 +11,6 @@ libdivecomputer-dev (>= 0.3.0), libqt4-dev, libqtwebkit-dev, - libosmgpsmap-dev, libgconf2-dev, libtool, libxml2-dev, signature.asc Description: OpenPGP digital signature
Bug#739121: Status of Creepy?
Hi Daniel, Is there any movement on your packaging of Creepy? I can see that your version 1.1 upload to mentors has not been updated, and the version 1.1 that Andreas imported to the pkg-grass git repository on Alioth has also not been updated. Regarding user data and the plugins/addons that a user might install/enable after installation, I know other packages that would use a ".creepy" hidden directory in the user's home directory for this type of thing. As long as the location is in the correct search path, everything should work. Do you know if the upstream project are working on this issue? Regards, Ross -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739117: gpxviewer in Debian
Hi Andrew, I am copying in the bug report so that the status is recorded there if anyone else is investigating the status of gpxviewer (sorry if you get the email twice). I am glad to hear that you are slowly getting there with the new "gir" bindings. And thanks very much for your work on fixing the osm-gps-map bug about the tiles not displaying. I prepared a package for this latest version containing that fix, and I can see that just now Andreas has sponsored its upload! Keep up the good work. Ross On 05/04/2014 09:12 PM, Andrew Gee wrote: Hi Ross, Thanks for getting in touch. I'm currently trying to work on getting gpxviewer back and working in my spare time. Currently it does not work with the latest version of osmgpsmap, due to the use of Gtk 3 introspection. I am currently updating gpxviewer to work this way. Having a few problems, but getting there. I think I may have found a bug with the python bindings or osmgpsmap itself to do with colours of the tracks not being recognised, but I'm going to check this again. Also, osmgpsmap has a new upstream version that fixes a bug where openstreetmap tiles are not being displayed. It could do with an update to 1.0.2. Thanks, Andrew On 03/05/14 19:31, Ross Gammon wrote: Hi Andrew, I see that gpxviewer has been auto-removed from Debian Testing due to a dependency on the old version of osmgpsmap: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739117 It would be a shame if gpxviewer was not a part of the next Debian release. You have not responded to this bug, but I can see on launchpad that you have committed to the osm-gps-map project quite recently in response to another bug. Therefore I thought I would email you directly to ask if you know whether gpxviewer actually works with either 0.7.3 or 1.0.1 of osmgpsmap? This would then be a simple fix for gpxviewer of replacing the dependency of python-osmgpsmap with gir1.2-osmgpsmap-1.0. Unfortunately, when I tried to test this myself, I suffered this bug: https://bugs.launchpad.net/gpxviewer/+bug/1280845 Let me know if I can help in any way. Regards, Ross (I am a new member of the Debian GIS team and looking at bugs in and around osmgpsmap) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#713612: vdpau-video: FTBFS: utils_glx.h:163:5: error: unknown type name 'PFNGLMULTITEXCOORD2FPROC'
Hi, I have fixed the watch file so that uscan finds the latest version of vdpau-video (see attached). According to the changelog in 0.7.4, both the vaBufferInfo, and the libva issue MAY be solved in this new version. Unfortunately, when I imported the tarball and refreshed the patches, the autoreconf patch does not reapply cleanly, and it was a bit beyond my abilities to sort it out. I could not get vdpau-video to build without the patch. Regards, Ross version=3 http://cgit.freedesktop.org/vaapi/vdpau-driver/ snapshot/vdpau-driver-(.+)\.tar\.gz
Bug#736436: [src:gramps] Minimised js files without source
fixed 736436 4.0.3 tags 736436 + pending thanks This bug has been fixed in version 4.0.3 of Gramps. A package of this version has been prepared and is awaiting sponsorship. Regards, Ross Gammon -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736436: [src:gramps] Sourceless file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 retitle 736436 [src:gramps] Minimised js files without source owner 736436 ! thanks I am currently packaging the latest upstream version of Gramps (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720858), and this bug will be addressed as part of that update. Ross -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS6Vm/AAoJEFP+e72miRD8gIYP/i+9HKo1rPVi9DwWN38nD9cM g5ynQtaqlQWogn0ORBgVW6LtRzwZKVJ+Txjemg+Son4Mu1F5EYKQxSw1htmqIOjn j6lJx2cHJBgKLeg4QrqpFMAmQ9klwUhTCt0LBX1I8Q28rbIN5aQK06DfofgTXjBq K1a6bq2yqcBT4PWneXSrt6iEcShbJZp+hvWv5lmBBbjzya6FVe+wJFHmEDLO35Yh d3K1XUSN3WIrJN/vjjX35p9wLFtgX45y7OJJxmgaFUtPhd5QuZ8yalvjixcxcOo2 MbbL9Sn//4EUACf3y9g8RCeey+dcfSj+R9qlhzR8GKLx+QlQKLXm3tsz9Bf6OxfW /mn0ikh+3aUVttYowBwkYOB/qyuS4E4no65sSheCwfIlT6SOMaj7j420Qk6WZfWT 9SfEjd7mIHJMZ1y+40nu0vvvXrMUZzuK7AnyP9X7+AKSdAbGfLhSKMQm+BzNwMvq AY8PkLAqvVyKeLDgu/awENiu5vO6jnNWAOTg6q8dUVnCRvGDIxGHHHAdjtdLQFMf fpVDpo2NBL3IVjUotwmE4GVDWjGJU6PNPfb6CIWeg9CgLjRNiowT0PM/KEF1rghA UP43cfso3zPcuK8nrkM+zwjOokZrhefrxcTAF+qVwW2KjIUPUP99d+54yryoaA3q MrGngQyOkR3ZEukSVEcU =EAOy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683042: Blender: debian/copyright: No information of embedded external libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tag 683042 +patch thanks Wow - is there a license that isn't used in the Blender package! I have attached a patch with an updated copyright file where I have included all copyrights/licenses found in the package. Regards, Ross -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSUJJ6AAoJEFP+e72miRD8mN4P/R9DfzHRDbaXYArnwruWnVRb ytKnDo77KGGBsW5nz9SvDJ2jC8c7r3aEXzysfntgvTjXIArHgaBU6zpdxKpHw2Sb VMLWES1XcnsCu6yORUw4CwHD+EGRDZCgR/gX8YwoVA+9tf0WCP3xlbEPORtyQftx vLro4tkSeZuBHLWSp4pqWtSYSFovqCUfQyNHZtrOlAm7S7KoMQXIgskWe2AG/tmT UWdhvBts4ZReJNx74GKi9+HPpggiEX5dmuM0POu3C46WwkyXSpFg2+3CyIjDuziB gl5ifa/xoyql2paggSTn/lweKVsP6a+f2SO0ZzHCijPni77znNTjppZMZcbbnDvb rqNGSECEvIGZrQaGkCUKe6o54GimgjdWfDchP3hPAhrxoLP7SKDQGeslRzVVoQn/ ByF+8LUkAphIXzaMGHOZZ3hgFl3uxJsLS8EpnDKen538xl5UKwZpKDIHE632f2Yk 8wspnGCuFXQfFlx0POvXN1pzz03XAql8lwmHl35MELdsJ706uJQFU2L/8Y56Y1cO d0q8HcUkOGtpjHFg8RSwq/avZTz/FW5GLjQdiMQxtRtizSB2ZJoHfeweKNGItn2i EMhRLxEFS9kdvuSbHs+gtKgtJW2QjNXQJ2eOJsn3s+BnNQfspcAkdiLSyXwrZ6sz /3boJ1WVRQu+f/Wac9NB =dDlt -END PGP SIGNATURE- >From 552f66c33698379034b9d31f795da1e9979c3228 Mon Sep 17 00:00:00 2001 From: Ross Gammon Date: Sun, 6 Oct 2013 00:11:55 +0200 Subject: [PATCH] Complete update of copyright file to fix #683042 --- debian/copyright | 814 ++- 1 file changed, 811 insertions(+), 3 deletions(-) diff --git a/debian/copyright b/debian/copyright index 756d16c..f5ca688 100644 --- a/debian/copyright +++ b/debian/copyright @@ -4,17 +4,614 @@ Upstream-Author: Blender Foundation Source: http://www.blender.org/ Files: * -Copyright: 2002-2013, Blender Foundation +Copyright: 2001-2013, Blender Foundation + 2001-2002, NaN Holding BV. + 2009, Joshua Leung + 2006-2007, 2009-2012, Nicholas Bishop + 2007, 2009, Janne Karhu + 2011-2012, AutoCRC + 1991, Xerox Corporation + 2006, Peter Schlaile + 1999-2002, David Hodson + 2006, Joseph Eagar + 2007, NVIDIA Corporation + 2009, Google Inc. + 2011, Bastien Montagne + 2002-2003, TNCCI Inc. + 2005, Elsevier Inc. + 1999, Tom Tromey + 2000, Red Hat, Inc. + 2006-2007, University of Dublin, Trinity College + 1989-1993, 1996-1997, Free Software Foundation, Inc. + 2005, Shaun Jackman + 1995, Software Foundation, Inc. + 1990-1998, NeoGeo BV. + 2013, Campbell Barton + 1999, Stephane Popinet + 2000-2004, Bruno Levy + 2001, softSurfer + 1997-2002, Makoto Matsumoto + 1997-2002, Takuji Nishimura + 1996-2000, 2003-2006, Erwin Coumans + 2006-2007, The Zdeno Ash Miklas + 2011, Dan Eicher + 1996-2011, Markus Franz Xaver Johannes Oberhumer + 1996-2000, Paul Sheer + 2009-2010, Mikko Mononen + 2000, Gino van den Bergen + 2009-2011, Jörg Hermann Müller + 2006, 2008, 2011, Peter Schlaile + 2009, Daniel Genrich + 2001, NaN Technologies B.V. + 1997-2001, Id Software, Inc. + 1993-2011, Tim Riker + 2012, Alex Fraser + 2009, Nokia Corporation and/or its subsidiary(-ies) + 2008, Frances Y. Kuo and Stephen Joe + 1999, 2002, Aladdin Enterprises + 2002, Industrial Light & Magic, a division of Lucas + 2009-2010, Sony Pictures Imageworks Inc. + 2003-2006, Erwin Coumans + 2009, www.stani.be + 2001-2006, 2009, Fernando Perez + 2005-2010, Anthony D'Agostino + 2009-2010, Paulo Gomes + 2004-2005, Bruce Merry + 2001-2013, MakeHuman Team + 2010, Fabian Fricke + 2011-2013, Alexander Nussbaumer + 2004-2009, jm soler juillet + 2010, Ken Nign + 2009-2012, Laurea University of Applied Sciences + 2010, Mariano Hidalgo + 2005, Stani Michiels License: GPL-2+ +Files: build_files/cmake/clang_array_check.py +License: Apache-2.0 + +Files: build_files/cmake/Modules/* +Copyright: 2011-2012, Blender Foundation +License: BSD + Unspecified BSD styled license + . + Distributed under the OSI-approved BSD License (the "License"); + see accompanying file Copyright.txt for details. + . + This software is distributed WITHOUT ANY WARRANTY; without even the + implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + See the License for more information. + +Files: build_files/scons/tools/crossmingw.py +Copyright: 2001-2009, The SCons Foundation +License: Expat + +Files: build_files/scons/tools/mstoolkit.py +Copyright: 2004, John Connors +License: Expat + Files: debian/* -Copyright: 2004-2005, Masayuki Hatta
Bug#683042: Blender: debian/copyright: No information of embedded external libraries
Hi, I am looking to join the Multimedia team soon. This bug looked like a nice one to start with for a new chum. Give me a few days, and then hopefully I can attach a patch with a fresh copyright file to the bug for review. Regards, Ross -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
