Bug#1061743: Gramps in Debian

[Ross Gammon]

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

[Ross Gammon]

forwarded 1061743https://gramps-project.org/bugs/view.php?id=13212
thanks

Bug#1061743: Forwarded upstream

[Ross Gammon]

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

[Ross Gammon]

Hi Petter,

Thanks for doing this. Removal from unstable is the right thing to do I 
think.


Regards,

Ross

Bug#916638: Dragonfly is NEW

[Ross Gammon]

tags 916638 + pending
thanks

-- 
Regards,

Ross Gammon
FBEE 0190 904F 1EA0 BA6A  300E 53FE 7BBD A689 10FC



signature.asc
Description: OpenPGP digital signature

Bug#975390: RFS: dragonfly-reverb/3.2.1-1 [ITP] -- Reverb effect plugins (metapackage)

[Ross Gammon]

tag 975390 - moreinfo
thanks

Hi Dennis,

I will take another look over the weekend. Hopefully my gpg key issue is 
sorted out now.


I am on a different machine, so I can't check the exact lintian warning. 
I think it was the "manpage missing" warnings, which have changed name 
and lintian does the divert automatically. I run lintian as a pbuilder 
hook (with all the pedantic options etc.), so it would have been the 
latest lintian in sid at that time. No matter. It is something that can 
be sorted out at the next upload anyway (if required).


Cheers,

Ross

On 25.02.2021 23.57, Dennis Braun wrote:

Hi Ross,

thank you for the review! I think ive fixed everything. I also added 2 
patches to fix cross building and fix building without sse.


about 5., i dont know which new tag you mean. my build on sid didnt 
had a different tag.


and about 12., yeah all plugins should be installed.

Best,
Dennis

Bug#975390: Review of Dragonfly Reverb

[Ross Gammon]

tag 975390 + moreinfo
owner 975390 !
thanks

Hi Dennis,

I have done a review of Dragonfly Reverb and have the following comments:
1. d/changelog - As this is the initial release for Debian, the
changelog entry should just have the one entry closing the ITP bug.
2. d/rules - I don't think we need to export the path prefixes. The
standard build should do the right thing.
3. d/rules - I think we can drop the dh_autobuild overides. dh % should
do the right thing on its own.
4. d/dragonfly-reverb.lintian-overrides - In addition to the note about
the online manuals, I think it would be worth adding to the note in the
override that there are no command line options and the executables
always launch a gui.
5. d/dragonfly-reverb.lintian-overrides - While we are at it, the tag
name has changed for the lintian warning which we could fix.
6. d/control - I don't think mentioning how the gui is built with a
toolkit is useful for a user of the package. I would prefer that the
long description mentions the different types of reverb effects that are
included.
7. d/copyright - The main Files: * part should probably be licensed as
GPL-3+ (not GPL-3). At least this is the case for some files in common/*.
8. d/copyright - Mark Borgerding (kiss_fft) is not mentioned.
9. d/copyright - Attributions for David Robillard, Gabriel M.
Beddingfield, Lars Luthman, Leonard Ritter, Rui Nuno Capela, Stefano
D'Angelo, and Steve Harris for various files in dpf/distrho/src/lv2 seem
to be missing.
10. d/copyright - An attribution for Javier Serrano in
dpf/distrho/src/vestige is missing
11. d/copyright - An attribution for Richard W.E. Furse, Paul
Barton-Davis, Stefan Westerfeld in dpf/distrho/src/ladspa/ladspa.h is
missing.
12. d/copyright - I ran out of time to complete the review of
d/copyright. I recommend a thorough review before uploading. There are
so many bundled effects in the source package. Are they all installed?

-- 
Regards,

Ross Gammon
FBEE 0190 904F 1EA0 BA6A  300E 53FE 7BBD A689 10FC





signature.asc
Description: OpenPGP digital signature

Bug#669908: Do you need a sponsor?

[Ross Gammon]

Hi Thomas,

I see you have uploaded rtpaudio to Debian Mentors several times:
https://mentors.debian.net/package/rtpaudio/

If you would like somebody to review your package, I would recommend
sending a message to the Debian Mentors mailing list, asking for a review.

If you think your package is ready for sponsorship, then I recommend
submitting a separate RFS (Request For Sponsorship) bug using the
template on Debian Mentors (as described here):
https://mentors.debian.net/intro-maintainers/

-- 
Regards,

Ross Gammon
FBEE 0190 904F 1EA0 BA6A  300E 53FE 7BBD A689 10FC



signature.asc
Description: OpenPGP digital signature

Bug#975389: Review of dpf-plugins RFS

[Ross Gammon]

tag 975389 + moreinfo
owner 975389 !
thanks

Hi Dennis,

Thanks for packaging dpf-plugins for Debian. Here is a review:

Need fixing:
d/changelog:
1. This is the initial release in Debian, so the the changelog should be
empty except for the "Initial debian release (Closes: #953129)" entry.
The earlier packaging work for KXStudio & Ubuntu is at least credited in
d/copyright.

d/copyright:
2. The distrho/extra plugins seem to be using the ISC license (not
GPL2+), or at least that is the case for Thread.hpp.
3. dpf/distrho/extra/String.hpp has "Copyright (C) 2004-2008 René
Nyffenegger", and Rene is not listed at all in d/copyright.
4. I stopped checking the d/copyright file here. I recommend a thorough
check of d/copyright to ensure the package passes smoothly through the
ftp-master review.

Minor/optional stuff:
5. d/dpf-plugins-vst.lintian-overrides (and for the lv2, ladspa & dssi
packages):
"splitted" is not grammatically correct, and the lintian output should
not be overriden, but a patch sent upstream. "3 Band Equalizer, split
output version" would be better.
6. dpf-plugins-common emits a lintian warning about "no-manual-page" for
the binaries. I tried a couple of them and they seem to open gui's and
the normal -h & -v options do nothing. Maybe we could check the others
and override the warning?

Other comments:
7. I see version 1.4 is now available upstream. If you prefer, we could
update to a full release rather than the "1.3 plus git commit" we have
at the moment.

I would be happy to upload with at least the first four comments fixed!

Regards,

Ross
FBEE 0190 904F 1EA0 BA6A  300E 53FE 7BBD A689 10FC



signature.asc
Description: OpenPGP digital signature

Bug#979274: Sfizz Review

[Ross Gammon]

n-outside-usr-share-doc
usr/lib/vst3/sfizz.vst3/gpl-3.0.txt
I: sfizz: spelling-error-in-binary usr/bin/sfizz_jack helpfull helpful
P: sfizz source: co-maintained-package-with-no-vcs-fields
X: sfizz source: debian-watch-does-not-check-gpg-signature
P: sfizz: image-file-in-usr-lib
usr/lib/lv2/sfizz.lv2/Contents/Resources/background.png
P: sfizz: image-file-in-usr-lib
usr/lib/lv2/sfizz.lv2/Contents/Resources/backgro...@2x.png
P: sfizz: image-file-in-usr-lib
usr/lib/lv2/sfizz.lv2/Contents/Resources/icon_white.png
P: sfizz: image-file-in-usr-lib
usr/lib/lv2/sfizz.lv2/Contents/Resources/icon_wh...@2x.png
P: sfizz: image-file-in-usr-lib
usr/lib/lv2/sfizz.lv2/Contents/Resources/knob48.png
P: sfizz: image-file-in-usr-lib
usr/lib/lv2/sfizz.lv2/Contents/Resources/kno...@2x.png
P: sfizz: image-file-in-usr-lib
usr/lib/lv2/sfizz.lv2/Contents/Resources/logo.png
P: sfizz: image-file-in-usr-lib
usr/lib/lv2/sfizz.lv2/Contents/Resources/logo_text.png
P: sfizz: image-file-in-usr-lib
usr/lib/lv2/sfizz.lv2/Contents/Resources/logo_t...@2x.png
P: sfizz: image-file-in-usr-lib
usr/lib/lv2/sfizz.lv2/Contents/Resources/logo_text_white.png
P: sfizz: image-file-in-usr-lib
usr/lib/lv2/sfizz.lv2/Contents/Resources/logo_text_wh...@2x.png
P: sfizz: image-file-in-usr-lib
usr/lib/vst3/sfizz.vst3/Contents/Resources/background.png
P: sfizz: image-file-in-usr-lib
usr/lib/vst3/sfizz.vst3/Contents/Resources/backgro...@2x.png
P: sfizz: image-file-in-usr-lib
usr/lib/vst3/sfizz.vst3/Contents/Resources/icon_white.png
P: sfizz: image-file-in-usr-lib
usr/lib/vst3/sfizz.vst3/Contents/Resources/icon_wh...@2x.png
P: sfizz: image-file-in-usr-lib
usr/lib/vst3/sfizz.vst3/Contents/Resources/knob48.png
P: sfizz: image-file-in-usr-lib
usr/lib/vst3/sfizz.vst3/Contents/Resources/kno...@2x.png
P: sfizz: image-file-in-usr-lib
usr/lib/vst3/sfizz.vst3/Contents/Resources/logo.png
P: sfizz: image-file-in-usr-lib
usr/lib/vst3/sfizz.vst3/Contents/Resources/logo_text.png
P: sfizz: image-file-in-usr-lib
usr/lib/vst3/sfizz.vst3/Contents/Resources/logo_t...@2x.png
P: sfizz: image-file-in-usr-lib
usr/lib/vst3/sfizz.vst3/Contents/Resources/logo_text_white.png
P: sfizz: image-file-in-usr-lib
usr/lib/vst3/sfizz.vst3/Contents/Resources/logo_text_wh...@2x.png
P: sfizz source: package-does-not-install-examples
editor/external/vstgui4/vstgui/standalone/examples/
P: sfizz source: silent-on-rules-requiring-root
P: sfizz source: source-contains-autogenerated-visual-c++-file
vst/external/VST_SDK/VST3_SDK/public.sdk/source/vst/aaxwrapper/resource/aaxwrapper.rc
X: sfizz source: upstream-metadata-file-is-missing

Let us know on the list if you need any help to improve things.

-- 
Regards,

Ross Gammon
FBEE 0190 904F 1EA0 BA6A  300E 53FE 7BBD A689 10FC



signature.asc
Description: OpenPGP digital signature

Bug#976113: Closing Hydrogen RFS

[Ross Gammon]

Hi Nicholas,

On 07.01.2021 23.44, Nicholas D Steeves wrote:

Have you created the release tag on your local master branch, or shall
I, and would you like to push the tag when the package is accepted, or
would you like me to remember to do so?


I normally wait until it is accepted by the ftp-masters. Feel free to 
ping me on private mail.

Bug#954823: Hydrogen is NEW

[Ross Gammon]

tag 954823 + pending
tag 960539 + pending
thanks

Tagging these bugs as pending as Hydrogen has been uploaded and is
sitting in the NEW queue.

-- 
Regards,

Ross Gammon
FBEE 0190 904F 1EA0 BA6A  300E 53FE 7BBD A689 10FC



signature.asc
Description: OpenPGP digital signature

Bug#976113: RFS Review for Hydrogen

[Ross Gammon]

Hi Sebastian,

On 07/01/2021 11:06, Sebastian Ramacher wrote:
> The *.desktop and appdata files belong to the package that provides the
> executable (except for some corner cases). In particular, having the
> appdata file in hydrogen-data instructs the consumers of those files to
> install hydrogen-data if somebody wants to install hydrogen. They are
> non-functional if installing hydrogen-data without also installing
> hydrogen. So please move them to hydrogen.

Good point - well made.

Don't worry Nicholas. I can take care of that to avoid another mentors
upload round trip.

-- 
Regards,

Ross Gammon
FBEE 0190 904F 1EA0 BA6A  300E 53FE 7BBD A689 10FC



signature.asc
Description: OpenPGP digital signature

Bug#976113: RFS Review for Hydrogen

[Ross Gammon]

Hi Nicholas,

On 06/01/2021 18:12, Nicholas D Steeves wrote:
> Hi Ross,
> 
> Sorry for the delay, so tired and busy here!
>

Me too!

> Ross Gammon  writes:
> 
>> Please note, I was not able to do a test installation to check hydrogen
>> is working. I hope you can confirm that.
>>
> 
> I can confirm it works for everything I use it for, but unfortunately I
> don't have any midi gear to test midi-related functionality.
> 
>> Blocking upload:
>> 1. The package fails to build twice in a row (I used the --twice option
>> in pdebuild). It appears some translation files are not being cleaned
>> after the first build.
>>
> 
> Thank you for spotting this.  I've activated a build hook to catch cases
> like this in the future.  Fixed, and fixed an assumption I had made
> about the translations.
> 
>> Minor things:
>> 1. We could enable Salsa CI by adding a debian/salsa-ci.yml file.
> 
> We could, but I don't think Hydrogen's test is significant enough to
> make it worthwhile to spin up an instance every time someone pushes to
> the repo (cost of resources, and cost of carbon footprint).

No problems. But you also get other tests like reproducibility and
piuparts tests for free, which you should otherwise do manually to avoid
issue with an upload. :-)

> 
>> 2. I think the copyright-hints & check files can be removed as they were
>> used by cdbs?
> 
> Done, queued for the source-only -2 upload
> 
>> 3. The github issues page could be added to the upstream metadata
>> file.
> 
> Is this user facing?  I have been specifically omitting this from my
> packages, because I worry that it will make it more convenient for the
> user to click and report upstream, despite "Don't file bugs upstream" 
> (https://www.debian.org/Bugs/Reporting).

Yes, there are a few public facing tools that use this information. And
I always think a report in the wrong place is better than no report :-)

> 
>> 4. I am not sure what is going on with the icon. There is a lot going on
>> in d/rules and also a patch. This is probably something that should be
>> sorted out upstream. As a minimum we should probably forward our patch
>> upstream or tag the patch as "Forwarded: not-needed" if it is not an
>> upstream issue. I note that in Ubuntu, they install an svg into the
>> pixmaps folder.
> 
> Yeah, it's confusing to me too, and yes, ought to be solved upstream.
> The png (erroneously named as a bmp) is used internally for something,
> and I'm not sure using the svg in that context would succeed, but it
> seems like it ought to be.  The SVGs we install are:
> 
> usr/share/hydrogen/data/img/gray/h2-icon.svg
> usr/share/hydrogen/data/img/gray/icon.svg
> usr/share/hydrogen/data/img/gray/warning.svg
> usr/share/icons/hicolor/scalable/apps/org.hydrogenmusic.Hydrogen.svg
> 
>> 5. Patch 2001 should probably be tagged as "Forwarded: not-needed" as it
>> seems Debian specific.
> 
> Done.  Queued for -2.
> 
>> 6. I see that even with all hardening options enabled in d/rules, we
>> still get the "hardening no fortify" lintian error. Are there some flags
>> not being passed to the build system?
> 
> Possibly.  I will investigate and plan to solve this for -2.
> 
>> 7. I see the large number of commits to add library packages and upload
>> pre-release versions has resulted in some churn in the changelog. I
>> think some entries can be removed now that we have agreed to upload a
>> simpler structure and because it is a proper release (e.g. disabling the
>> documentation)?
>>
> 
> I believe I cut the bin:lib-pkg ones, but I see I missed the docs ones.
> Fixed.
> 
>> Suggestions/Considerations:
>> 1. It is worth taking a look at the version of hydrogen uploaded in
>> Ubuntu by Erich Eickmeyer. By adding ladspa-sdk and libtar as build
>> dependencies (and a patch), it appears that the hydrogen builds with
>> extra options.
> 
> I considered enabling new features, but chose to change the package as
> little as possible, because we're so late in the bullseye cycle.  I'm of
> course open to enabling them if someone else will thoroughly test the
> features.
> 
>> Erich also switched the jack dependency to jack2.
> 
> When building with libjack-dev, debhelper should indirectly generate a
> dependency on libjack-jackd2-0 | libjack-0.125.  My rational for not
> switching is that I'm aware of users of older Firewire interfaces who
> prefer (or need) jack and not jack2.  I also asked #debian-multimedia
> for confirmation that sticking with jack was consistent with team policy
> and received a firm statement to not switch to bui

Bug#976113: RFS Review for Hydrogen

[Ross Gammon]

Hi Nicholas,

Good stuff. I think we are just about ready to upload. Here are the
comments from my review.

Please note, I was not able to do a test installation to check hydrogen
is working. I hope you can confirm that.

Blocking upload:
1. The package fails to build twice in a row (I used the --twice option
in pdebuild). It appears some translation files are not being cleaned
after the first build.

Minor things:
1. We could enable Salsa CI by adding a debian/salsa-ci.yml file.
2. I think the copyright-hints & check files can be removed as they were
used by cdbs?
3. The github issues page could be added to the upstream metadata file.
4. I am not sure what is going on with the icon. There is a lot going on
in d/rules and also a patch. This is probably something that should be
sorted out upstream. As a minimum we should probably forward our patch
upstream or tag the patch as "Forwarded: not-needed" if it is not an
upstream issue. I note that in Ubuntu, they install an svg into the
pixmaps folder.
5. Patch 2001 should probably be tagged as "Forwarded: not-needed" as it
seems Debian specific.
6. I see that even with all hardening options enabled in d/rules, we
still get the "hardening no fortify" lintian error. Are there some flags
not being passed to the build system?
7. I see the large number of commits to add library packages and upload
pre-release versions has resulted in some churn in the changelog. I
think some entries can be removed now that we have agreed to upload a
simpler structure and because it is a proper release (e.g. disabling the
documentation)?

Suggestions/Considerations:
1. It is worth taking a look at the version of hydrogen uploaded in
Ubuntu by Erich Eickmeyer. By adding ladspa-sdk and libtar as build
dependencies (and a patch), it appears that the hydrogen builds with
extra options. Erich also switched the jack dependency to jack2.
2. I see we have added a lintian override for the desktop and appdata
files not being in the same package as the executable. Is there a reason
for not just installing the desktop/appdata files with the executable
instead of in -data?

-- 
Regards,

Ross Gammon
FBEE 0190 904F 1EA0 BA6A  300E 53FE 7BBD A689 10FC



signature.asc
Description: OpenPGP digital signature

Bug#976113: Bug#954823: Sponsorship of hydrogen

[Ross Gammon]

Hi Nicholas,

Dropped one of the bugs from "To:" (leaving only the RFS copied in).

On 30/12/2020 00:55, Nicholas D Steeves wrote:
> Hi Ross,
>
> Ross Gammon  writes:
>
>> I have spent some time going through the commit messages. There has
>> been a lot of work done!
> Yes :-)  If I remember correctly, cdbs -> dh, and upstream churn between
> prereleases was the worst of it.
>
>
> Will do!  The WIP branch is called "rfs-976113-rebase" and I pushed it
> just now; it doesn't contain much yet.  I will update mentors as soon as
> we have an upload candidate (still too many outstanding big issues at
> this time).

>> I was wondering why the library packages suddenly appeared. I think if
>> it is possible, it is best to stick to the old packages. What
>> applications would want to use hydrogen as a library?
>>
> Hypothetical 3rd party plugins, I think?  Unfortunately even with
> -DWANT_SHARED=OFF we still end up with libhydrogen-core-1.0.1.a, which
> appears to have not been installed in the 0.9.7 series of Debian
> packages.  I can whitelist and ignore it, but for comparison to other
> distributions, OpenSUSE chose to ship the lib:
>
> https://software.opensuse.org/package/libhydrogen-core0 (for 0.9.7)
> https://software.opensuse.org/package/libhydrogen-core1 (for 1.0.1)
>
> Also, I'm also not sure if there is any practical benefit to
> hydrogen-dev (hypothetical plugin development), so I'm wondering if the
> headers should not be installed; they weren't installed in the last
> release (0.9.7-6).  Hydrogen-dev_1.0.1-1_all.deb is only 84KB, so could
> be merged into libhydrogen-core-1.0.1.  Sebastinas says the -dev package
> is arch-specific, and if that's the case it seems like merging the -dev
> package into bin:libhydrogen-core-1.0.1 would be reasonable.
>
> There is something to be said the principle of least surprise when
> moving between distributions, but I don't have a position on way or the
> other.
>
> At this time we can also reassess the hydrogen and hydrogen-data split.
> If I was packaging Hydrogen from scratch I'm not sure that I would split
> them...
>
> Finally, if we maintain the split, what is your position on .desktop and
> appdata files?  Should they go in bin:hydrogen-data, or in bin:hydrogen?

OK - I think we are a bit too close to the next Debian release to be
making things complicated. Maintaining a library complicates upgrades to
new versions if transitions are required, and can be problematic if the
the ABI is not stable. I don't know how stable the hydrogen library is.
Why don't we just stick to how it was structured before it was removed?
That way users of Hydrogen in making music (like me) can just use the
application like they used to.

We have to go through the NEW queue to get hydrogen into the next
release, so making the ftp-master review as simple as possible (with a
rock solid copyright file) is the least risky approach.

I think the main reason for splitting stuff out into a *-data package is
to split the architecture dependent files from the architecture
independent files. When looking at the contents of the old hydrogen
package, you could question some of the decisions between the -data and
-doc packages.

Maybe after the release we can think about helping developers of
potential plugins, and moving files around between packages? That is
unless the previous structural decisions contributed to any bugs!

We can always backport new versions for users of Debian stable after the
release if there is a demand.



>
> I've reopened this list of bugs.
>
>> Let me know when the new version is available on mentors.
>>
> Will do!  I'd just want to take care of the major design decisions
> first.
>
> Cheers,
> Nicholas

Cheers,

Ross




signature.asc
Description: OpenPGP digital signature

Bug#954823: Sponsorship of hydrogen

[Ross Gammon]

Hi Nicholas,

I have spent some time going through the commit messages. There has been
a lot of work done!

On 29/12/2020 17:29, Nicholas D Steeves wrote:
> Hi Ross!
>
> Ross Gammon  writes:
>
>> owner 954823 rossgam...@debian.org
>> thanks
>>
>> Hi Nicholas,
>>
>> I am happy to take a look at hydrogen, and sponsor it. I have some spare
>> time over the next few days.
>>
> Thank you, I really appreciate this! :-D  Here are some notes and
> questions:
>
> Will you be sponsoring from git or mentors?  How would you like me to
> work during the WIP cycles of the review?  The git history will look a
> bit silly and confusing with too many "refinalise for release to
> unstable" commits ;-)

I can do either. But I think in this case, I would prefer to work from
mentors (mainly because I have problems with my gbp setup on this
computer). But please also keep the git repository in sync (even if it
is on a different branch that we can merge later).

Actually, I would like to compliment you on your commit messages. It was
pleasing to see a verbose reason for the change, instead of some short
cryptic message that just generates more questions.

I think it is best to keep a record of the review in the RFS bug. So I
have cc'd the RFS bug (sorry - I did not spot it when I started), and we
can continue the discussion there.

>
> On #debian-multimedia, Sebastinas did a preliminary review, and two big
> issues were:
>
> 1. override_dh_auto_build had a typo! "override_override_dh_auto_build"
>*   I've fixed this locally
> 2. I was missing an override_dh_auto_configure to make use of
>$DEB_CMAKE_EXTRA_FLAGS
>* I believe that is why the extra lib and dev packages became
>  necessary.  Now that I know what was causing the problem I can
>  restore something closer to the old packaging.
>* Changing this in the future will require another trip through NEW,
>  so what do you think the correct split of the package is?

I was wondering why the library packages suddenly appeared. I think if
it is possible, it is best to stick to the old packages. What
applications would want to use hydrogen as a library?


> 3. override_dh_auto_clean failed to run "dh_auto_clean".  Oops :-/

This might explain why I found that the package failed to build twice in
a row for me.


> I've already make local fixes for these and other issues, but will delay
> pushing until I receive your preference regarding the shared lib and dev
> packages.  I'm of course open to fixing other issues and removing
> anything you consider vestigial to the old cdbs packaging (I chose the
> more labour-intensive approach rather than clean packaging)!
>
>> Have you reopened any bugs that were closed when the package was removed?
>> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-packages
>>
> I have not yet reopened any bugs.  The list of -rm bugs is:
>   945042 642014 629105 870395 794042 586087 874907 347279 945042
>
> There seem to be differences in perspective about when/if these bugs
> should be reopened.  My preference is to maintain a strong link between
> the changelog and BTS, for future reference, and for future
> maintainers.  Given "changelog closes bugs in wrong way", I feel like
> reopening the bugs that will be closed by the yet-to-be-uploaded
> changelog entry is the correct approach, because it creates a strong
> link between the changelog and BTS.

I think the best thing is to reopen the bug and then close them in the
changelog once it is confirmed that they are closed. That way they are
closed with the right version information. The most important thing is
to ensure that bugs that are not fixed in the new version remain open.

Let me know when the new version is available on mentors.

Ross




signature.asc
Description: OpenPGP digital signature

Bug#954823: Sponsorship of hydrogen

[Ross Gammon]

owner 954823 rossgam...@debian.org
thanks

Hi Nicholas,

I am happy to take a look at hydrogen, and sponsor it. I have some spare
time over the next few days.

Have you reopened any bugs that were closed when the package was removed?
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-packages

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#974693: RFP: studio-controls -- small application to allow setting up audio for (semi)pro-audio work

[Ross Gammon]

Package: wnpp
Version: 2.0.9
Severity: wishlist
Upstream Author:Len Ovenwerks  
URL: https://github.com/ovenwerks/studio-controls
License: GPL-2
Description: small application to allow setting up audio for (semi)pro-audio 
work

 The application first checks to see if application will have access to
 memory locking and real time priorities. If not, a warning is displayed
 and a checkbox allows repairing this. After repairing this the user needs
 to log out and back in for the new setting to have effect, there is
 a warning to this effect.
 .
 It is assumed that jack will run at session start and not be stopped till
 session end. However, it is possible to override this.
 .
 USB mics have started to make their way into bedroom studios and have been
 a problem with jack or ALSA oriented audio applications which expect
 to work with only one audio device. The user expects to use their USB
 mic for input and internal audio for monitoring. These two devices have
 no way of being in sync with each other and in most cases cannot be
 used together. This application allows setting one jack device and adding
 a second device as a jack client via zita-ajbridge.



signature.asc
Description: OpenPGP digital signature

Bug#974692: RFP: spleeter -- Source separation library including pretrained models

[Ross Gammon]

Package: wnpp

Version: 1.4.0

Severity: wishlist

Upstream Author: deezer

URL: https://github.com/deezer/spleeter

License: MIT

Description: Source separation library including pretrained models

 Spleeter is the Deezer source separation library with pretrained models
 written in Python and uses Tensorflow. It makes it easy to train source
 separation model (assuming you have a dataset of isolated sources), and
 provides already trained state of the art model for performing various
 flavour of separation :
 * Vocals (singing voice) / accompaniment separation (2 stems)
 * Vocals / drums / bass / other separation (4 stems)
 * Vocals / drums / bass / piano / other separation (5 stems)
 2 stems and 4 stems models have state of the art performances on the
 musdb dataset. Spleeter is also very fast as it can perform separation
 of audio files to 4 stems 100x faster than real-time when run on a GPU.
 We designed Spleeter so you can use it straight from command line as
 well as directly in your own development pipeline as a Python library.




signature.asc
Description: OpenPGP digital signature

Bug#766424: Update bug tags

[Ross Gammon]

tag 766424// + moreinfo upstream
thanks

Bug#939951: Link upstream bug

[Ross Gammon]

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#936463: python3-ecasound: Upstream are working on Python 3 support

[Ross Gammon]

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

[Ross Gammon]

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

[Ross Gammon]

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

[Ross Gammon]

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#944862: RM: laditools/oldstable -- ROM; Python 2 removal, dead upstream

[Ross Gammon]

retitle 944862 RM: laditools/unstable -- ROM; Python 2 removal, dead upstream
thanks

Hi Adam,

On 11/16/19 4:56 PM, Adam D. Barratt wrote:
> 
> I assume you didn't really mean oldstable, as the subject suggestions,
> as Python 2 removal really isn't relevant there.
> 
> Regards,
> 
> Adam
> 

You are correct - sorry - I meant unstable

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#944862: RM: laditools/oldstable -- ROM; Python 2 removal, dead upstream

[Ross Gammon]

Package: ftp.debian.org
Severity: normal

Laditools is dead upstream, and Alessio Treglia who forked it previously is no
longer as active as he used to be.

The package is python 2, and would need to be ported to python 3 to survive in
Debian.

However, laditools is becoming less relevant for Linux Audio as other tools are
developed (e.g. the KX Studio tools).

Bug#943419: RFA: python-requests-toolbelt -- Utility belt for advanced users of python-requests

[Ross Gammon]

Package: wnpp
Severity: normal

We request an adopter for the python-requests-toolbelt package.

The package description is:
 Collection of utilities for python-requests
 It provides transport adapters: FingerprintAdapter, SSLAdapter,
 SourceAddressAdapter, SocketOptionsAdapter, TCPKeepAliveAdapter

Petter and I both no longer have need for the package as it was package as a
dependency for creepy which is no longer in the archive.

It has picked up a few other reverse dependencies since though, so the package
is used.

The old Alioth git repository can be found archived here:
https://alioth-archive.debian.org/git/collab-maint/

It could be a good package for a new-comer to pick up. Perhaps as part of the
Debian Python Modules Team?

Regards,

Ross Gammon

Bug#938141: python-requests-toolbelt: diff for NMU version 0.8.0-1.1

[Ross Gammon]

Hi both,

On 10/15/19 7:44 AM, Petter Reinholdtsen wrote:
> [Sandro Tosi]
>> I've prepared an NMU for python-requests-toolbelt (versioned as
>> 0.8.0-1.1) and uploaded it to DELAYED/7. Please feel free to tell me
>> if I should delay it longer.
> Thank you very much!
>
> Perhaps you could like to become a co-maintainer or take over the
> package?  The source git repo should be imported into Salsa and a new
> maintainer upload should be done with your fixes.
>
> I uploaded python-requests-toolbelt into Debian to get
> https://tracker.debian.org/pkg/creepy > working, but creepy has
> since been removed because its upstream no longer maintained it.
>
Same here. I no longer have need for the package. I was thinking of
seeing if the Python Modules team wanted to pick it up. I am no longer a
member of the team after the Salsa migration, and I am a bit too busy to
reapply.

Petter,

Maybe we should do an RFA bug and see if a new contributor wants to pick
it up? I am on my Ubuntu machine at the moment and I get:

$ apt-cache rdepends python3-requests-toolbelt
python3-requests-toolbelt
Reverse Depends:
  vdirsyncer
  python3-acme
  twine
  snapcraft
  python3-zeep
  python3-jira
  python3-flickrapi
  python3-bioblend
  python3-pylxd

I will do that if you agree.

Regards,

Ross

Bug#875038: [lmms] Future Qt4 removal from Buster

[Ross Gammon]

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#681902: calf-plugins: disabling compressor generates horrible distortion

[Ross Gammon]

tags 681902 unreproducible moreinfo
thanks

Hi Jonas,

I am just doing an update to calf-plugins and tried to reproduce this
bug without success.

Version 0.0.18.6-5 is no longer in the archive, and I tested with 0.90.1-2.

But maybe I am not disabling the compressor the same way. I exited calf
whilst compressing a signal, and I also disconnected inputs whilst
compressing a signal. I did not hear any distortion.

Maybe it was fixed sometime after 18.6? I can't find any mention in the
upstream bug tracker.

Do you think we can close this?

Ross



signature.asc
Description: OpenPGP digital signature

Bug#925551: lintian: desktop-command-not-in-package - plugin where host command is executed

[Ross Gammon]

Hi Chris,

On 3/26/19 7:03 PM, Chris Lamb wrote:
> tags 925551 + moreinfo
> thanks
> 
> Hi Ross,
> 
>> To avoid a warning in this case, could lintian check if a package with a
>> similar name to the command exists as a dependency to the package with the
>> desktop file?
> 
> My worry is that this would make this check a little bit too "magical",
> especially when weighed up against providing an override for what I
> believe to be a somewhat rare case. What do you think?
> 
> 
> Regards,
> 

I thought it might be tricky, bug decided to report it in case you could
do magic :-)

There was a similar bug about the executable being in a different
package (update-alternatives).

It is the first time I have come across the issue. But there might be
other plugin type cases. Looking at the lintian website, there are lots
of overrides, and soon to be one more.

Thanks for the fast response. Feel free to close the bug.

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#925551: lintian: desktop-command-not-in-package - plugin where host command is executed

[Ross Gammon]

Package: lintian
Version: 2.5.81ubuntu1
Severity: normal

Dear Maintainer,

Hexter is a package I am working on that runs as a plugin, and the desktop file
executes the host (dssi-host-jack) with hexter as an a further option in the
command (Exec=jack-dssi-host hexter.so).

https://salsa.debian.org/multimedia-team/hexter

To avoid a warning in this case, could lintian check if a package with a
similar name to the command exists as a dependency to the package with the
desktop file?

Regards,

Ross



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

Kernel: Linux 4.15.0-46-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils  2.30-21ubuntu1~18.04
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1build1
ii  dpkg  1.19.0.5ubuntu2.1
ii  file  1:5.32-2ubuntu0.2
ii  gettext   0.19.8.1-6ubuntu0.1
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33build1
ii  libarchive-zip-perl   1.60-1ubuntu0.1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdpkg-perl  1.19.0.5ubuntu2.1
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1build3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.1-6ubuntu0.3
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.73-1
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.69+repack-1
ii  man-db2.8.3-2ubuntu0.1
ii  patchutils0.3.4-2
ii  perl  5.26.1-6ubuntu0.3
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1build3

Versions of packages lintian suggests:
ii  binutils-multiarch 2.30-21ubuntu1~18.04
ii  dpkg-dev   1.19.0.5ubuntu2.1
ii  libhtml-parser-perl3.72-3build1
ii  libtext-template-perl  1.47-1

Bug#923725: lintian: Spelling - false positive for "itialize"

[Ross Gammon]

tags 923725 - moreinfo
thanks

Hi Chris,

On 3/4/19 2:52 PM, Chris Lamb wrote:
> tags 923725 + moreinfo
> thanks
> 
> Hi Ross,
> 
>> Whilst working on the Carla package, I got false positives for the word
>> "itialize".
> 
> Please could you paste the the exact output that you get from Lintian?
> There are a number of spelling-related tags and it is unclear which you
> are referring to here.
> 
> Also, I cannot find your package in Debian to potentially reproduce.
> Is it available somewhere?
> 
> 
> Regards,
> 

Whoops - I remember copying it to the clipboard:
I: carla-bridge-linux64: spelling-error-in-binary
usr/lib/carla/carla-bridge-posix64 itialize initialize
I: carla-bridge-linux64: spelling-error-in-copyright GNU Lesser Public
License GNU Lesser General Public License
I: carla-vst: spelling-error-in-copyright GNU Lesser Public License GNU
Lesser General Public License
I: carla: spelling-error-in-binary usr/lib/carla/carla-bridge-native
itialize initialize
I: carla: spelling-error-in-binary usr/lib/carla/libcarla_standalone2.so
itialize initialize

It is a new package that we are working on for Ubuntu Studio. We hope to
upload it there and follow up with a Debian upload after Buster is
released. I didn't want to burden the NEW queue at this stage ;-)

You can find the packaging here (I haven't pushed the latest changes -
it is a work in progress):
https://code.launchpad.net/~ubuntustudio-dev/carla/+git/carla

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#923725: lintian: Spelling - false positive for "itialize"

[Ross Gammon]

Package: lintian
Version: 2.5.81ubuntu1
Severity: minor

Dear Maintainer,

Whilst working on the Carla package, I got false positives for the word
"itialize". The actual string is in all cases "initialize" which is the very
string that lintian suggests as a replacement.

carla$ grep "itialize" -riH *
data/carla-single:# Initialize variables to null
data/windows/unzipfx-carla-control/ebcdic.h:   by the translation code
portions.  They may get initialized at program
data/windows/unzipfx-carla-control/zipinfo.c:G.pInfo = G.info;   /*
(re-)initialize, (just to make sure) */
data/windows/unzipfx-carla-control/extract.c:/* a) initialize the CRC table
pointer (once) */
data/windows/unzipfx-carla-control/extract.c:Initialize variables, buffers,
etc.
data/windows/unzipfx-carla-control/globals.c:  Routines to allocate and
initialize globals, with or without threads.
data/windows/unzipfx-carla-control/process.c:/* Initialize UnZip's built-in
pseudo hard-coded "ISO <--> OEM" translation,
data/windows/unzipfx-carla-control/process.c:Initialize the internal flag
holding the mode of processing "overwrite
data/windows/unzipfx-carla-control/process.c:   stream, the "U" is not a very
good escape initializer. Therefore, we
data/windows/unzipfx-carla-control/win32/win32.c:/* The milliseconds field
gets always initialized to 0. */
data/windows/unzipfx-carla-control/win32/win32.c:if (!G.notfirstcall) {  /*
first call:  must initialize everything */
data/windows/unzipfx-carla-control/win32/win32.c:Initialize various
pointers and counters and stuff.
data/windows/unzipfx-carla-control/win32/win32.c:*pathcomp = '\0';
/* initialize translation buffer */
data/windows/unzipfx-carla-control/win32/win32.c:INIT:  allocate and
initialize buffer space for the file currently being
data/windows/unzipfx-carla-control/win32/nt.c:static BOOL Initialize(VOID);
data/windows/unzipfx-carla-control/win32/nt.c:volatile BOOL bInitialized =
FALSE; /* module level stuff initialized? */
data/windows/unzipfx-carla-control/win32/nt.c:static BOOL Initialize(VOID)
data/windows/unzipfx-carla-control/win32/nt.c:if (bInitialized) return
TRUE;
data/windows/unzipfx-carla-control/win32/nt.c:return bInitialized;
data/windows/unzipfx-carla-control/win32/nt.c:if (!bInitialized) {
data/windows/unzipfx-carla-control/win32/nt.c:/* initialize module
level resources */
data/windows/unzipfx-carla-control/win32/nt.c:
InitializeCriticalSection(  );
data/windows/unzipfx-carla-control/win32/nt.c:bInitialized = TRUE;
data/windows/unzipfx-carla-control/win32/nt.c:if(!bInitialized)
if(!Initialize()) return FALSE;
data/windows/unzipfx-carla-control/win32/nt.c:if(!bInitialized)
if(!Initialize()) return FALSE;
data/windows/unzipfx-carla-control/unzip.c:/* initialize international char
support to the current environment */
data/windows/unzipfx-carla-control/unzip.c:/* initialize Unicode */
data/windows/unzipfx-carla-control/unix/unix.c:if (!G.notfirstcall) {  /*
first call:  must initialize everything */
data/windows/unzipfx-carla-control/unix/unix.c:/* initialized to 0 for
check in "default" branch below... */
data/windows/unzipfx-carla-control/unix/unix.c:Initialize various pointers
and counters and stuff.
data/windows/unzipfx-carla-control/unix/unix.c:return MPN_NOMEM;
/* initialize path buffer, unless no memory */
data/windows/unzipfx-carla-control/unix/unix.c:*pathcomp = '\0';
/* initialize translation buffer */
data/windows/unzipfx-carla-control/unix/unix.c:INIT:  allocate and
initialize buffer space for the file currently being
data/windows/unzipfx-carla-control/crypt.c:   /* For the encoding task used in
Zip (and ZipCloak), we want to initialize
data/windows/unzipfx-carla-control/crypt.c:  used to supply these `random'
bytes, which in turn is initialized by
data/windows/unzipfx-carla-control/crypt.c: * Initialize the encryption keys
and the random header according to
data/windows/unzipfx-carla-control/crypt.c: * Initialize the local copy of the
table of precomputed crc32 values.
data/windows/unzipfx-carla-control/crypt.c:/* Initialize keys with password
and write random header */
data/windows/unzipfx-carla-control/crypt.c:/* Initialize keys with password
*/
data/windows/unzipfx-carla-control/consts.h:  This file contains global,
initialized variables that never change.  It is
data/windows/unzipfx-carla-control/fileio.c:register int init;  /*
initializer character */
data/windows/unzipfx-carla-control/globals.h:  structure and initialize any
variables that require it.  This must
data/windows/unzipfx-carla-control/globals.h:#ifndef VMS
/* if SMALL_MEM, outbuf2 is initialized in */
data/windows/unzipfx-carla-control/globals.h:int inflInit; /*
inflate static: zlib inflate() initialized */
data/windows/unzipfx-carla-control/globals.h:/* pseudo constant sigs; they are
initialized at runtime so unzip executable

Bug#921544: gramps: Please don't compress example Gramps data files

[Ross Gammon]

Package: gramps
Version: 5.0.1-1~ubuntu18.04.1~ppa1
Severity: wishlist

Dear Maintainer,

The example Family Tree databases provided with Gramps are automatically
compressed.

This makes it difficult to troubleshoot issues for users that are not used to
uncompressing files in the system directories.

For privacy reasons, users are not normally happy sharing their problematic
files that might contain genealogical data for living people. It is best to try
and recreate the problem in the example databases, which can be updated with
problematic data and used in the unit tests.

Please exclude these example files from being compressed.

Regards,

Ross



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

Kernel: Linux 4.15.0-45-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gramps depends on:
ii  gir1.2-gtk-3.03.22.30-1ubuntu1
ii  librsvg2-22.40.20-2
ii  python3   3.6.7-1~18.04
ii  python3-bsddb36.1.0-1build4
ii  python3-gi3.26.1-2
ii  python3-gi-cairo  3.26.1-2
ii  xdg-utils 1.1.2-1ubuntu2.3

Versions of packages gramps recommends:
ii  gir1.2-gexiv2-0.100.10.8-1
ii  gir1.2-osmgpsmap-1.0  1.1.0-2
ii  graphviz  2.40.1-2
ii  python3-icu   1.9.8-0ubuntu1

Versions of packages gramps suggests:
ii  fonts-freefont-ttf20120503-7
ii  gir1.2-goocanvas-2.0  2.0.4-1
ii  gir1.2-gtkspell3-3.0  3.0.9-2
ii  python3-numpy 1:1.13.3-2ubuntu1
ii  python3-pil   5.1.0-1
pn  rcs   

-- no debconf information

Bug#897806: Lmms fix uploaded

[Ross Gammon]

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

[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.

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#918242: Take over lmms maintanenace

[Ross Gammon]

Hi Javier,

I hope my suggestions will mean that lmms is released with Buster (lmms
has been removed from testing), and can be added into the Ubuntu Studio
standard set of packages (it was removed from  the Ubuntu Studio seeds
recently due to the clash with calf-plugins). We are very close to the
release freeze.

I prefer that packages are team maintained, and I am confident that the
Debian Multimedia Team will do a good job of maintenance when we take over.

But of course, it would be a shame to lose you as a contributor. You
have done an excellent job looking after lmms so far. I hope you would
consider continuing. We can take patches in the BTS, and Merge Requests
on salsa if you don't want to join the team.

Would you like me to remove you from the uploaders list?

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#918242: Lmms Review

[Ross Gammon]

Hi Javier,

I have done a quick review of lmms as it is in Salsa at the moment. Here
are my comments.

Upload Blockers:

1. Why are we adding the lmms-bin package? This is not explained, and
means the package will have to go via the NEW queue, and may be there
for months waiting for acceptance. And then, because lmms still depends
on calf-ladspa, #891756 is not really fixed. I recommend reverting this
change, and keeping the old package names. Then the RC bug will be fixed
much quicker.

2. The Vcs-Git URL in debian/control is now missing & the Vcs-Browser
URL should not have .git at the end. This change should also be
mentioned in the changelog.

3. The Debian changelog is missing most of the Debian changes made to
the package (and the ones there are not very explanatory). See below for
suggestions.

Minor Issues:

4. * Fix build (Closes: #897806). If the patch was based on an upstream
commit(s), this should be referenced in the patch header description.
The purpose being, that it is easier to work out for the next release if
the patch can be dropped. And the debian/changelog entry should
reference the patch that fixed the FTBFS for GCC 8.
I would recommend: "Added build-amd64-20181013.patch to fix FTBFS for
GCC 8".

5. * Allow recommendations (Closes: #891756). It is better to say "Drop
calf-laspa from depends to recommends (Closes: #891756)".

6. Debian changelog should mention the change of maintainer email address.

7. The change to debian/rules is not mentioned in the changelog, and
should be explained there.

8. There are lots of lintian warnings. Some of them will go away when
point 1. above is addressed. Some of them are probably easy to fix.

Other stuff for later:

9. Later versions - Do you think it is worth trying to package v1.1.90
for Buster (assuming the latest 1.2.0 comes too late)? By the way, we
could package RC7 for experimental. Then it would be easy to move it to
unstable once the Final Release comes out (all of the tricky packaging
issues should have been already sorted out).

10. Join Debian Multimedia Team? As Petter is happy for DMT to take
over, feel free to request to join the team. Lmms is a good fit for the
team, and it would be easier for me to help out (and others too). Of
course, if you enjoy helping out with other Debian Edu packages, then
feel free to stay. We can close this ITS Bug recording your decision, or
in the changelog of a future upload from the DMT repository.

Ping me when you think the package is ready.

Thanks for caring for lmms, and sorry it has taken so long for you to
get the help to upload it.

Regards,

Ross

Bug#918242: ITS: lmms

[Ross Gammon]

Hi Javier & Israel,

Thanks for responding so soon. It is good to know that there are 3
people (including Boyuan) interested in caring for lmms. This bug can
probably be closed once there is an upload.

On 1/4/19 10:05 PM, Javier Serrano Polo wrote:
> El dv 04 de 01 de 2019 a les 17:57 +0100, Ross Gammon va escriure:
>> And he has been recently adding information to some of the bugs,
>> including
>> asking for help to upload something.
> 
> Indeed, I am still waiting. Boyuan Yang offered to sponsor too. I am
> fine if you do the upload.

I have to travel with work for two weeks. This sometimes means I have
lots of spare time, and sometimes it means zero. But I will take a look
when I get a chance.

> 
> Next upstream version, namely 1.2.0, is not ready.
> 
>> I am wondering if it would be a good idea to move lmms into the
>> Debian
>> Multimedia team where I could help with the maintenance.
> 
> This is for Debian Edu developers to decide.
> 

It sounds like the Debian Edu DD's are just busy, so it is probably time
to advertise outside of the team for sponsorship. No need to move the
package somewhere else unless the Debian Edu team want this.

For the future, I recommend using Debian Mentors to find a sponsor
(which is what I think Boyuan was asking for):
https://mentors.debian.net/intro-maintainers

But as Debian Edu is a Blend, Andreas Tille's Sponsoring of Blends (SoB)
initiative might also be a good bet:
https://wiki.debian.org/DebianPureBlends/SoB

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#918242: ITS: lmms

[Ross Gammon]

Source: lmms
Severity: important

Dear Maintainer,

I am checking whether you would be happy for me to salvage the lmms package:
https://wiki.debian.org/PackageSalvaging

Lmms seems to need some love, and I would like to try and fix the issue that
lmms is not co-installable with calf-plugins.

Lmms seems at first glance to fit several salvaging criteria (I think):
1. There is an RC bug that needs fixing, and lmms has been removed from testing
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897806).
2. There is no visible activity regarding the package for six months (At least
on the PTS - the Vcs points to Alioth which gives a "Not Found" page).
2. A previous NMU was not acknowledged, and a bug justifying another NMU is
pending for one month (there is an RC bug that needs fixing causing lmms to be
removed from testing in August 2018).
3. The last upload was an NMU and there was no maintainer upload within one
year (the last upload was an NMU on 2018-03-18 - the last maintainer upload was
in 2016).

However, to be fair to  Javier Serrano Polo, a new Vcs has been created on
Salsa:
https://salsa.debian.org/debian-edu-pkg-team/lmms
And he has been recently adding information to some of the bugs, including
asking for help to upload something.

The next upstream version (Version 1.1.90) could be packaged.
Also, the latest upstream release candidate (1.2.0rc7) could be uploaded to
experimental, so that if 1.2.0 is released before the Buster freeze, it could
be very quickly moved to unstable.

I am wondering if it would be a good idea to move lmms into the Debian
Multimedia team where I could help with the maintenance.

Would this be okay with you all (Javier, Israel & Petter)?

Alternatively, can I help with sponsoring an upload?

I will wait the required 21 days before taking action.

Regards,

Ross



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

Kernel: Linux 4.15.0-43-generic (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#293454: Qjackctl: Won't fix?

[Ross Gammon]

tag 293454 - upstream + wontfix
notforwarded 293454
thanks

The fowarded address is no longer valid. Tickets on the current
Sourceforge tracker date from 2012.

According to the upstream maintainer's comments on this bug, the problem
won't be fixed. SO I have tagged the bug with this status for now.

If it is still a problem, a new ticket should probably be created upstream.

Ross




signature.asc
Description: OpenPGP digital signature

Bug#896305: laditools: diff for NMU version 1.1.0-3.1

[Ross Gammon]

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#844229: WIP pushed to Salsa for anyone to take over

[Ross Gammon]

Waiting for node-catty, which is in NEW. If someone needs it, WIP
packaging is here:
https://salsa.debian.org/js-team/node-chroma-js



signature.asc
Description: OpenPGP digital signature

Bug#826560: [Pkg-javascript-devel] Bug#826560: progress

[Ross Gammon]

On 07/04/2018 12:00 AM, Christoph Lehnberger wrote:
> Hi Ross,
>
> any progress about the changes. Maybe I can help somehow.
>
> Best regards,
> Christoph
>
>
Hi Christopher,

I can't remember exactly where I got to. I think I was waiting for
node-catty to get out of the NEW queue. But if you have the time and the
lust, you are welcome to take over. You can try building with catty from
NEW,  or just embed it for now (at least for testing).

Ross

Bug#895917: Libav-tools relegated to Suggests

[Ross Gammon]

Hi James,

On 06/09/2018 05:33 PM, James Cowgill wrote:
> Hi,
> 
> On 09/06/18 14:17, Ross Gammon wrote:
>> Hi,
>>
>> FFmpeg is already recommended by multimedia-video.
>>
>> Removing libav-tools from the blends task would mean that people running
>> stable would not be able to find the package on the blends website:
>> https://blends.debian.org/multimedia/tasks/
> 
> Is this really a problem? libav-tools was deprecated before stretch was
> released so even in stable people should not be encouraged to install it.
> 
> James
> 

No, it is not really a problem. It is just the way blends work. The
blends website shows you all the packages that are available for you to
install in the e.g. video category.

Libav-tools now shows in the "Official Debian packages with lower
relevance" category (because I dropped it to Suggests):
https://blends.debian.org/multimedia/tasks/video

I don't imagine anyone would be crazy enough to install one of the meta
packages with suggestions included.

Anyway, I suppose libav and ffmpeg is a bit of a special case, as it is
a transitional package. And anyone that is using libav in a script or
whatever will already have it installed. The bug is still open, so when
it is time for the next upload I will remember to remove it.

Thanks for following up with the query.

Cheers,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#895917: Libav-tools relegated to Suggests

[Ross Gammon]

Hi,

FFmpeg is already recommended by multimedia-video.

Removing libav-tools from the blends task would mean that people running
stable would not be able to find the package on the blends website:
https://blends.debian.org/multimedia/tasks/

We normally only remove packages from the blends tasks once the package
is completely removed from the archive.

I have demoted libav-tools to "Suggests" so that it appears lower down
the website. Once the package is no longer in stable, we can remove it
from the blends task. If this causes problems in anyway, please let me know.

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#885799: Partial Fix Commited

[Ross Gammon]

Control: severity -1 normal

Hi,

I have removed libjuce-dev, as it is no longer part of the juce package.
The other Juce packages are still listed in the tasks.

Regarding libart-2.0-dev (which is actually still part of testing and
unstable at the moment), removing these would mean that people running
stable would not be able to find the package on the blends website:
https://blends.debian.org/multimedia/tasks/

We normally only remove packages from the blends tasks once the package
is completely removed from the archive. I am not aware of a "recommends"
blocking a testing migration before, but if I am wrong - please feel
free to raise the severity when it happens.

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#898077: lintian: False positive in missing-build-dependency-for-dh-addon, python package

[Ross Gammon]

Package: lintian
Version: 2.5.55
Severity: normal

Dear Maintainer,

When building laditools, the missing-build-dependency-for-dh-addon lintian
warning is received because scour is not a build dependency when the scour dh
addon is used in debian/rules.

However, python-scour is a build dependency and pulls in the scour package.

Lintian should perhaps check of there is a python package that meets the
dependency requirement? Or allow e.g. "*scour"?

Regards,

Ross



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

Kernel: Linux 4.13.0-39-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils  2.29.1-4ubuntu1
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1build1
ii  dpkg  1.18.24ubuntu1
ii  file  1:5.32-1
ii  gettext   0.19.8.1-4ubuntu1
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2build2
ii  libdpkg-perl  1.18.24ubuntu1
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1build3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.0-8ubuntu1.1
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.72-1
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.63-2build1
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.26.0-8ubuntu1.1
ii  t1utils   1.40-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1build3

Versions of packages lintian suggests:
ii  binutils-multiarch 2.29.1-4ubuntu1
ii  dpkg-dev   1.18.24ubuntu1
ii  libhtml-parser-perl3.72-3build1
ii  libtext-template-perl  1.46-1

-- no debconf information

Bug#892022: ITP: node-catty -- source file concatenator for Mapshaper

[Ross Gammon]

Package: wnpp
Severity: wishlist
Owner: Ross Gammon <rossgam...@debian.org>
X-Debbugs-CC: debian-de...@lists.debian.org
X-Debbugs-CC: pkg-javascript-de...@lists.alioth.debian.org

* Package name    : node-catty
  Version : 0.0.8
  Upstream Author : Matthew Bloch <mbl...@nytimes.com>
* URL : https://github.com/mbloch/catty
* License : Expat
  Programming Lang: JavaScript
  Description : source file concatenator for Mapshaper

 Catty is the source file concatenator for Mapshaper.
 .
 Some features:
 .
 * Each source file lists its dependencies in a formatted comment. There
   is no manifest, unlike some other tools.
 * Concatenated files are (optionally) wrapped in a self-executing
   function, to protect the global namespace.
 * Catty can monitor source files and regenerate output files when a
   required source file changes.
 .
 Node.js is an event-based server-side JavaScript engine.

This package is a required dependency of node-chroma.js, which is a
new dependency of the latest version of node-carto.

This package will be maintained within the Debian JavaScript maintainers
team.

Bug#826560: Nearly there with node-carto dependencies

[Ross Gammon]

Hi All interested,

Sorry - I am extremely busy at the moment.

I am nearly ready with chroma-js, which is the only remaining missing
dependency from what I can see.

I just need to package catty to make for a smooth build process for
chroma-js. Help with than one package would be good, as I probably won't
get back onto chroma-js for a few weeks.

Ross



signature.asc
Description: OpenPGP digital signature

Bug#890023: abcmidi fails autopkg tests on 32bit architectures

[Ross Gammon]

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#870460: anyone working on npm?

[Ross Gammon]

Hi Diane,

https://wiki.debian.org/Javascript/Nodejs/Tasks/npm

As far as I know, people have been working on trying to get all the
missing packages packaged, and update the old ones. Unfortunately, I
have not had the time to help myself.

I am not sure if anyone else has tried building npm yet, but it is good
to know we are getting close.

I will let the other more active team members comment on how best to
incorporate your work.

Ross

On 01/24/2018 08:14 AM, Diane Trout wrote:
> Hello,
>
> I was looking to update zotero, which needs a newer npm.
>
> I was curious, so I tried building a npm using upstream's 5.6.0, and I
> have something that almost installs & runs.
>
> Several dependencies are out of date in Debian, and there's still a
> fair number of node_modules that don't seem to have a corresponding
> Debian package.
>
> Would it be worth sharing these changes? How would you prefer to
> receive / review them? There's a few issues I avoided that need some
> discussion. (Like they embed a copy of node-gyp, and several scripts
> hard code relative paths to that copy)
>
> I wanted to get in touch with people in the javascript team before
> slogging through updating the copyright file.
>
> Diane
> detrout on Debian IRC
> Debian Developer

Bug#797535: vmpk status

[Ross Gammon]

Hi Mehdi,

On 01/08/2018 09:47 AM, Mehdi Dogguy wrote:
> Hi Ross,
>
> It is great to hear that pkg-multimedia is willing to take care of this
> package. Did you make any progress on this package?
>
> AFAIK, current version is broken and doesn't work anymore. An update to
> the latest upstream version is very much needed.
>
> Regards,
>

From memory, I got stuck on the libdrumstick transition. The latest
version (1.1.0) has introduced some "ctest" which I had not come across
before, and I have not had a chance recently to try and work out why the
tests are failing when building the package, or (worst case) how to
disable them.

Also, the transition is waiting for a new version of kmidimon which has
not yet been updated to work with the latest libdrumstick. This could be
solved by knocking it out of testing and hoping it is fixed by the
Buster release, or moving the latest libdrumstick into it's own source
package so that the old library can remain (they are co-installable
apparently).

Unfortunately, real life is getting in the way at the moment.

Regards,

Ross

Bug#733610: Webapp no longer part of Gramps

[Ross Gammon]

The latest news is that the webapp was split out of Gramps to a project
called gramps-connect. Then Gprime was created which is a web-based fork
of Gramps & Gramps-connect.

https://genealogycollective.github.io/gprime/

Gprime is a better target to package once it is ready.

Ross



signature.asc
Description: OpenPGP digital signature

Bug#876937: missing build dependency

[Ross Gammon]

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#879783: Removing dino from multimedia-blends

[Ross Gammon]

Control: tags -1 pending

Hi Ralf,

I have pushed a change to git removing dino from multimedia-blends. I
will do an upload sometime soon.

But don't you think it is a bit early to introduce a new/different
package with the same name as dino?

Dino is still in old-stable and Ubuntu Trusty which are still both
supported. It might be better to rename the package (e.g. to dino-im)
for now, and then rename it back to dino once Buster is released, and
Ubuntu Trusty is dropped.

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#880932: ITP: node-bin-version -- Get the version of a binary in semver format

[Ross Gammon]

Package: wnpp
Severity: wishlist
Owner: Ross Gammon <rossgam...@debian.org>
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name    : node-bin-version
  Version : 2.0.0
  Upstream Author : Sindre Sorhus <sindresor...@gmail.com>
(sindresorhus.com)
* URL : https://github.com/sindresorhus/bin-version
* License : Expat
  Programming Lang: JavaScript
  Description : Get the version of a binary in semver format

 Node-bin-version returns the version of a binary in semver format. Semver
 is the semantic versioning system for npm.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#779305: Package is NEW

[Ross Gammon]

Hi,

I have uploaded the package, and it is waiting in the NEW queue:
https://ftp-master.debian.org/new.html

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#779305: node-bluebird

[Ross Gammon]

On 10/08/2017 06:12 PM, Hubert Chathi wrote:
> On Sat, 7 Oct 2017 17:28:17 +0200, Ross Gammon <r...@the-gammons.net> said:
> 
>> Hi Hubert, I would like to incorporate your work, but for some reason
>> I cannot clone or fetch from your node-bluebird repository (I was able
>> to clone one of your others - whalebuilder).
> 
> Hi Ross,
> 
> Can you give it another try?  I forgot to enable the hook to allow it to
> be cloned over HTTPS.  Hopefully it should work now.
> 
> Hubert
> 

Thanks - that did it!



signature.asc
Description: OpenPGP digital signature

Bug#779305: node-bluebird

[Ross Gammon]

Hi Hubert,

I would like to incorporate your work, but for some reason I cannot
clone or fetch from your node-bluebird repository (I was able to clone
one of your others - whalebuilder).

Maybe you could email be a git patch?

Thanks for helping out.

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

[Ross Gammon]

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#785566: goocanvas 2.0.3 now in unstable

[Ross Gammon]

Hi Mathias,

Goocanvas 2.0.3 is now in unstable, which contains the fixes required
for goocalender to use gir1.2-goocanvas-2.0 instead of python-goocalendar.

Regards,

Ross

Bug#876597: goocanvas FTBFS with gtk-doc-tools 1.26: gtkdoc-mktmpl is no longer available

[Ross Gammon]

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

[Ross Gammon]

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#779305: Update on dependencies

[Ross Gammon]

On 10/02/2017 06:42 AM, Pirate Praveen wrote:
> On 10/01/2017 10:42 PM, Hubert Chathi wrote:
>> I don't think contrib would help since packages in main aren't allowed
>> to build-depend on things in contrib.  I think it would be OK to include
>> the pre-built JS files as long as they're the same as the resulting
>> files, so that people can verify that it's built properly.  Also, since
>> they're un-minified, and the build process seems to be mostly trivial
>> (some macros and removing comments and asserts), it isn't that hard to
>> see that it does come from the source.
> contrib route can be useful as a prototype package when there is a lot
> of dependencies to be packaged or has circular dependencies. I had
> uploaded babel to contrib because it needed babylon and babylon needed
> rollup. Once I figured babylon can be built with babel and rollup was
> not required, I uploaded both babylon and babel together to main. If all
> dependencies are already in main, it can be uploaded to main, even
> though it depends on itself (The requirement is, it should be buildable
> in main and first upload is always binary included).
> 

Thanks guys. I hope to have a couple of days holiday soon, which I will
try and devote to bluebird. In the meantime, I have some RC bugs and
transitions to try and kick off before Buster is frozen (I missed them
already for stretch) :-)
But if I fail, anyone from the team is welcome to chip in.



signature.asc
Description: OpenPGP digital signature

Bug#779305: Update on dependencies

[Ross Gammon]

Hi guys,

On 10/01/2017 04:59 PM, Pirate Praveen wrote:
> On 10/01/2017 07:56 PM, Hubert Chathi wrote:
>> Hi Ross,
>> Have you done any work on this recently?  I took a quick look bluebird
>> the other day, and I have a 1-line patch to make it build with
>> node-acorn in Debian, plus a few other little patches.  The tests are
>> running, but failing, and I haven't dug much into why they're failing
>> yet.  But the resulting build is the same as what I get from npm install
>> (at least just the node part, obviously).  I can push what I've done
>> somewhere, if that would be helpful.
>>
>> Hubert
> 
> You could push it to a different branch on alioth repo. It will be
> helpful to get this moving as it is a dependency required for updating npm.
> 
> 

Yes - any help getting bluebird finished would be welcome. I have been
conscious that it would very soon become a blocker for many things, but
have lacked the time to get back onto it. It probably also needs to have
a bootstrap trip via contrib, as it needs a prebuilt version of itself
to build.

I found some old local updates that I had not pushed, so I just pushed
them. If you push to another branch like Pirate says Hubert, we can
merge all the best bits.

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#520915: Open from Location bug also reported in Ubuntu

[Ross Gammon]

Hi,

This has also been reported in Ubuntu. Installing gvfs-backends worked
for that person (Kubuntu 17.04).

https://bugs.launchpad.net/ubuntu/+source/gimp/+bug/1720582

"Open from Location" seems to be pretty core functionality to me. Would
it be possible to move gvfs-backends to "Depends" instead of "Suggests".
Or at least to "Recommends".

Regards,

Ross

Bug#867727: RFS: parlatype/1.5.2-1 [ITP]

[Ross Gammon]

Control: tags -1 moreinfo

Hi Gabor,

Good work. We are nearly there!

The only thing I spotted, was the lack of a docbase file to help people
fire up the docs locally:
https://www.debian.org/doc/manuals/maint-guide/dother.en.html#doc-base

Would you like to maintain this within the Debian Multimedia Team? If so:
https://wiki.debian.org/DebianMultimedia/Join
and then follow the stuff in the Develop Packaging link there (to create
the git repository etc).
We can always do this before the next upload if you prefer. Just let me
know.

Some minor things we can work on for next time:
1. Lintian complains about there being no upstream changelog. As you are
upstream, maybe you can fix this? It is a nice service to our users to
see what changed in each version without going online. The Debian
changelog only contains changes in the packaging.
2. It would be nice to add some autopkgtests. For parlatype, that might
just be to run the binary command without a file to check that it
installs & doesn't crash. For the library & gir library you can compile
a simple app against the libraries to check they compile & run OK. If
you search on Debian Codesearch you will find examples.

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#867727: RFS: parlatype/1.5.2-1 [ITP]

[Ross Gammon]

Control: owner -1 rossgam...@debian.org

Thanks Juhani for the excellent review, and thanks Gabor for your patience.

I plan to take a look at parlatype over the weekend.

Cheers,

Ross




signature.asc
Description: OpenPGP digital signature

Bug#867727: Request for sponsoring Parlatype -- audio player for transcription

[Ross Gammon]

Hi Gabor,

On 08/24/2017 11:13 AM, Gabor Karsay wrote:
> Dear Debian Multimedia Maintainers,
>
> I'm looking for a reviewer or sponsor of my package Parlatype which is
> a minimal audio player that helps you to transcribe speeches,
> interviews, lyrics etc. It's based on GStreamer and GTK+.
>
> It shows the waveform of the audio and I am not aware of any other
> comparable tool in Debian that does that. A similar program is
> Play-it-slowly, but Parlatype offers helpers for transcription, like
> timestamps (drag'n'drop), rewind on pause etc.
>
> Just to clarify: I'm also the upstream author. I filed already ITP and
> RFS bugs here:
>
> ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868886
> RFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867727
>
> I was not aware of the multimedia packaging team before, my first
> intent was to maintain it myself, i.e. not in a team. I hope that
> somebody from this team is interested and can give me some guidance
> how to proceed.
>
> Thank you
> Gabor Karsay
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
>

I would be happy to take a look at this. Unfortunately, I am quite busy
at the moment so I can't promise much this week.

I have cc'd you because you did not say whether you are subscribed to
the Multimedia list. I have also copied in the RFS bug so that other
potential sponsors see this and take over if they are looking for
something to do :-)

Regards,

Ross

Bug#875279: node-coffeeify: Please enable upstream Testsuite

[Ross Gammon]

Package: node-coffeeify
Version: 1.0.0-1
Severity: normal

Dear Maintainer,

The upstream testsuite is not run during the building of the package. This is
due to node-browserify not yet being available in Debian (see TODO file).

Please remember to enable the tests once browserify is packaged.

Ross



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

Kernel: Linux 4.10.0-33-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#785566: [tryton-debian] Bug#785566: Removing pygoocanvas after Stretch release

[Ross Gammon]

On 08/23/2017 12:56 PM, Mathias Behrle wrote:
> * Mathias Behrle: " [tryton-debian] Bug#785566: Bug#785566: Removing
>   pygoocanvas after Stretch release" (Sat, 25 Mar 2017 00:29:32 +0100):
>
> Hi Ross,
>
> [...]
>
 According to the upstream bug report, version 0.3 now supports the
 latest goocanvas (2.0), so it should already be possible to depend on
 gir1.2-goocanvas-2.0 instead of python-pygoocanvas.
>>> As https://git.gnome.org/browse/goocanvas/log/ shows, the patches in
>>> question were merged (2016-12-15), but not yet released.
>>>
>>> The latest release of goocanvas in Debian dates from 11 Jun 2015
>>> [2015-08-22] goocanvas-2.0 2.0.2-2 MIGRATED to testing
>>> So the according changes are not available in Debian.
>>>
>>> Please correct me if I am wrong (you are the maintainer of the package...;).
>>> Otherwise please provide an updated goocanvas package.
>> Sorry about that - the upstream goocalender bug did not mention that the 
>> changes were dependent on changes pushed to goocanvas, so I missed it. I 
>> can see that goocanvas seem to be working towards a 3.0 release. I will 
>> ask for their plans. One option might be to patch things in Debian so 
>> that we have a path for goocalender before the next problem hits the 
>> unmaintained pygoocanvas (in Debian and upstream).
> Did you get any news on this? Otherwise how do you feel about including the
> necessary patches or to package from git to get things done?
>
> Cheers,
> Mathias
>
>
Thanks for the ping. I had not had time to look into it.

I just asked on the upstream list if there is a new release planned
soon. If I don't hear anything, I will try patching a version targeted
at experimental to play with (hopefully in the next week or so).

Cheers,

Ross




signature.asc
Description: OpenPGP digital signature

Bug#870812: RM: gosmore -- ROM; RC buggy, dead upstream

[Ross Gammon]

Thanks Bas,

I had a look upstream last night, and I was thinking of doing the same
thing today. As usual, you are lightning fast :-)

Regards,

Ross

On 08/05/2017 01:57 PM, Bas Couwenberg wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> Please remove gosmore from the archive, it is RC buggy and will remain
> so because it is also dead upstream.
> 
> Kind Regards,
> 
> Bas
> 
> ___
> Pkg-grass-devel mailing list
> pkg-grass-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
> 




signature.asc
Description: OpenPGP digital signature

Bug#749775: Gramps 5.0 series will be DFSG Free!

[Ross Gammon]

tag 749775 -upstream +fixed-upstream
thanks

According to the upstream bug, this has been fixed upstream, and will be
part of the 5.0 series of Gramps once released (currently alpha2).

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#784619: Linked my Qt4-Qt5 fork to upstream Creepy issue

[Ross Gammon]

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#869366: RM: creepy -- ROM; Unmaintained upstream

[Ross Gammon]

Package: ftp.debian.org
Severity: normal

Creepy has failed to make it into any of the previous 2 Debian releases despite
the efforts of Petter Reinholdtsen (mainly) and myself.

Although upstream merged some of our Debianisation (and other) patches
initially, they have stopped responding to our prompts. The repo has not been
touched for 2 years now.

Until the major work is done to convert Creepy from QT4 to QT5, it will not be
possible to install Creepy in Debian. This issue has been closed as "won't fix"
upstream.

There are also many other issues with the instagram/twitter etc. plugins that
are not being responded to. Creepy is pretty useless without these plugins.

Regards,

Ross (on behalf of Petter Reinholdtsen & the GIS Team)

Bug#784619: Linked my Qt4-Qt5 fork to upstream Creepy issue

[Ross Gammon]

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#866736: RFS: budgie-desktop/10.2.9-3

[Ross Gammon]

On 07/01/2017 05:27 PM, foss.freedom wrote:
> Sorry - I didnt really understand about filing a bug against
> release.debian.org targeting "p-u" - I had a look here but didnt see
> an example https://www.debian.org/Bugs/Reporting

There is a bit more background information in the Developers Reference
about uploading to stable:
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#upload-stable

It is best to use the reportbug tool to report the bug, as it helps to
make sure you provide all the necessary info.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866759 for a good
example of what the bug should look like.

Cheers,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#865570: lintian: autopkgtest no longer requires an entry in debian/control

[Ross Gammon]

Package: lintian
Version: 2.5.51
Severity: normal

Dear Maintainer,

I was updating one of my packages today and received the testsuite-autopkgtest-
missing information warning from lintian. This appears to have been added due
to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859467.

This is very good, because there isn't a testsuite in my package, and thanks to
the prompt I will now provide one (I keep forgetting to check if this is one of
the packages for which I haven't done it yet).

However, reading the information about the warning, it sounds like lintian will
only be checking if there is a Testsuite field in debian/control (I have not
tested this). Unfortunately, this field is optional (it is added automatically
by dpkg-source version 1.17.11 or later) and lintian would give false positives
in cases where a testsuite is provided, but not declared in debian/control.

A more reliable way to check if a testsuite is provided, is to look for a
control file in the debian/tests directory.

Or if I am wrong about lintian, and it already checks there too, then the
description for the lintian tag should be updated.

Regards,

Ross



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

Kernel: Linux 4.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#863575: unblock: node-concat-stream/1.5.1-2

[Ross Gammon]

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

Please unblock package node-concat-stream

Node-concat-stream is vunerable to Uninitialized Memory Exposure (CWE-201).
This was reported in bug https://bugs.debian.org/cgi-
bin/bugreport.cgi?archive=no=863481. This was fixed upstream, and a version
of the fixing commit is included in this version as a patch. The patch has been
tested with the upstream testsuite, which unfortunately has to be disabled as
the testing framework (node-tape) does not exist in testing.

More information can be found in the attached debdiff (between tesing &
unstable), in the patch description.

unblock node-concat-stream/1.5.1-2

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

Kernel: Linux 4.4.0-24-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
diff -Nru node-concat-stream-1.5.1/debian/changelog node-concat-stream-1.5.1/debian/changelog
--- node-concat-stream-1.5.1/debian/changelog	2015-11-08 17:03:58.0 +0100
+++ node-concat-stream-1.5.1/debian/changelog	2017-05-28 16:19:49.0 +0200
@@ -1,3 +1,12 @@
+node-concat-stream (1.5.1-2) unstable; urgency=high
+
+  * Apply upstream fix for Uninitialized Memory Exposure weakness CWE-201
+(Closes: #863481)
+  * Use stretch git branch
+  * Use Ubuntu email address
+
+ -- Ross Gammon <ros...@ubuntu.com>  Sun, 28 May 2017 16:19:49 +0200
+
 node-concat-stream (1.5.1-1) unstable; urgency=low
 
   * Initial release (Closes: #796351)
diff -Nru node-concat-stream-1.5.1/debian/control node-concat-stream-1.5.1/debian/control
--- node-concat-stream-1.5.1/debian/control	2015-11-08 17:03:58.0 +0100
+++ node-concat-stream-1.5.1/debian/control	2017-05-28 16:19:49.0 +0200
@@ -2,13 +2,13 @@
 Section: web
 Priority: optional
 Maintainer: Debian Javascript Maintainers <pkg-javascript-de...@lists.alioth.debian.org>
-Uploaders: Ross Gammon <rossgam...@mail.dk>
+Uploaders: Ross Gammon <ros...@ubuntu.com>
 Build-Depends: debhelper (>= 9),
dh-buildinfo,
nodejs
 Standards-Version: 3.9.6
 Homepage: https://github.com/maxogden/concat-stream#readme
-Vcs-Git: git://anonscm.debian.org/pkg-javascript/node-concat-stream.git
+Vcs-Git: git://anonscm.debian.org/pkg-javascript/node-concat-stream.git -b stretch
 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-javascript/node-concat-stream.git
 
 Package: node-concat-stream
diff -Nru node-concat-stream-1.5.1/debian/gbp.conf node-concat-stream-1.5.1/debian/gbp.conf
--- node-concat-stream-1.5.1/debian/gbp.conf	2015-11-08 17:03:58.0 +0100
+++ node-concat-stream-1.5.1/debian/gbp.conf	2017-05-28 16:19:49.0 +0200
@@ -6,7 +6,7 @@
 
 # The default name for the Debian branch is "master".
 # Change it if the name is different (for instance, "debian/unstable").
-debian-branch = master
+debian-branch = stretch
 
 # git-import-orig uses the following names for the upstream tags.
 # Change the value if you are not using git-import-orig
diff -Nru node-concat-stream-1.5.1/debian/patches/series node-concat-stream-1.5.1/debian/patches/series
--- node-concat-stream-1.5.1/debian/patches/series	2015-11-08 17:03:58.0 +0100
+++ node-concat-stream-1.5.1/debian/patches/series	2017-05-28 16:19:49.0 +0200
@@ -1 +1,2 @@
 readable-stream.patch
+to-string_numbers.patch
diff -Nru node-concat-stream-1.5.1/debian/patches/to-string_numbers.patch node-concat-stream-1.5.1/debian/patches/to-string_numbers.patch
--- node-concat-stream-1.5.1/debian/patches/to-string_numbers.patch	1970-01-01 01:00:00.0 +0100
+++ node-concat-stream-1.5.1/debian/patches/to-string_numbers.patch	2017-05-28 16:19:49.0 +0200
@@ -0,0 +1,81 @@
+Description: to-string numbers written to the stream
+ Node-concat-stream is vulnerable to Uninitialized Memory Exposure. This
+ 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.
+ See https://snyk.io/vuln/npm:concat-stream:20160901 for further details.
+Origin: upstream, https://github.com/maxogden/concat-stream/
+Bug: https://github.com/maxogden/concat-stream/issues/55
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863481
+Applied-Upstream: https://github.com/maxogden/concat-stream/pull/47/commits/3e285ba5e5b10b7c98552217f5c1023829efe69e
+Last-Update: 2017-05-28
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- node-concat-stream.orig/index.js
 node-co

Bug#863481: [Pkg-javascript-devel] Bug#863481: [node-concat-stream] Uninitialized Memory Exposure

[Ross Gammon]

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#779305: Update on dependencies

[Ross Gammon]

On 04/29/2017 09:14 AM, Ross Gammon wrote:

> 
> I will try and push where I got to to Alioth this morning.
> 
> Cheers,
> 
> Ross
> 

Found the latest & pushed!

I had success (apart from the acorn issue) bootstrapping it with a copy
of a pre-built bluebird in debian/node_modules. I need to change that
directory name though, because it is ignore by git.

If you like, I could try and finish it off this weekend. Any tips
welcome. If you are impatient, you are welcome to take it from here.

Regards,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#779305: Update on dependencies

[Ross Gammon]

On 04/29/2017 07:43 AM, Pirate Praveen wrote:
> On Sun, 24 May 2015 12:34:59 +0200 Ross Gammon <r...@the-gammons.net> wrote:
>> -uglifyjs (already packaged as node-uglify)
>> -rimraf (already pckage as node-rimraf)
>> -optimist (already packaged as node-optimist)
>> -mocha (already packaged as libjs-mocha & mocha)
>> -mkdirp (already packaged as node-mkdirp)
>> -glob (already packaged as node-glob)
>> -cross-spawn (already packaged & in the NEW queue as node-cross-spawn)
>> -cli-table (already packaged & in the NEW queue as node-cli-table)
>> -browserify
>> -acorn (already packaged & in NEW queue as part of the acorn package)
>>
>> I have stopped work on this, waiting for node packages to start leaving
>> the NEW queue.
>>
> 
> All of them are in archive. Can we have just the nodejs part packaged
> until we get browserify?
> 

Yes - that was what what I was working on just before the Stretch Freeze.

Bluebird unfortunately build depends on itself, so I had been testing
different ways to bootstrap it, but ran into the problem that it
couldn't find acorn. Julien explained what might have been the problem,
but I never got around to fixing that.

I will try and push where I got to to Alioth this morning.

Cheers,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#785566: [tryton-debian] Bug#785566: Removing pygoocanvas after Stretch release

[Ross Gammon]

Hi Mathias,

On 25/03/17 00:29, Mathias Behrle wrote:

* Ross Gammon: " [tryton-debian] Bug#785566: Removing pygoocanvas after Stretch
   release" (Fri, 24 Mar 2017 17:47:47 +0100):

Hi Ross,


severity 785566 important
thanks

Hi,

I plan to ask for the removal of pygoocanvas after Stretch is released.
At that time, I will raise this bug's severity to serious.

Your message is in format for the control server, so didn't work. Which is kind
of fortunate, because I don't agree to raise the severity for the reasons below.


Thanks for spotting that - no problems. I will only raise the severity 
for the other packages that haven't been as proactive as yourself. :-)





According to the upstream bug report, version 0.3 now supports the
latest goocanvas (2.0), so it should already be possible to depend on
gir1.2-goocanvas-2.0 instead of python-pygoocanvas.

As https://git.gnome.org/browse/goocanvas/log/ shows, the patches in
question were merged (2016-12-15), but not yet released.

The latest release of goocanvas in Debian dates from 11 Jun 2015
[2015-08-22] goocanvas-2.0 2.0.2-2 MIGRATED to testing
So the according changes are not available in Debian.

Please correct me if I am wrong (you are the maintainer of the package...;).
Otherwise please provide an updated goocanvas package.


Sorry about that - the upstream goocalender bug did not mention that the 
changes were dependent on changes pushed to goocanvas, so I missed it. I 
can see that goocanvas seem to be working towards a 3.0 release. I will 
ask for their plans. One option might be to patch things in Debian so 
that we have a path for goocalender before the next problem hits the 
unmaintained pygoocanvas (in Debian and upstream).


Regards,

Ross

Bug#822251: Tried testing with Mocha instead

[Ross Gammon]

Hi,

As node-espresso is unmaintained upstream, I tried testing with mocha 
instead. But mocha fails to find 'seq'. Actually, this is also the case 
with espresso included as a node_module.


The test cases might need some work, or alternatively run as autopkgtest 
(installed) instead.


Regards,

Ross

Bug#798278: node-tape: team and good news

[Ross Gammon]

Hi Bastien,

Go for it! Don't let me be a blocker. It will be great to have node-tape 
available for Buster.


I am going to be quite busy for the next month.

Thanks for your help.

Ross


On 03/04/17 23:44, Bastien ROUCARIES wrote:

On Mon, Apr 3, 2017 at 11:43 PM, Bastien ROUCARIES
 wrote:

On Mon, Apr 3, 2017 at 6:11 PM, Bastien ROUCARIES
 wrote:

Hi,

I achieved to package node-tape and it is relativly easy.

It need patching in order to avoid some surprise but it is nice.

Ross I am now a dd and I can upload but I need to upload a fixed resumer.

Can I upload and add myself to resumer ?

Hi,

The git tree is here

https://anonscm.debian.org/git/collab-maint/node-tape.git




Thanks

Bastien

Bug#813185: goocanvas to be removed from the archive after Stretch is released

[Ross Gammon]

severity 813185 important
thanks

Hi,

I plan to ask for the removal of goocanvas after Stretch is released.
Once all reverse dependencies have moved to the new gir bindings (or
removed from testing), I will reassign this bug to ftp-master & ask for
removal from unstable.

This will allow goocanvas to be removed from unstable as well.

Regards,

Ross

Bug#785553: goocanvas to be removed once stretch released

[Ross Gammon]

severity 785553 important
thanks

Hi,

I plan to ask for the removal of goocanvas after Stretch is released.
At that time, I will raise this bug's severity to serious.

It would be great in the meantime if you could check which upstream that
libgoo-canvas-perl works with the newer goocanvas-2.0 which has been in
unstable for some time now.

Let me know if I can help in any way.

Regards,

Ross

Bug#785551: Removal of goocanvas during Buster cycle

[Ross Gammon]

severity 785551 important
thanks

Hi,

I plan to ask for the removal of goocanvas after Stretch is released.
At that time, I will raise this bug's severity to serious.

It would be great in the meantime if you could check which upstream that
gpredict works with the newer goocanvas-2.0 which has been in unstable
for some time now.

Let me know if I can help in any way.

Regards,

Ross

Bug#858636: goocanvas is deprecated & replaced by goocanvas-2.0

[Ross Gammon]

Source: goocanvas
Version: 1.0.0-1
Severity: important

Dear Maintainer,

Goocanvas is deprecated upstream and replaced by goocanvas-2.0 which is already
in the archive.

I plan to remove goocanvas from the archive during the Buster cycle, once the
reverse dependencies have moved over to goocanvas-2.0.

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#785565: Removal of pygoocanvas after Stretch Release

[Ross Gammon]

severity 785565 important
thanks

Hi,

I plan to ask for the removal of pygoocanvas after Stretch is released.
At that time, I will raise this bug's severity to serious.

The upstream bug tracker (bugzilla) seems to need an account to submit a
bug, so I did not do ask them about moving to the gir package instead.
But at least the visualiser (that needs goocanvas) seems to be optional,
so assume it could be dropped temporarily if required.

Let me know if I can help in any way.

Regards,

Ross

Bug#785566: Removing pygoocanvas after Stretch release

[Ross Gammon]

severity 785566 important
thanks

Hi,

I plan to ask for the removal of pygoocanvas after Stretch is released.
At that time, I will raise this bug's severity to serious.

According to the upstream bug report, version 0.3 now supports the
latest goocanvas (2.0), so it should already be possible to depend on
gir1.2-goocanvas-2.0 instead of python-pygoocanvas.

Let me know if I can help in any way.

Regards,

Ross

Bug#785562: pygoocanvas to be removed for Buster

[Ross Gammon]

severity 785562 important
thanks

Hi,

Just a friendly warning that as soon as Stretch is released, I plan to
start the removal of pygoocanvas. Therefore, I will raise the severity
of this bug to "serious" at that time.

It would be great if you could start working on packaging the latest
version of openshot, so that the dependency on pygoocanvas can be dropped.

Let me know if I can help in any way.

Regards,

Ross

Bug#855471: RFP: node-bin-version-check -- Check whether a version satisfies a semver range

[Ross Gammon]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: pkg-javascript-de...@lists.alioth.debian.org

* Package name: node-bin-version-check
  Version : 3.0.0
  Upstream Author : Sindre Sorhus  
(sindresorhus.com)

* URL : https://github.com/sindresorhus/bin-version-check
* License : Expat
  Programming Lang: JavaScript
  Description : Check whether a binary version satisfies a semver range

 Node-bin-version-check checks whether a binary version satisfies a semver
 range. This is useful when you have a thing that only works with specific
 versions of a binary.
 .
 Node.js is an event-based server-side JavaScript engine.

Node-bin-version-check is a dependency of grunt-contrib-compass and 
should probably be packaged within the Debian Javascript Team.

Bug#855469: RFP: node-dargs -- Convert options into an array of arguments

[Ross Gammon]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: pkg-javascript-de...@lists.alioth.debian.org

* Package name: node-dargs
  Version : 5.1.0
  Upstream Author : Sindre Sorhus  
(sindresorhus.com)

* URL : https://github.com/sindresorhus/dargs#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Convert options into an array of arguments
 Node-dargs can be considered a reverse of minimist. It converts an object
 of options into an array of command-line arguments. This is useful when
 spawning command-line tools.
 .
 Node.js is an event-based server-side JavaScript engine.

Node-dargs is a dependency of node-grunt-contrib-compass and should 
probably be packaged in the Debian Javascript Team.

Bug#855466: RFP: node-grunt-contrib-compass -- Compile Sass to CSS using Compass

[Ross Gammon]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: pkg-javascript-de...@lists.alioth.debian.org

* Package name: node-grunt-contrib-compass
  Version : 1.1.1
  Upstream Author : Grunt Team (http://gruntjs.com/)
* URL : https://github.com/gruntjs/grunt-contrib-compass#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Compile Sass to CSS using Compass

 Compass is an open-source authoring framework for the Sass css
 preprocessor. It helps you build stylesheets faster with a huge library
 of Sass mixins and functions, advanced tools for spriting, and workflow
 improvements including file based Sass configuration and a simple pattern
 for building and using Compass extensions.
 .
 Node.js is an event-based server-side JavaScript engine.

Node-grunt-contrib-compass is a dependency of 
kodi-addon-webinterface-chorus2 and is a good fit for the Debian 
Javascript Team.

Bug#784619: Creepy: Still some work to do

[Ross Gammon]

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