Accepted caps 0.9.24-5 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 26 Mar 2018 14:47:27 -0300 Source: caps Binary: caps Architecture: source Version: 0.9.24-5 Distribution: unstable Urgency: medium Maintainer: Debian Multimedia Maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org> Changed-By: Felipe Sateler <fsate...@debian.org> Description: caps - C* Audio Plugin Suite Closes: 890633 Changes: caps (0.9.24-5) unstable; urgency=medium . [ Ondřej Nový ] * d/copyright: Use https protocol in Format field * d/control: Set Vcs-* to salsa.debian.org * d/changelog: Remove trailing whitespaces . [ Felipe Sateler ] * Use standard exp10f instead of pow10f. Thanks to Aurelien Jarno for the patch. (Closes: #890633) Checksums-Sha1: 240345fd695dbe323d0e7cadb1ea587cd7ef869a 1975 caps_0.9.24-5.dsc fc241d49c0e87e98736b4bef88d20de9744de2ff 3712 caps_0.9.24-5.debian.tar.xz 3a6252c52a83afa66a1c3dc02ab7e87740257078 5152 caps_0.9.24-5_source.buildinfo Checksums-Sha256: e5638bad77eb3a418f39ffc5d2ce6ee2466d44155bd8da67830b330cab34034e 1975 caps_0.9.24-5.dsc 095f7e4be750f504ba724fddeaeb615f13eabf0342b4d0bd206700e068252dd3 3712 caps_0.9.24-5.debian.tar.xz 8568413dbb625d0199c9fa8d6cdf7b944f439c9b35460f4c7f5c0db9f5c59186 5152 caps_0.9.24-5_source.buildinfo Files: 36bec692adec6d7c92410adda310e4fe 1975 sound optional caps_0.9.24-5.dsc 077d68bbf2473ee0e7f310a99021907c 3712 sound optional caps_0.9.24-5.debian.tar.xz d5b9b4dc960738d88b32819e4b1c0d11 5152 sound optional caps_0.9.24-5_source.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCAAyFiEEIY7gNiAzyHtsE1+ko7q64kCN1s8FAlq5MlcUHGZzYXRlbGVy QGRlYmlhbi5vcmcACgkQo7q64kCN1s/DxA//XL5stNice+b98MJG/FYlKjuFwm7B 5rSX7/j6mO7iJzWi2QwOm5+yg9Tr7glsG/0oOBbgOv3SXEZxOWN3eqdYOXZNpbta /uwwn2K6VWpwdxzjjtlXKTR25bwwoO7/DFnFWAfq8mp5nXNPQrXlS8f3fivFTJyV 16UjF43+v1kJ6MrZoOexrMlSvwWKX4Hws8nzDXKFV2TAxcsKWLz0otysgJyunvzU uB2fGXrjEd6Gns9tDNt/JXShkKr67c1vQcxKtEk6EiWX9kqtzaj7t1UK5khxmjrK waxmeD/kWPhQpjmjq5+k99QOmKxXiz7K1CMkRxPrnxmNVoTRajfddVoXy+ihoiKh DYA++hbqICefVXITyBeosDnjqfLWB5podIVABcMhK1Q4th6zCQocWZ0HoIJ3hgpA i5f89AbCB60p9MT0PxvHc2cTaC6JhvZDxb02DEuEK/jXJSSHBxdyPb+OlTKqrDRX +RHMjkoDj0sVEi3kt7u3tMmDnVC4EFpZUmZaDmeQz28CQX+DAaD+EJa+hm+xvDgI jtQK+z3gVx48M+mpgvjEIY9mNTKzwM7o0uGfpAjGu91+HJAUD7UdDgF6a8/x9gXg 0HxZiebSnm5lo1poFnlEm/0n1ULPD5PgfIxzs5iXA1rmGqX/FRJAu2nhiPtEKlkM HXjiUe0PV+lC65I= =JK41 -END PGP SIGNATURE- ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Accepted rtkit 0.11-6 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 16 Feb 2018 13:59:32 -0300 Source: rtkit Binary: rtkit Architecture: source Version: 0.11-6 Distribution: unstable Urgency: medium Maintainer: Debian Multimedia Maintainers <debian-multime...@lists.debian.org> Changed-By: Felipe Sateler <fsate...@debian.org> Description: rtkit - Realtime Policy and Watchdog Daemon Closes: 881342 Changes: rtkit (0.11-6) unstable; urgency=medium . * Move dbus and polkit from Recommends to Depends rtkit can't do much really without either of them so bump them to Depends. (Closes: #881342) * Switch maintainer to debian-multimedia@l.d.o since alioth will be going away * Update Vcs-* to point to salsa * Update standards-version (no changes needed) * Drop dh-autoreconf and autotools-dev Build-Dependencies, implied by debhelper compat 10 Checksums-Sha1: 9a416c5e32759ffb7c236b7ab7637d0e0a60a78f 2107 rtkit_0.11-6.dsc 008a10eac3f97769de18b8483cf4d8e24fd5e458 6516 rtkit_0.11-6.debian.tar.xz Checksums-Sha256: babad658f967f564ff2e5815c362be8e805062d49e19dd6c47350d0c9657a160 2107 rtkit_0.11-6.dsc 1bcdb108b37fe720d7fe470b1144b2e7e418af87ee413ec224292fbd9faee23a 6516 rtkit_0.11-6.debian.tar.xz Files: 54510c8b2fd2469cbd3b7e6cd084a583 2107 admin optional rtkit_0.11-6.dsc 3c6e3f4c2eb4a778f44161843e9ef344 6516 admin optional rtkit_0.11-6.debian.tar.xz -BEGIN PGP SIGNATURE- iQJIBAEBCAAyFiEEIY7gNiAzyHtsE1+ko7q64kCN1s8FAlqNeSAUHGZzYXRlbGVy QGRlYmlhbi5vcmcACgkQo7q64kCN1s/KZA/9Hx+k2mhW9mE5whhU14UQwZieBH4d 7OihaNdyioVxDKfQ4LY0pu0Qle25/NynYdqiv89ir3ontn/PSgpEe7LcP4Wy0beJ XD4FxC3J4IVpXnM7SxSzJ+/ZebGOQdDasSnzX8ijt7m7KvktLr5cWfGLoI75ZDDm MlZjVx+wj5yyWLkQ9JuSkBbssoNhfxN1XckTD5rexI92ddpUGqMySY+dAPhcUa9l xFeROjt7W+piod7CmNaRCOv9GqenOZkDOfRebrxeum+gfDTe30mfGtX7iZvzSyHA qcuYzfdEAyxFBYCR4W5IumxdE902G/vkWt9Z894F8otm9HEJaEeVLZir9nfxOI3e HxpC5nDlQnMzoTQDmXUIeiQ3COXPzQ6Uo/5qB0zZiSWQr9WzsOC3bNCz2j0f12YL IztsTCre5/GHvKu00p7aCPO5wiFc9dB0aVmoJ/CaIodurpImQB1s/d0pR7NP6k+O VX8S7lXRF4LX2ZZGdi7k2A4D7FvyRn51XyMPr05G5NgC/GLMlK3vigIGsjhbXYsd y5Ls1rFCwt1siAIIdxQ+NxCyk97LKG5C7wQ37beDDSvuZVPwUZi9r3bxK7MwB0Ih lRki0ICjEn8lOvb8A2VFy3AVpm9vHAphYsejoAxI13BHLYHviEN+LgFWwK5RARe8 atPw/IMtYEYvRPQ= =64LP -END PGP SIGNATURE- ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Proposed multimedia team migration to salsa.d.o
On Mon, Jan 1, 2018 at 2:43 PM, James Cowgill <jcowg...@debian.org> wrote:
> Hi,
>
> As you've probably seen, the Debian Gitlab instance salsa.debian.org is
> up and running (in beta). Since alioth.debian.org is deprecated and
> might be disabled soon, we need to migrate things over to salsa.
>
Agreed.
>
> This is what I propose. I posted it on IRC, but for more discussion I'm
> posting it to the mailing lists now.
>
> salsa.debian.org team
> ===
> A group on salsa.debian.org has been created here:
> https://salsa.debian.org/multimedia-team
>
> Existing members of the alioth team have not been migrated over which
> should help prune inactive members. Anyone who was a member of the
> alioth team can click the "Request Access" button and an someone will
> approve you.
>
> Usually, team members who are DDs are given "Owner" permissions in the
> group and other members are given "Master" permissions.
>
I have no problem with this rule. We can revisit later if needed.
> When creating a new project:
> * The project name should be the same as the source package name.
>
This is the same policy as currently, so no change here.
> * "Issues" should be disabled (use the BTS instead).
>
This has been done by default on salsa. So new projects will get issues
disabled by default.
> * A commit notification hooks should be setup (see below).
>
> New Vcs-* URLs:
>
> ```
> Vcs-Git: https://salsa.debian.org/multimedia-team/package.git
> Vcs-Browser: https://salsa.debian.org/multimedia-team/package
> ```
>
> https://lists.debian.org/debian-devel-announce/2017/12/msg3.html
> https://wiki.debian.org/Salsa/Doc
>
> New maintainer address
> ===
> There is not going to be a replacement for alioth mailing lists, so we
> are going to switch back to using "debian-multime...@lists.debian.org"
> as the mailing list used in the Maintainer field of all packages.
>
> https://lists.debian.org/debian-devel-announce/2017/09/msg4.html
OK with me.
>
> Commit notifications
> ===
> The commit mailing list is also on alioth and will soon be disabled.
> This is replaced by the "Emails on push" integration on salsa which
> sends emails to tracker.debian.org which you can subscribe to. This
> needs to be enabled manually per project.
>
> See: https://wiki.debian.org/Salsa/Doc#Email_notifications
>
> IRC notifications can be enabled using Irker. Again this needs to be
> enabled manually per project.
>
> See: https://wiki.debian.org/Salsa/Doc#IRC_notifications
>
> Automation
> ---
> Enabling these should probably be automated and checked using the GitLab
> API because inevitably someone will forget to enable it in a repository.
>
> Eg for "Emails on push":
>
> https://docs.gitlab.com/ee/api/services.html#emails-on-push
> ```
> curl -X PUT -H "Private-Token: $GITLAB_API_PRIVATE_TOKEN" -F
> "recipients=dispatch+${package}_...@tracker.debian.org"
> https://salsa.debian.org/api/v4/projects/multimedia-team%
> 2F${package}/services/emails-on-push
> ```
>
> Migration
> ===
> Migration of the maintainer email address can start immediately. New
> packages can also immediately start hosting their VCS on salsa.debian.org.
>
> For existing packages, I propose:
> - Wait until salsa.debian.org is declared stable (expected at the end of
> January)
> - Announce to the lists before migration starts
> - Set all repositories on alioth read-only (eg using a git pre-receive
> hook)
> - Migrate everything to salsa using Christoph Berg's import script:
> http://www.df7cb.de/blog/2017/Salsa_batch_import.html
We can add the email on push + irker notifications to the script here.
> At this point we should attempt to upload all packages at least once
> before the mailing list on alioth is disabled. Unfortunately this is a
> lot of work, so I am quietly hoping there will be an alternative
> solution for this so we don't loose bug reports sent to the old
> maintainer address.
>
It appears some people are working on providing a replacement for the
alioth lists, as a stop-gap for a release cycle or so:
https://lists.alioth.debian.org/pipermail/alioth-staff-replacement/Week-of-Mon-20171225/90.html
--
Saludos,
Felipe Sateler
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#877773: groovebasin crashes
Control: reassign -1 libleveldb1v5 1.20-1 Control: retitle -1 libleveldb1v5: breaks ABI without SONAME bump On Thu, Oct 5, 2017 at 8:38 AM, Thadeu Lima de Souza Cascardo <casca...@debian.org> wrote: > > Package: groovebasin > Version: 1.4.0-1 > Severity: grave > > groovebasin crashes when simply running with 'groovebasin'. Setting this > as grave as it seems to make it unusable for any user. > > I was using groovebasin during the stretch release cycle and though I > found some problems related to filename encoding, it was a great player. > > After the release, some nodejs updates seemed to require binary NMUs due > to ABI incompatibilities for some of the libraries used by groovebasin. > After they were completed, I could upgrade nodejs and groovebasin. But > for a while, I didn't run groovebasin, so didn't notice the issue. So, > it's possible that it's related to the nodejs upgrade. Thanks for this info, it proved helpful. I think the problem is that leveldb broke ABI without SONAME bump (and transition). Downgrading to 1.19 or rebuilding node-leveldown fixes the crash. I think (but my C++ fu is not very strong) that the problem is the addition of the max_file_size to the Options class. ABI tracker seems to agree with me[1]. Dear leveldb maintainers, please bump soname and do a transition. [1] https://abi-laboratory.pro/tracker/compat_report/leveldb/1.19/1.20/ecd6d/abi_compat_report.html -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#880011: csound: Macro system on csound make segfault
Control: forwarded -1 https://github.com/csound/csound/issues/871 2017-11-08 16:45 GMT-03:00 Mickael Viey <m.v...@wanadoo.fr>: > Le 08/11/2017 à 14:19, Felipe Sateler a écrit : > >> Control: forcemerge -1 880010 >> Control: tags -1 moreinfo >> >> On Sat, Oct 28, 2017 at 7:54 AM, Mickael Viey <m.v...@wanadoo.fr> wrote: >> >>> Package: csound >>> >>> Version: 1:6.08.0~dfsg-1 >>> Severity: normal >>> >>> Dear Maintainer, >>> >>> >>> I have some csd files I made on another platforms which generate >>> segfault when running with this version of csound. After diagnostic It >>> appears that the macro system which is responsible. >>> >>> By example, this macro works: >>> #define TIME # 0.25 # >>> #define freq # 146 # >>> >>> >>> #define T # $freq # >>> #define Am # $freq * 17 / 16 # >>> #define AM # $freq * 9/8 # >>> >>> But If I had this after te last line: >>> >>> #define E # $freq # >>> >>> I get a segfault. I will join the complete csd file I used for my tests. >>> >> Weird. I can reproduce on a stretch docker container, but I can't >> reproduce on sid, either with 6.09 or rebuilding 6.08 . I ran out of >> time, but could you try rebuilding csound and see if the problem >> persists? >> >> Hi, > > I am not sure what you mean by "rebuild" but this is what I done: > Thanks, but I meant recompile the csound sources, not just reinstall. Anyway, I have debugged some more. Turns out the error in sid is still present, it just doesn't cause a crash. I have forwarded upstream to the above url. The error is not due to the macro, but due to the 3/2 p7. This is invalid syntax, and that triggers the crash/malfunction (the crash is in the error printing code, heh). You can work around the problem by fixing the syntax error and passing 1.5. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#880011: csound: Macro system on csound make segfault
Control: forcemerge -1 880010 Control: tags -1 moreinfo On Sat, Oct 28, 2017 at 7:54 AM, Mickael Viey <m.v...@wanadoo.fr> wrote: > Package: csound > > Version: 1:6.08.0~dfsg-1 > Severity: normal > > Dear Maintainer, > > > I have some csd files I made on another platforms which generate > segfault when running with this version of csound. After diagnostic It > appears that the macro system which is responsible. > > By example, this macro works: > #define TIME # 0.25 # > #define freq # 146 # > > > #define T # $freq # > #define Am # $freq * 17 / 16 # > #define AM # $freq * 9/8 # > > But If I had this after te last line: > > #define E # $freq # > > I get a segfault. I will join the complete csd file I used for my tests. Weird. I can reproduce on a stretch docker container, but I can't reproduce on sid, either with 6.09 or rebuilding 6.08 . I ran out of time, but could you try rebuilding csound and see if the problem persists? -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: sox package adoption
On Sun, Nov 5, 2017 at 11:29 AM, Jaromír Mikeš <mira.mi...@gmail.com> wrote: > > > 2017-11-05 14:55 GMT+01:00 Ross Gammon <deb...@the-gammons.net>: > >> >> >> On 05/11/17 10:29, Jaromír Mikeš wrote: >> > >> > >> > 2017-11-04 17:36 GMT+01:00 Jaromír Mikeš <mira.mi...@gmail.com >> > <mailto:mira.mi...@gmail.com>>: >> > >> > >> > >> > 2017-11-04 17:30 GMT+01:00 Sebastian Ramacher <sramac...@debian.org >> > <mailto:sramac...@debian.org>>: >> > >> > On 2017-11-04 14:25:18, Jaromír Mikeš wrote: >> > > Hi, >> > > >> > > I am about to adopt sox package which I think will suite >> perfectly in >> > > pkg-multimedia team. >> > > >> > > At the moment I am having problem with import dscs ... this >> comand failed :( >> > > >> > > $ gbp import-dscs --debsnap --pristine-tar sox >> > > >> > > Any idea what to do about it? >> > >> > What's the error? >> > >> > >> > Here is output with --verbose option >> > >> > $ gbp import-dscs --debsnap --pristine-tar --verbose sox >> > >> > >> > Any progress with this? I forgot to mention that I tried same for >> > different packages with success. >> > >> > mira >> >> You could just do it manually by taking the latest dsc from the archive: >> $ dget http://httpredir.debian.org/debian/pool/main/s/sox/sox_14.4. >> 1-5.dsc >> >> And then doing a normal dsc import: >> $ gbp import-dsc --pristine-tar sox_14.4.1-5.dsc >> >> That worked for me. Of course there is no history. You could also import >> the version in old-old stable first, but there doesn't seem much point >> in that. >> > > Hi Ross, > > I was thinking the same but wanted try all possibilities first. > Anyway I filled a bug against the git-buildpackage > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880878 > > > Is there any way to import dscs files later if I will start this way and > this bug will be fixed latter? > > It appears the problem is that the changelog has some invalid lines near the end. I imported the first version manually: git init sox cd sox gbp import-dsc ../sox_11gamma-cb3-5.dsc #this fails cd .. dpkg-source -x sox_11gamma-cb3-5.dsc cp -a sox-11gama-cb3/* sox/ cd sox git add . git commit --date="26 Feb 1998 8:50:00 +0100" \ --author "Geiger Guenter <gei...@iem.mhsg.ac.at>" \ -m "Import Debian changes 11gamma-cb3-5" I was then able to use gbp import-dscs on that repo, because the faulty changelog lines are already in the repo and gbp no longer tries to read them. I have pushed my results to https://anonscm.debian.org/git/users/fsateler/sox.git if you want to use them. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#877656: kodi: supports insecure download of non-free addons
On Tue, Oct 3, 2017 at 7:04 PM, Jonas Smedegaard <d...@jones.dk> wrote: > Quoting Felipe Sateler (2017-10-03 23:32:24) >> On Tue, Oct 3, 2017 at 5:49 PM, Jonas Smedegaard <d...@jones.dk> wrote: >> > Package: kodi >> > Version: 2:17.3+dfsg1-2 >> > Severity: grave >> >> This severity feels a bit inflated. After all, you can download and >> run non-free programs using a web browser too! > > When you browse into <https://evil.example.com/>, download scarycode.sh > from there and execute it in a shell, then you are to blame if your foot > gets blown away. > > If instead you open your media center, it automatically updates an addon > but the http connection gets hijacked and redirected to > http://evil.example.com/ where scarycode.sh instead gets loaded and > blows off your foot, then I dare say not you but your media center is to > blame. Ah, this was key information I was missing (the automatic part). >> > Tags: security upstream patch >> > Justification: user security hole > > What severity would you use for user security hole? Or do you disagree > that using hardcoded http in an _internal_ interface is a user security > hole? > No, I don't disagree. I just misunderstood. > >> > Kodi supports downloading and loading addons at runtime. >> > >> > Official addon feed is served only via http and contain non-free >> > addons. >> > >> > Allowing to extend the system with non-free addons at runtime by >> > default is arguably an anti-feature in itself. Doing so insecurely >> > poses a risk of malicious code getting into users' home and executed >> > by Kodi. >> > >> > Attached patch relaxes to make addon feed optional. >> >> Making plugin feeds optional sounds good though. > > Right. > > I realize my choice of words might be confusing: feed is optional in > code with the patch, meaning it won't fail to start if missing. On the > packaging level I however intend at first to have kodi _recommend_ the > feed, so it will be pulled in by default - so until an alternative exist > it is an "opt-out" not an "opt-in". BTW, I think there are two issues conflated here: 1. Insecure downloading of code 2. Non-free addons available by default. I think your patch mainly addresses issue number 2, doesn't it? Fixing issue 1 would require asking upstream to provide https://mirrors.kodi.tv/addons/krypton/addons.xml.gz.md5 (and upgrade to a better hash algorithm). -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#877656: kodi: supports insecure download of non-free addons
On Tue, Oct 3, 2017 at 5:49 PM, Jonas Smedegaard <d...@jones.dk> wrote: > Package: kodi > Version: 2:17.3+dfsg1-2 > Severity: grave This severity feels a bit inflated. After all, you can download and run non-free programs using a web browser too! > Tags: security upstream patch > Justification: user security hole > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Kodi supports downloading and loading addons at runtime. > > Official addon feed is served only via http and contain non-free addons. > > Allowing to extend the system with non-free addons at runtime by default > is arguably an anti-feature in itself. Doing so insecurely poses a risk > of malicious code getting into users' home and executed by Kodi. > > Attached patch relaxes to make addon feed optional. Making plugin feeds optional sounds good though. > > I intend to move the addons feed configuration file to a separate > package "kodi-repository-kodi" and, at first, ship that package in main > recommended by kodi. > > Later when an alternate package "kodi-repository-curated" is available¹, > I intend to favor that over kodi-repository-kodi and move the latter to > contrib. I don't think moving to contrib makes sense. Either the package fits the requirements for main or it doesn't. I don't think this package should go in contrib, as it doesn't *need* any software not available in main. So it should not be moved there. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Repacking of rtmidi
Why do we do it? There is no documentation about it :( . In particular, some reasons (windows stuff) does not appear to be relevant anymore. The doc images are also removed, do we think they are non-free ? -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: boost problem while packaging SuperCollider 3.8
On Thu, Sep 28, 2017 at 7:05 PM, Dan S <danstowell+de...@gmail.com> wrote: > > 2017-09-26 9:49 GMT+01:00 Dan S <danstowell+de...@gmail.com>: > > 2017-09-26 9:26 GMT+01:00 Dan S <danstowell+de...@gmail.com>: > >> 2017-09-25 16:36 GMT+01:00 Felipe Sateler <fsate...@debian.org>: > >>> On Mon, Sep 25, 2017 at 12:22 PM, Felipe Sateler <fsate...@debian.org> > >>> wrote: > >>>> On Mon, Sep 25, 2017 at 11:14 AM, Dan S <danstowell+de...@gmail.com> > >>>> wrote: > >>>>> > >>>>> 2017-09-25 13:48 GMT+01:00 Felipe Sateler <fsate...@debian.org>: > >>>>> > > >>>>> > > >>>>> > On Mon, Sep 25, 2017 at 7:37 AM, Dan S <danstowell+de...@gmail.com> > >>>>> > wrote: > >>>>> >> > >>>>> >> Hi > >>>>> >> > >>>>> >> I'm trying to get the new release 3.8 of SuperCollider into the > >>>>> >> debian-multimedia repository. I've done an import to git here (not > >>>>> >> pushed yet). The problem is SC's dependency on boost. > >>>>> > > >>>>> > > >>>>> > Please push, so that I can try to reproduce locally. > >>>>> > >>>>> OK, done. > >>>> > >>>> Oh I'm so terribly sorry. I see now that I forgot to push the last > >>>> upload, which fixes the FTBFS with gcc 7. I'm now merging your changes > >>>> with mine to see if things build. I believe this should fix at least > >>>> some problems with newer gcc. > >>> > >>> Indeed, the patches Adrian Bunk sent fix the failure to build. I have > >>> force pushed the changes to git (so please use git reset instead of a > >>> simple pull). Some are already upstream but it appears the > >>> PyrSched.cpp one is not yet. > >>> > >>> I'm sorry for causing additional work :( > >> > >> OK, thanks. > >> > >> On the latest master then: > >> * I refreshed patches (because "gbp -S" failing complaining about fuzzy > >> patches) > >> * Build failed on gcc 7 due to an ICE while compiling some part of > >> supernova > >> * I'm running a gcc 6 build today, I'll let you know if it completes. > > > > ...failed due to ICE again :( Something while building supernova > > OK, now after much updating of packages on my machine, and I have a > successful build! Hurrah! > > My build succeeded as of commit 79d7a5320, plus a local commit in > which I ensured it was using GCC 6 (6.4.0). > (It failed with an internal compiler error when I allowed it to > default to GC 7.2.0.) Weird. It builds here and on debomatic[1]. [1] http://debomatic-amd64.debian.net/distribution#unstable/supercollider/3.8.0~repack-1/buildlog > > Someone else (Miguel) also reported he can compile and run the 3.8.0 > version from the debian-multimedia repository now. Excellent! I have pushed a few changes, including a repack fix (the portaudio dir name changed). If you think this looks good I can upload (unless there is more stuff pending?). -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: boost problem while packaging SuperCollider 3.8
On Mon, Sep 25, 2017 at 12:22 PM, Felipe Sateler <fsate...@debian.org> wrote: > On Mon, Sep 25, 2017 at 11:14 AM, Dan S <danstowell+de...@gmail.com> wrote: >> >> 2017-09-25 13:48 GMT+01:00 Felipe Sateler <fsate...@debian.org>: >> > >> > >> > On Mon, Sep 25, 2017 at 7:37 AM, Dan S <danstowell+de...@gmail.com> wrote: >> >> >> >> Hi >> >> >> >> I'm trying to get the new release 3.8 of SuperCollider into the >> >> debian-multimedia repository. I've done an import to git here (not >> >> pushed yet). The problem is SC's dependency on boost. >> > >> > >> > Please push, so that I can try to reproduce locally. >> >> OK, done. > > Oh I'm so terribly sorry. I see now that I forgot to push the last > upload, which fixes the FTBFS with gcc 7. I'm now merging your changes > with mine to see if things build. I believe this should fix at least > some problems with newer gcc. Indeed, the patches Adrian Bunk sent fix the failure to build. I have force pushed the changes to git (so please use git reset instead of a simple pull). Some are already upstream but it appears the PyrSched.cpp one is not yet. I'm sorry for causing additional work :( >> >> >> The upstream includes boost in the download, and so to be Debian-like, >> >> we strip that out and use system boost instead. This works in prev >> >> releases, but in 3.8 (which has updated to use boost 1.63) it errors >> >> out with confusing compiler/linker problems: >> >> https://github.com/supercollider/supercollider/issues/3203 >> >> >> > >> > I notice you are using wheezy. I'd first try building in sid. BTW, where >> > did >> > you get boost 1.63? Unstable has 1.62... >> >> "libboost1.63-dev" etc packages > > OK, why did you bump these deps? I don't see any specific requirement > for 1.63 (at least with a quick grep through the sources). > I did not keep this commit in the forced push (but have kept locally in case it is still needed), because SC built fine without it. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: boost problem while packaging SuperCollider 3.8
On Mon, Sep 25, 2017 at 11:14 AM, Dan S <danstowell+de...@gmail.com> wrote: > > 2017-09-25 13:48 GMT+01:00 Felipe Sateler <fsate...@debian.org>: > > > > > > On Mon, Sep 25, 2017 at 7:37 AM, Dan S <danstowell+de...@gmail.com> wrote: > >> > >> Hi > >> > >> I'm trying to get the new release 3.8 of SuperCollider into the > >> debian-multimedia repository. I've done an import to git here (not > >> pushed yet). The problem is SC's dependency on boost. > > > > > > Please push, so that I can try to reproduce locally. > > OK, done. Oh I'm so terribly sorry. I see now that I forgot to push the last upload, which fixes the FTBFS with gcc 7. I'm now merging your changes with mine to see if things build. I believe this should fix at least some problems with newer gcc. > > >> The upstream includes boost in the download, and so to be Debian-like, > >> we strip that out and use system boost instead. This works in prev > >> releases, but in 3.8 (which has updated to use boost 1.63) it errors > >> out with confusing compiler/linker problems: > >> https://github.com/supercollider/supercollider/issues/3203 > >> > > > > I notice you are using wheezy. I'd first try building in sid. BTW, where did > > you get boost 1.63? Unstable has 1.62... > > "libboost1.63-dev" etc packages OK, why did you bump these deps? I don't see any specific requirement for 1.63 (at least with a quick grep through the sources). -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: boost problem while packaging SuperCollider 3.8
On Mon, Sep 25, 2017 at 7:37 AM, Dan S <danstowell+de...@gmail.com> wrote: > Hi > > I'm trying to get the new release 3.8 of SuperCollider into the > debian-multimedia repository. I've done an import to git here (not > pushed yet). The problem is SC's dependency on boost. > Please push, so that I can try to reproduce locally. > > The upstream includes boost in the download, and so to be Debian-like, > we strip that out and use system boost instead. This works in prev > releases, but in 3.8 (which has updated to use boost 1.63) it errors > out with confusing compiler/linker problems: > https://github.com/supercollider/supercollider/issues/3203 > > I notice you are using wheezy. I'd first try building in sid. BTW, where did you get boost 1.63? Unstable has 1.62... > The SC team actually have patches applied to their own boost: > https://github.com/supercollider/supercollider/blob/develop/external_ > libraries/boost_sc_changes.patch > > This looks unrelated (at least the first part). > It's possible that using bundled+patched boost would fix these > difficulties, though I'm not sure if this would be acceptable. > Grateful for any insights. > It is possible, but lets first rule out other causes. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#872860: csound FTBFS with libgmm++-dev 5.2+dfsg1-5
Control: forwarded -1 https://github.com/csound/csound/pull/839 On Tue, Aug 22, 2017 at 4:07 PM, Anton Gladky <gl...@debian.org> wrote: > tags 872860 +patch > thanks > > Dear maintainers, > > in attachment you will find a patch which fixes FTBFS due to a new > getfem (gmm) version. It would be good if somebody reviews and tests > it properly. Thanks for the patch. There is a problem though: the `<<std::endl` call has been omitted. I have proposed a different patch upstream, and am waiting on that to be accepted to include in debian. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: qm-dsp DM flag
On Fri, Aug 18, 2017 at 9:24 AM, Jaromír Mikeš <mira.mi...@gmail.com> wrote: > > > 2017-08-15 20:26 GMT+02:00 Jaromír Mikeš <mira.mi...@gmail.com>: >> >> >> can someone grant me DM flag for qm-dsp package. >> > > ping ;) > I need this flag to close this bug: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872249 Done. Should be processed in a few minutes. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-csound on raspbian
Hi Dirk, On Sun, Aug 13, 2017 at 4:58 AM, Dirk Stromberg <dirkstromb...@gmail.com> wrote: > Dear List, > > I am having issues getting csound6~ to work on raspbian. I have managed to > get it to work on ubuntu mate, but there seems to be an issue with the > installation on raspbian. The error is flagged in the pd console: > > "undefined symbol: canvas_dspstate" This function does not appear to exist in pd 0.46.2, but is present on 0.47 . Therefore, it appears that the pd externals are being built for a newer version of pd than what you have. Where are you getting your pd externals from? I think simply rebuilding against 0.46.2 should fix the issue. That said, 0.47 is available in stretch. I suppose you could upgrade your raspbian to stretch and the issue should be fixed. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#853671: supercollider: ftbfs with GCC-7
Hi Dan, On Tue, Jan 31, 2017 at 6:36 AM, Matthias Klose <d...@debian.org> wrote: > Package: src:supercollider > Version: 1:3.7.0~repack-4 > Severity: normal > Tags: sid buster > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-7 > > The package fails to build in a test rebuild on at least amd64 with > gcc-7/g++-7, but succeeds to build with gcc-6/g++-6. The > severity of this report may be raised before the buster release. > There is no need to fix this issue in time for the stretch release. The severity was raised so now it is RC. I also see that there are newer upstream releases. Maybe this issue does not exist in the newer release? -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: My Status in Debian
On Sat, Apr 22, 2017 at 7:34 AM, Ross Gammon <deb...@the-gammons.net> wrote: > Hi Team, > > I know I am not a guru like most of you in the team, and that and my busy > life means I am a little slow sometimes, and haven't produced a lot of work > in the team. But I also spend a lot of my time working on dependencies > (javascript & python) for > packages in the GIS team, and I also work on Ubuntu Studio (which is why I am > interested in Multimedia packages). > > Anyway, one of my other sponsors has stated a few times when I have > asked for DM rights for something, that maybe it was time to step up to > DD status. > > I am in no hurry (probably would aim to take the plunge towards the > middle of the year). And I wouldn't do it until there was wider support > for that. So any words of encouragement, or any suggestions of things > that you would like to see from me before you would endorse me are > welcome (here or in private). I agree with Jonas. Just do it. I'll add just one more comment: > I know I am not a guru like most of you in the team This is not relevant. What is important is to know when you don't know, and then to know where to look for the relevant information, or where to ask for help. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#859022: unblock: stk/4.5.2+dfsg-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, Please unblock source package stk. The update fixes two RC bugs: * Use debian RAWWAVE_PATH in stk-demo. (Closes: #858895) * Fix link targets for RtAudio and RtMidi header files (Closes: #858957) Attached is the debdiff between -4 and -5 unblock stk/4.5.2+dfsg-5 -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) diff -Nru stk-4.5.2+dfsg/debian/changelog stk-4.5.2+dfsg/debian/changelog --- stk-4.5.2+dfsg/debian/changelog 2016-12-24 15:15:56.0 -0300 +++ stk-4.5.2+dfsg/debian/changelog 2017-03-29 10:39:43.0 -0300 @@ -1,3 +1,10 @@ +stk (4.5.2+dfsg-5) unstable; urgency=medium + + * Use debian RAWWAVE_PATH in stk-demo. (Closes: #858895) + * Fix link targets for RtAudio and RtMidi header files (Closes: #858957) + + -- Felipe Sateler <fsate...@debian.org> Wed, 29 Mar 2017 10:39:43 -0300 + stk (4.5.2+dfsg-4) unstable; urgency=medium [ Petter Reinholdtsen ] diff -Nru stk-4.5.2+dfsg/debian/libstk0-dev.links stk-4.5.2+dfsg/debian/libstk0-dev.links --- stk-4.5.2+dfsg/debian/libstk0-dev.links 2016-12-24 15:15:56.0 -0300 +++ stk-4.5.2+dfsg/debian/libstk0-dev.links 2017-03-29 10:39:43.0 -0300 @@ -1,2 +1,2 @@ -usr/include/RtAudio.h usr/include/stk/RtAudio.h -usr/include/RtMidi.h usr/include/stk/RtMidi.h +usr/include/rtaudio/RtAudio.h usr/include/stk/RtAudio.h +usr/include/rtmidi/RtMidi.h usr/include/stk/RtMidi.h diff -Nru stk-4.5.2+dfsg/debian/patches/demo-use-RAWWAVE_PATH-instead-of-hardcoded-string.patch stk-4.5.2+dfsg/debian/patches/demo-use-RAWWAVE_PATH-instead-of-hardcoded-string.patch --- stk-4.5.2+dfsg/debian/patches/demo-use-RAWWAVE_PATH-instead-of-hardcoded-string.patch 1969-12-31 21:00:00.0 -0300 +++ stk-4.5.2+dfsg/debian/patches/demo-use-RAWWAVE_PATH-instead-of-hardcoded-string.patch 2017-03-29 10:39:43.0 -0300 @@ -0,0 +1,21 @@ +From: Felipe Sateler <fsate...@debian.org> +Date: Wed, 29 Mar 2017 10:28:40 -0300 +Subject: demo: use RAWWAVE_PATH instead of hardcoded string + +--- + projects/demo/demo.cpp | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/projects/demo/demo.cpp b/projects/demo/demo.cpp +index c877b4a..3e74769 100644 +--- a/projects/demo/demo.cpp b/projects/demo/demo.cpp +@@ -213,7 +213,7 @@ int main( int argc, char *argv[] ) + + // Depending on how you compile STK, you may need to explicitly set + // the path to the rawwave directory. +- Stk::setRawwavePath( "../../rawwaves/" ); ++ Stk::setRawwavePath( RAWWAVE_PATH ); + + // By default, warning messages are not printed. If we want to see + // them, we need to specify that here. diff -Nru stk-4.5.2+dfsg/debian/patches/series stk-4.5.2+dfsg/debian/patches/series --- stk-4.5.2+dfsg/debian/patches/series2016-12-24 15:15:56.0 -0300 +++ stk-4.5.2+dfsg/debian/patches/series2017-03-29 10:39:43.0 -0300 @@ -7,3 +7,4 @@ demo-needs-rt.patch Sort-o-files Do-not-override-user-supplied-CXXFLAGS.patch +demo-use-RAWWAVE_PATH-instead-of-hardcoded-string.patch ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#855834: linuxptp: default startup argument "-i eth0" should be removed
On Wed, Feb 22, 2017 at 10:31 AM, Tino Mettler <tino.mett...@tikei.de> wrote: > On Wed, Feb 22, 2017 at 09:51:25 -0300, Felipe Sateler wrote: > > [...] > >> The readme suggests ptp4l can detect appropiate devices by itself. If >> that is true, then there is no problem to be solved :). > > Hi, > > do you mean this? > > - >If the ethtool ioctl is available, then the ptp4l program will use >it in order to discover the proper PHC device. > - Yes, that's what I was reading. > > This means that ptp4l can find the proper PHC device (/dev/ptpX) that > belongs to a certain ethernet interface (like eth0). Before that, the > user had to specify both the ethernet interface (-i) and the PHC device > (-p) to use. > > The ethernet interface still has to be specified either on the command > line (-i option) or in the config file. > > From the manual page: > > >-i interface > Specify a PTP port, it may be used multiple times. At > least one port must be specified by this option or in > the configuration file. > OK. I don't have any clue about linuxptp, so I'm going by what I read. > > >> >> If that is not true, I suggest the following: >> >> 1. Convert ptp4l into a template unit, ptp4l@.service >> 2. Change the device to be the instance: >> ExecStart=ExecStart=/usr/sbin/ptp4l -f /etc/linuxptp/ptp4l.conf -i %i >> 3. Do not enable the unit. >> 4. Add a udev rule that starts the (properly instanced) service when >> it is detected. >> >> You can see the ifupdown package for a similar approach: there is >> ifup@.service, a udev rule, and a helper program (ifupdown-hotplug) >> that determines if an instance should be started for the given device. > > Thanks. I don't fully understand 4. What exactly should be detected, > and how? A network card. A rule like the following: SUBSYSTEM=="net", ACTION=="add|remove", RUN+="ptp-hotplug " Will run the program /lib/udev/ptp-hotplug. In that program you should be able to use the INTERFACE environment variable to then start the appropriate service: if [ -d /run/systemd/system ] ; then systemctl --no-block start \ $(systemd-escape --template linuxptp@.service $INTERFACE) systemctl --no-block start \ $(systemd-escape --template phc2sys@.service $INTERFACE) fi > >> While I looked at the service files, I noticed you order them after >> chrony, ntpdate and other time services. Systemd defines a standard >> place for that, so you can replace all those alternatives with >> `time-sync.target`. > > Thanks for the suggestions. Currently, I just look how Fedora sets up > the services and do the same, so I'm always open for suggestions how to > improve them. Great. Hopefully the service files eventually reach upstream... -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#855834: linuxptp: default startup argument "-i eth0" should be removed
Hi On Wed, Feb 22, 2017 at 7:36 AM, Tino Mettler <tino.mett...@tikei.de> wrote: > On Wed, Feb 22, 2017 at 10:59:08 +0100, Norbert Lange wrote: > > [...] > >> I would recommend removing the argument, and add a section for the device in >> the >> configuration file. can be a placeholder like [eth0], I would not know >> of a good default name that would fit most systems. > > Hi, > > thanks for the comments. If I got this right, there won't be a default > name that would fit most systems as of Stretch and later. That is correct. > > A userfriedly approach would be to look for a device with PTP support > and use this, or supply a debconf request with devices that can be > used. I'll try to incorporate this. My debconf foo is limited. though, > so this might take a while. The readme suggests ptp4l can detect appropiate devices by itself. If that is true, then there is no problem to be solved :). If that is not true, I suggest the following: 1. Convert ptp4l into a template unit, ptp4l@.service 2. Change the device to be the instance: ExecStart=ExecStart=/usr/sbin/ptp4l -f /etc/linuxptp/ptp4l.conf -i %i 3. Do not enable the unit. 4. Add a udev rule that starts the (properly instanced) service when it is detected. You can see the ifupdown package for a similar approach: there is ifup@.service, a udev rule, and a helper program (ifupdown-hotplug) that determines if an instance should be started for the given device. While I looked at the service files, I noticed you order them after chrony, ntpdate and other time services. Systemd defines a standard place for that, so you can replace all those alternatives with `time-sync.target`. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#855605: rtkit uses dbus_message_new_error_printf unsafely
On Mon, Feb 20, 2017 at 3:28 PM, Andrew Shadura <andrew.shad...@collabora.co.uk> wrote: > Package: rtkit > Version: 0.11-4 > Severity: important > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Dear Maintainer, > > rtkit uses dbus_message_new_error_printf in an unsafe way, which also causes > it to FTBFS when it builds against a newer dbus version (e.g. 1.11.8 and > newer, available in experimental): Do you consider this something that should be fixed in stretch? I just realized I have a pile of pending changes that are not appropriate for the freeze, so I'd have to prepare an upload for this. In any case I applied your patch to the git repo. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#850855: [rtkit] rtkit daemon fails to start
Control: tags -1 - unreproducible moreinfo Control: reassign -1 systemd Control: affects -1 rtkit Control: retitle -1 Units with PrivateTmp fail when /var is a symlink Control: severity -1 normal On 12 January 2017 at 04:46, Bogdan Vatra <bogdan.va...@kdab.com> wrote: > Hi, > > I have an update, some time ago (~1year) I run out of space on my system > partition and I decide to move /var folder to another partition and symlink it > back to / partition. Today I just moved back my var folder and rtkit daemon > started to work ... :) This is a bug in systemd. A related issue is https://github.com/systemd/systemd/issues/3867 , but that is supposedly fixed in 232. BogDan, do you have version 232 installed? It may be that the issue is not fully fixed yet. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#850855: [rtkit] rtkit daemon fails to start
On 11 January 2017 at 13:05, Bogdan Vatra <bogdan.va...@kdab.com> wrote: > On miercuri, 11 ianuarie 2017 12:40:23 EET Felipe Sateler wrote: >> On 11 January 2017 at 12:37, Bogdan Vatra <bogdan.va...@kdab.com> wrote: >> > On miercuri, 11 ianuarie 2017 10:12:00 EET Felipe Sateler wrote: >> >> Control: tags -1 moreinfo unreproducible >> >> >> >> On 11 January 2017 at 04:59, Bogdan Vatra <bogdan.va...@kdab.com> wrote: >> >> > On miercuri, 11 ianuarie 2017 09:48:16 EET Bogdan Vatra wrote: >> >> >> On marți, 10 ianuarie 2017 17:20:28 EET Felipe Sateler wrote: >> >> >> > Hi, >> >> >> > >> >> >> > On 10 January 2017 at 16:05, Bogdan Vatra <bogdan.va...@kdab.com> >> > >> > wrote: >> >> >> > > Package: rtkit >> >> >> > > Version: 0.11-4 >> >> >> > > Severity: important >> >> >> > > >> >> >> > > --- Please enter the report below this line. --- >> >> >> > > >> >> >> > > This bug is pretty annoying because it makes pulseaudio unusable >> >> >> > > (see >> >> >> > > #850806). >> >> >> > >> >> >> > > Here are the logs: >> >> >> > >> >> >> > >> >> >> > > -- Unit rtkit-daemon.service has begun starting up. >> >> >> > > ian 10 21:00:32 zmeu rtkit-daemon[19342]: Failed to connect to >> >> >> > > system >> >> >> > > bus: >> >> >> > > Failed to connect to socket /var/run/dbus/system_bus_socket: No su >> >> >> > >> >> >> > This suggests that dbus is not running. Could that be the case? Do >> >> >> > other dbus-interacting apps misbehave? >> >> >> >> >> >> I think that's a wrong message ... because : >> >> >> >> >> >> $ ls -l /var/run/dbus/system_bus_socket >> >> >> srw-rw-rw- 1 root root 0 ian 10 09:42 /var/run/dbus/system_bus_socket >> >> >> >> >> >> That file exists and dbus works fine (all my KDE/Qt apps works ok). >> >> > >> >> > If I manually run "/usr/lib/rtkit/rtkit-daemon" it works just fine... >> >> > The only problem is when I start it with "systemctl start rtkit- >> >> > daemon.service". >> >> >> >> Weird. Could you repeat the same with the daemon as started by systemd? >> >> >> >> Use `systemctl edit --full rtkit-daemon` to edit the ExecStart line. >> > >> > It is the same thing ... : >> > [...] >> > ExecStart=/usr/lib/rtkit/rtkit-daemon >> > [...] >> > Actually I was inspired from that file to exec >> > "/usr/lib/rtkit/rtkit-daemon" manually :). >> >> Sorry, I was not clear. I meant stracing the daemon. > > Attached the log. Hmm. I guess it's not my day, I can't explain myself :( Please run the rtkit-daemon under strace, with systemd: edit the systemd service like so: ExecStart=/usr/bin/strace -o /tmp/strace.log -ff /usr/lib/rtkit/rtkit-daemon then do a `systemctl daemon-reload` and a restart of the rtkit-daemon. Then please attach the /tmp/strace.log.$PID file. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#850855: [rtkit] rtkit daemon fails to start
On 11 January 2017 at 12:37, Bogdan Vatra <bogdan.va...@kdab.com> wrote: > On miercuri, 11 ianuarie 2017 10:12:00 EET Felipe Sateler wrote: >> Control: tags -1 moreinfo unreproducible >> >> On 11 January 2017 at 04:59, Bogdan Vatra <bogdan.va...@kdab.com> wrote: >> > On miercuri, 11 ianuarie 2017 09:48:16 EET Bogdan Vatra wrote: >> >> On marți, 10 ianuarie 2017 17:20:28 EET Felipe Sateler wrote: >> >> > Hi, >> >> > >> >> > On 10 January 2017 at 16:05, Bogdan Vatra <bogdan.va...@kdab.com> > wrote: >> >> > > Package: rtkit >> >> > > Version: 0.11-4 >> >> > > Severity: important >> >> > > >> >> > > --- Please enter the report below this line. --- >> >> > > >> >> > > This bug is pretty annoying because it makes pulseaudio unusable (see >> >> > > #850806). >> >> > >> >> > > Here are the logs: >> >> > >> >> > >> >> > > -- Unit rtkit-daemon.service has begun starting up. >> >> > > ian 10 21:00:32 zmeu rtkit-daemon[19342]: Failed to connect to system >> >> > > bus: >> >> > > Failed to connect to socket /var/run/dbus/system_bus_socket: No su >> >> > >> >> > This suggests that dbus is not running. Could that be the case? Do >> >> > other dbus-interacting apps misbehave? >> >> >> >> I think that's a wrong message ... because : >> >> >> >> $ ls -l /var/run/dbus/system_bus_socket >> >> srw-rw-rw- 1 root root 0 ian 10 09:42 /var/run/dbus/system_bus_socket >> >> >> >> That file exists and dbus works fine (all my KDE/Qt apps works ok). >> > >> > If I manually run "/usr/lib/rtkit/rtkit-daemon" it works just fine... >> > The only problem is when I start it with "systemctl start rtkit- >> > daemon.service". >> >> Weird. Could you repeat the same with the daemon as started by systemd? >> >> Use `systemctl edit --full rtkit-daemon` to edit the ExecStart line. > > It is the same thing ... : > [...] > ExecStart=/usr/lib/rtkit/rtkit-daemon > [...] > Actually I was inspired from that file to exec "/usr/lib/rtkit/rtkit-daemon" > manually :). Sorry, I was not clear. I meant stracing the daemon. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#850855: [rtkit] rtkit daemon fails to start
Control: tags -1 moreinfo unreproducible On 11 January 2017 at 04:59, Bogdan Vatra <bogdan.va...@kdab.com> wrote: > On miercuri, 11 ianuarie 2017 09:48:16 EET Bogdan Vatra wrote: >> On marți, 10 ianuarie 2017 17:20:28 EET Felipe Sateler wrote: >> > Hi, >> > >> > On 10 January 2017 at 16:05, Bogdan Vatra <bogdan.va...@kdab.com> wrote: >> > > Package: rtkit >> > > Version: 0.11-4 >> > > Severity: important >> > > >> > > --- Please enter the report below this line. --- >> > > >> > > This bug is pretty annoying because it makes pulseaudio unusable (see >> > > #850806). >> > >> > > Here are the logs: >> > >> > >> > > -- Unit rtkit-daemon.service has begun starting up. >> > > ian 10 21:00:32 zmeu rtkit-daemon[19342]: Failed to connect to system >> > > bus: >> > > Failed to connect to socket /var/run/dbus/system_bus_socket: No su >> > >> > This suggests that dbus is not running. Could that be the case? Do >> > other dbus-interacting apps misbehave? >> >> I think that's a wrong message ... because : >> >> $ ls -l /var/run/dbus/system_bus_socket >> srw-rw-rw- 1 root root 0 ian 10 09:42 /var/run/dbus/system_bus_socket >> >> That file exists and dbus works fine (all my KDE/Qt apps works ok). >> > > If I manually run "/usr/lib/rtkit/rtkit-daemon" it works just fine... > The only problem is when I start it with "systemctl start rtkit- > daemon.service". Weird. Could you repeat the same with the daemon as started by systemd? Use `systemctl edit --full rtkit-daemon` to edit the ExecStart line. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#850855: [rtkit] rtkit daemon fails to start
Hi, On 10 January 2017 at 16:05, Bogdan Vatra <bogdan.va...@kdab.com> wrote: > Package: rtkit > Version: 0.11-4 > Severity: important > > --- Please enter the report below this line. --- > > This bug is pretty annoying because it makes pulseaudio unusable (see > #850806). > > Here are the logs: > -- Unit rtkit-daemon.service has begun starting up. > ian 10 21:00:32 zmeu rtkit-daemon[19342]: Failed to connect to system bus: > Failed to connect to socket /var/run/dbus/system_bus_socket: No su This suggests that dbus is not running. Could that be the case? Do other dbus-interacting apps misbehave? -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: abGate in Debian
On 6 January 2017 at 08:25, Jaromír Mikeš <mira.mi...@gmail.com> wrote: > 2017-01-06 11:46 GMT+01:00 <anta...@hippie.lt>: >> On 2016-12-28 14:55, treb...@tuxfamily.org wrote: > > Hi > >>> The Debian multimedia team is currently thinking of removing abGate >>> from the repositories for the next Debian "stretch" since it's buggy >>> (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824353 ). I >>> just wanted to let aware of this in the hope it could be of a push to >>> you. Stretch is going to happen in a few months, so if you'd like to >>> tell that it's still in active development, please do. > >> This bug should be fixed now. New release is available on github: >> https://github.com/antanasbruzas/abGate/releases/ > > Thank you Anastas! Unfortunately at the moment debian is in "freeze" > state (from yesterday) > and new upstream releases are not accepted :( It is my understanding that new versions can still be uploaded. New packages are not acceptable anymore. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
New pulseaudio version in experimental, please test
Hi all, This is a bit OT, since pulseaudio is not under the pkg-mm umbrella, but as you probably use it anyway, I figured I would announce here as well. Pulseaudio 9.99.1 has today been uploaded to experimental. Testing of it is appreciated, as I want to determine if the new version should be uploaded to unstable before the hard freeze. Thanks! -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] ffmpeg/master: Don't enable x11grab, which has been replaced with xcb.
On 6 November 2016 at 16:40, <aca-gu...@users.alioth.debian.org> wrote: > The following commit has been merged in the master branch: > commit 390d78a3b516af0544264fa0b11ea5cefeec5943 > Author: Andreas Cadhalpun <andreas.cadhal...@googlemail.com> > Date: Sun Nov 6 19:54:10 2016 +0100 > > Don't enable x11grab, which has been replaced with xcb. > > diff --git a/debian/control b/debian/control > index 6c7d733..e7bc0f9 100644 > --- a/debian/control > +++ b/debian/control > @@ -137,8 +137,6 @@ Build-Depends: > libx264-dev [!powerpcspe] , > # --enable-libx265 > libx265-dev (>= 1.8), > -# --enable-x11grab > - libxext-dev, > # --enable-libxvid > libxvidcore-dev, > # autodetected: decoder 'mpeg_xvmc'; outdev 'xv' > diff --git a/debian/rules b/debian/rules > index e9f90ed..f59b8eb 100755 > --- a/debian/rules > +++ b/debian/rules > @@ -88,8 +88,7 @@ CONFIG := --prefix=/usr \ > --enable-libzmq \ > --enable-libzvbi \ > --enable-opengl \ > - --enable-sdl2 \ > - --enable-x11grab > + --enable-sdl2 I think explicitly disabling is useful. Having a build that differs due to to extraneous packages installed is annoying. Sometimes, allowing autodetection is useful: for example, it can lower the diff between Debian and some other build that has some extra libraries. However, explicit settings should be preferred whenever possible: 1. They don't enable hidden features when an extra package is installed 2. Should a bug occur in the autodetection code, or on the depended package, the feature will be silently disabled instead of failing the build. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#843166: kodi: block migration to testing untill all reverse dependencies are ready
On 4 November 2016 at 11:57, Bálint Réczey <bal...@balintreczey.hu> wrote: > Hi Felipe, > > 2016-11-04 15:50 GMT+01:00 Felipe Sateler <fsate...@debian.org>: >> On 4 November 2016 at 11:21, Balint Reczey <bal...@balintreczey.hu> wrote: >>> Source: kodi >>> Version: 17.0~beta5+dfsg1-1 >>> Severity: grave >>> >>> To not break testing users' addon configuration I'm blocking kodi's >>> migration to testing until all addons are ready to migrate together. >>> >>> Close this bug when all reverse dependencies are ready. >> >> It seems to me that then kodi and the plugin should have stricter >> dependencies. Maybe kodi should Provides: kodi-plugin-$version and the >> plugins should Depend: on that? > > Yes, this is the plan and Tobias already offered implementing it later. Great! -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#837468: csoundqt: FTBFS: Project ERROR: A valid csound library was not found.
Control: forcemerge 837273 -1 Hi, On 11 September 2016 at 16:42, Chris Lamb <la...@debian.org> wrote: > Source: csoundqt > Version: 0.9.2.1-3 > Severity: serious > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > csoundqt fails to build from source in unstable/amd64: Thanks for reporting! This bug is actually in src:csound, and was filed a few days ago. I'm merging the bugs. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#837273: csoundqt: FTBFS: Project ERROR: A valid csound library was not found.
Control: reassign -1 libcsound64-dev Control: found -1 1:6.07.0~dfsg-3 Control: retitle -1 libcsound64-dev: missing .so symlink On 10 September 2016 at 04:18, Lucas Nussbaum <lu...@debian.org> wrote: > Source: csoundqt > Version: 0.9.2.1-3 > Severity: serious > Tags: stretch sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20160910 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. > >> Project MESSAGE: Searching /usr/lib/libcsound64.so >> Project MESSAGE: Searching /usr/lib/libcsound64.a >> Project ERROR: A valid csound library was not found. >> /usr/share/cdbs/1/class/qmake.mk:45: recipe for target 'Makefile' failed >> make: *** [Makefile] Error 3 Turns out the latest csound upload somehow is missing the dev symlink. Will take a look. Thanks for reporting! -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: debug-file-with-no-debug-symbols
On 25 August 2016 at 11:50, Jaromír Mikeš <mira.mi...@gmail.com> wrote:
> 2016-08-25 15:03 GMT+02:00 Felipe Sateler <fsate...@debian.org>:
>> On 25 August 2016 at 09:39, Jaromír Mikeš <mira.mi...@gmail.com> wrote:
>>> Hi all,
>>>
>>> I have a plenty of these warnings in eq10q package :(
>>>
>>> W: eq10q-dbgsym: debug-file-with-no-debug-symbols
>>> usr/lib/debug/.build-id/04/acdb8bc701b4237e2de4a94680dc5af26e3d14.debug
>>>
>>> I didn't have any problems with debugging symbols before ... any idea
>>> how to fix it?
>>
>> The upstream build system is ignoring the flags from the
>> environment[1]. It should not set that variable, but only add to it:
>>
>> set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ...")
>>
>>
>> [1]
>> https://anonscm.debian.org/cgit/pkg-multimedia/eq10q.git/tree/CMakeLists.txt#n6
>
> I have just push patch which fixing this issue.
> Can you check if it is correct?
I think add_definitions is not correct, as it adds CPPFLAGS. Thus the
same flags will be added both to gcc and g++. And in this case will
result in gcc being called with -std=c++11, which I don't think makes
much sense ;)
I would use the approach I quoted before of using the previous value
of CMAKE_C_FLAGS, and then separately for CMAKE_CXX_FLAGS:
##ADD_DEFINITIONS(-Wall -O3 -fPIC -finline-functions
-finline-functions-called-once -msse -mfpmath=sse -std=c99)
-set(CMAKE_C_FLAGS "-Wall -O3 -fPIC -finline-functions
-finline-functions-called-once -std=c99")
+set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -O3 -fPIC
-finline-functions -finline-functions-called-once -std=c99")
#set(CMAKE_C_FLAGS "-Wall -O0 -g -fPIC -finline-functions
-finline-functions-called-once -msse -mfpmath=sse -std=c99")
-set(CMAKE_CXX_FLAGS "-Wall -fPIC -std=c++11")
-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -fPIC -std=c++11")
--
Saludos,
Felipe Sateler
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: .gitignore (was Re: Help offered with xwax package)
On 11 August 2016 at 04:43, IOhannes m zmölnig (Debian/GNU) <umlae...@debian.org> wrote: > On 2016-08-10 11:52, James Cowgill wrote: >>> Actually we should repack ( to get rid of upstream .gitignore file and >>> > use our .gitignore file ) and rename. >> You don't actually need to do that (and arguably you should not repack >> orig tarballs unless you need to). For source format "3.0 (quilt)", >> dpkg-source contains a set of regexes for files which are automatically >> ignored when generating the final source package. .gitignore (and .git/) >> are on the list so any changes you make to upstream's .gitignore are >> completely ignored by dpkg-source. > > i was wanting to ask about best practices regarding .gitignore for some > time. > > when packaging, i have two "problems" with .gitignore > > #1 upstream includes a .gitignore > having an upstream .gitignore field usually just creates trouble as it > (mostly) hides stray artefacts lying around until dpkg-source comes and > complains. i really think that gitignore's main purpose is exactly this > hiding of build artefacts, but it mainly causes trouble when it comes to > Debian's build chain. > with my Debian hat on, i would like to get rid of all upstream > .gitignore files, ideally *automatically* (to catch all those gitignores > in subdirectories...) > with my upstream hat on, i desparately need .gitignore though... I am less annoyed by this because I have set export-dir set in my ~/.gbp.conf. Thus gbp builds never happen in the git tree, and thus never contain the build artifacts. > > a "solution" which i often find applied (by myself, and others like > mira) is to just strip away the .gitignore file, when repacking the > sources (though afaik this is only done when the sources are repackaged > anyhow) > > #2 ignoring Debian toolchain artefacts > most packages use "3.0 quilt", which I (unlike many others) have no > problems with. > unfortunately, using quilt results in a .pc/ directory in the project > root, something that gbp will loudly complain about. > > the most common "solution" is to add .pc/ to .gitignore I have lately been migrating to gbp pq instead of quilt to manage the patches. In addition to allowing easier workflows for eg, rebasing on new upstream versions, this nicely sidesteps the issue of the .pc dir. Paired with the use of export-dir, this results in the .pc dir never existing in my local worktree. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Mayhem bugs
On 8 August 2016 at 15:45, Jaromír Mikeš <mira.mi...@gmail.com> wrote: > > Hi mates, > > I am having Mayhem bugs in couple of packages, but I don't know to > deal with them. > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=brutefir > > Any advice how to fix them, how to reproduce them? > How to confirm they are really fixed? The reports have files that should reproduce the issues. I think it is best to forward these issues upstream. Sometimes the fix to these issues is not trivial. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Help offered with xwax package
Hi Daniel, On 8 August 2016 at 11:47, Daniel James <dan...@64studio.com> wrote: > Hi all, > > I'd like to help update the xwax package in Debian to the latest > upstream 1.6-beta2, which Ubuntu already has. Then I would like to > backport this new version to jessie-backports, as jessie currently has > xwax version 1.5. > > There appears to be a typo in the current patch for Debian > 0001-use_either_ffmpeg_or_avconv.patch as follows: > > which avconf -> which avconv > > I attach an updated copy of the patch. > > I am not a Debian Developer but I have done some packaging work in > collab-maint. If it would be possible to have commit access to > pkg-multimedia/xwax on alioth I would gladly push some other fixes > there, for lintian issues etc. > > My alioth user name is dhj-guest. I've added you to the team in alioth, welcome! Please be sure to read the wiki[1] for some details on how most packages are managed in the team. [1] https://wiki.debian.org/DebianMultimedia/DevelopPackaging -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: concerning llibva backport
On 5 August 2016 at 18:15, James Cowgill <jcowg...@debian.org> wrote: > On 05/08/16 22:47, Felipe Sateler wrote: >> On 5 August 2016 at 17:24, James Cowgill <jcowg...@debian.org> wrote: >>> On 05/08/16 21:03, Nicholas D Steeves wrote: >>>> Hi Sebastian, >>>> >>>> I did a fresh build of libva-1.7.1-1~bpo+1 today, and noticed that it >>>> was building against mesa-10.3.2-1+deb8u1 from Jessie. I've been >>>> testing it on a Jessie+backported mesa-11.1.3-1~bpo8+1, and the >>>> packages I've been testing have also been built against mesa-10.3.x. >>>> Do you think it's ok to build against mesa 10.3.2, or should we bump >>>> the build deps of libva to pull in mesa from jessie-backports. I'm in >>>> favour of bumping the deps asap. Additionally, I think it would also >>>> be wise to bump the intel-vaapi-driver build-depend on libdrm-dev to >>>> prevent it from being built against libdrm-2.4.58-2. >>> >>> Why? You realize that building against a newer version of mesa/libdrm >>> won't affect the dependencies on the final package? >> >> In backports, it does. Dependencies are statisfied from stable if >> possible, thus the build-depends needs to be tightened to force use of >> the backported library. > > What I mean is that build-depending on a more recent package version > doesn't necessarily[1] mean that version will be required at runtime and > reflected in the Depends: lines. For example, mesa doesn't insert any > dependencies into the users of libgl1-mesa-glx, so bumping the > build-dependency will have no affect on the version of the package > actually used at runtime. So if the downstream package doesn't use any > new features in the more recent library, why bump the build-dependency? Ah. I was unaware of that weirdness. Indeed the mesa symbols file set all versions to 0, and does not provide a -dev package mapping. So the dep would be useless. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] rtaudio/master: Add libpulse-dev to deps of -dev package. (Closes: #833271)
On 2 August 2016 at 07:43, <mira-gu...@users.alioth.debian.org> wrote: > The following commit has been merged in the master branch: > commit e34c103bad0f3ab33e7c6dd578cd061d6f4a57b1 > Author: Jaromír Mikeš <mira.mi...@seznam.cz> > Date: Tue Aug 2 13:37:36 2016 +0200 > > Add libpulse-dev to deps of -dev package. (Closes: #833271) Is this the correct fix? AFAICT there is no reason for an rtaudio-using package to require libpulse. The correct fix seems to me to be dropping libpulse-dev (and alsa) from Requires, as rtaudio is supposed to be an abstraction over those libraries, and the dev packages are not required: % grep '#include' RtAudio.h #include #include #include #include #include #include #include #include #include #include -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] csound-manual/master: Switch from CDBS to dh sequencer
On 17 July 2016 at 12:14, Jonas Smedegaard <d...@jones.dk> wrote: > Quoting Felipe Sateler (2016-07-17 17:55:32) >> On 17 July 2016 at 05:42, Jonas Smedegaard <d...@jones.dk> wrote: >> > Quoting Felipe Sateler (2016-07-16 23:54:43) >> >> On 16 July 2016 at 17:52, <fsate...@users.alioth.debian.org> wrote: >> >>> Switch from CDBS to dh sequencer >> >> >> >> Jonas, I think you only work with packages using CDBS. Is this still >> >> the case? If so, would you like me to drop you from Uploaders here? >> > >> > Please drop me as uploader. Not due to change in packaging style (I am >> > - very slowly - moving to short-form dh myself), but because honestly my >> > interest in csound for quite some time is that it exists for use by >> > Sugar - and you are doing a great job at that without my help. >> >> OK, so I will drop you from the main csound package as well. >> >> > >> > Same goes for other packages I am involved with: If others would like to >> > help maintain some but feel too intimidated by CDBS, please nudge me and >> > I will likely - on a case by case basis - either agree to change >> > packaging style or hand it over. >> >> So I take the opportunity to ask here. I was thinking about switching >> over liblo as well. What do you think? > > Please drop me as uploader there too: Same reason as for CSound. OK. Thanks for all the work! -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] csound-manual/master: Switch from CDBS to dh sequencer
On 17 July 2016 at 05:42, Jonas Smedegaard <d...@jones.dk> wrote: > Quoting Felipe Sateler (2016-07-16 23:54:43) >> On 16 July 2016 at 17:52, <fsate...@users.alioth.debian.org> wrote: >>> Switch from CDBS to dh sequencer >> >> Jonas, I think you only work with packages using CDBS. Is this still >> the case? If so, would you like me to drop you from Uploaders here? > > Please drop me as uploader. Not due to change in packaging style (I am > - very slowly - moving to short-form dh myself), but because honestly my > interest in csound for quite some time is that it exists for use by > Sugar - and you are doing a great job at that without my help. OK, so I will drop you from the main csound package as well. > > Same goes for other packages I am involved with: If others would like to > help maintain some but feel too intimidated by CDBS, please nudge me and > I will likely - on a case by case basis - either agree to change > packaging style or hand it over. So I take the opportunity to ask here. I was thinking about switching over liblo as well. What do you think? -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#827929: csound FTBFS on hppa architecture
Control: tags -1 - patch
On 22 June 2016 at 15:58, Helge Deller <del...@gmx.de> wrote:
> Package: csound
> Version: 1:6.05~dfsg1-7
> Tags: patch
>
> csound fails to build on hppa, because hppa uses gcj as java compiler, and
> in interfaces/CMakeLists.txt it's hardcoded:
> COMMAND ${JAVA_COMPILE} *.java -source 1.6 -target 1.6 -d .
>
> gcj does not accept the -source and -target options.
> Removing those fixes build on hppa.
>
> Failing log is here:
> https://buildd.debian.org/status/fetch.php?pkg=csound=hppa=1%3A6.05%7Edfsg1-7=1463527847
>
> Attached patch fixes it for hppa, but is probably not useable for other
> architectures.
Right, we can't do this on other archs, we just depend on the default java.
> Is there any other possible work around for this problem ?
Maybe the java interface can be disabled on hppa? There are no reverse
dependencies on debian.
--
Saludos,
Felipe Sateler
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: rtaudio package
On 21 June 2016 at 10:00, Jaromír Mikeš <mira.mi...@gmail.com> wrote: > 2016-06-20 18:02 GMT+02:00 James Cowgill <jcowg...@debian.org>: >> On Mon, 2016-06-20 at 17:00 +0200, Jaromír Mikeš wrote: >>> 2016-06-18 12:23 GMT+02:00 James Cowgill <jcowg...@debian.org>: >>> > Hi, >>> > >>> > On Fri, 2016-06-17 at 22:25 +0200, Jaromír Mikeš wrote: >>> > > can safely upload package now? Soname was bumped. >>> > >>> > I can upload this for you if you want, though there are some >>> > issues. >>> > >>> > librtaudio5 is already taken and in use in jessie. To reuse this >>> > number, the ABI must be identical (which I have not checked). I'm >>> > still not sure I can believe what I'm reading here: >>> > >>> > librtaudio4| 4.0.10~ds0-2 | wheezy | amd64 >>> > librtaudio4v5 | 4.1.1~ds0-4 | stretch | amd64 >>> > librtaudio4v5 | 4.1.1~ds0-4 | sid | amd64 >>> > librtaudio5| 4.1.1~ds0-2 | jessie | amd64 >> >> I still don't like this. Although it probably won't effect most people, >> it will break reverse dependencies if you try to do a partial upgrade >> from jessie to stretch. >> >> I think you either need to do a local soname change (not 6!), or rename >> the package to something like librtaudio5a and have it Conflicts the >> old package name. >> >> That corresponds to the second renaming case on this page (there is no >> SONAME change when compared to jessie): >> https://wiki.debian.org/TransitionBestPractices > > Ok I renamed package to librtaudio5a and add Conflicts for librtaudio5. > Now get package-name-doesnt-match-sonames librtaudio5 ... lintian error. > > renaming librtaudio.so.5.0.0 to librtaudio.so.5a.0.0 should be enough? I suggest overriding this error. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: rtaudio package
On 19 June 2016 at 12:57, Jaromír Mikeš <mira.mi...@gmail.com> wrote: > 2016-06-18 15:38 GMT+02:00 Felipe Sateler <fsate...@debian.org>: >> On 18 June 2016 at 06:38, James Cowgill <jcowg...@debian.org> wrote: >>> On Sat, 2016-06-18 at 11:23 +0100, James Cowgill wrote: >>>> On Fri, 2016-06-17 at 22:25 +0200, Jaromír Mikeš wrote: >>>> > Hi, >>>> > >>>> > can safely upload package now? Soname was bumped. >>> [...] >>>> librtaudio-dev cannot be Multi-Arch: same because it provides a >>>> binary in /usr/bin (looks like this bug is already present in >>>> unstable already). >>> >>> On closer inspection rtaudio-config is probably OK because it doesn't >>> contain the libs path like most config scripts do. >>> >>> Please ship the pkg-config file! >> >> Yes, the only user of rtaudio-config in the archive tries the >> pkg-config file first >> >> https://codesearch.debian.net/perpackage-results/rtaudio-config/2/page_0 >> >> Maybe rtaudio-config can even be dropped. > > Felipe, > > I noticed you have filled bug against rtaudio ... to be build with cmake. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824114 > > can you help me with this? I took a look at this, but it appears the cmake build is not yet up to par with the autotools build: 1. It lacks SO versioning 2. It does not build documentation So I guess we can continue with the autotools for the time being. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: zynaddsubfx FTBFS on some archs
On 15 June 2016 at 09:29, Jaromír Mikeš <mira.mi...@gmail.com> wrote: > Hi, > > while updating zynaddsubfx package FTBFS on some archs :( > https://buildd.debian.org/status/package.php?p=zynaddsubfx=unstable > > Does somebody have any idea how to fix it? Looks like a faulty libc header to me: In file included from /usr/include/features.h:385:0, from /usr/include/stdio.h:27, from /usr/include/FL/fl_utf8.h:33, from /usr/include/FL/Fl.H:30, from /«PKGBUILDDIR»/obj-arm-linux-gnueabi/src/UI/ADnoteUI.h:5, from /«PKGBUILDDIR»/obj-arm-linux-gnueabi/src/UI/ADnoteUI.cxx:3: /usr/include/arm-linux-gnueabi/gnu/stubs.h:10:29: fatal error: gnu/stubs-hard.h: No such file or directory You could try asking the libc maintainers or the porters for any of those archs. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#824581: supercollider: FTBFS on various arches: errors in oscpack_build.cpp
On 21 May 2016 at 09:09, James Cowgill <james...@cowgill.org.uk> wrote: > > Control: tags -1 patch > > Hi, > > This patch seems to fix the FTBFS. I've tested it on amd64, i386, > arm64, powerpc and ppc64el. > > Since it builds on ppc64el, I'm guessing that #766630 is also fixed? > > I also tested it with supernova enabled and it works everywhere so you > can probably just remove the code to disable supernova. > > If you want I can commit / upload this. Yes please. We can always refine the patch later if upstream does not find it acceptable. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] supercollider/master: Restrict (optional) supernova to its target archs
On 18 May 2016 at 03:46, Dan S <danstowell+de...@gmail.com> wrote:
> 2016-05-18 0:24 GMT+01:00 Felipe Sateler <fsate...@debian.org>:
>> On 17 May 2016 at 18:34, <danstowell-gu...@users.alioth.debian.org> wrote:
>>> The following commit has been merged in the master branch:
>>> commit 837440f53425195c71a63651856e1717678bd4b5
>>> Author: Dan Stowell <danstow...@users.sourceforge.net>
>>> Date: Tue May 17 23:05:00 2016 +0100
>>>
>>> Restrict (optional) supernova to its target archs
>>>
>>> i386, ia64, amd64
>>>
>>> diff --git a/debian/control b/debian/control
>>> index f5ae176..ed8035e 100644
>>> --- a/debian/control
>>> +++ b/debian/control
>>> @@ -117,7 +117,7 @@ Description: integrated development environment for
>>> supercollider audio system
>>> working with SuperCollider code.
>>>
>>> Package: supercollider-supernova
>>> -Architecture: any-i386 any-amd64 armel armhf ia64 mips mipsel s390 s390x
>>> +Architecture: any-i386 any-amd64 ia64
>>> Depends: ${shlibs:Depends}, ${misc:Depends}, jackd
>>> Description: real time audio synthesis server (multiprocessor version)
>>> SuperCollider is an environment and programming language for real time
>>> diff --git a/debian/rules b/debian/rules
>>> index 3d36e0a..e15375a 100755
>>> --- a/debian/rules
>>> +++ b/debian/rules
>>> @@ -21,15 +21,11 @@ DEB_INSTALL_MANPAGES_supercollider-language =
>>> debian/sclang.1
>>> DEB_INSTALL_MANPAGES_supercollider-vim = debian/scvim.1
>>> debian/sclangpipe_app.1
>>> DEB_INSTALL_MANPAGES_supercollider-ide = debian/scide.1
>>>
>>> -# supernova (alternative to scsynth) uses fancy simd things which fail to
>>> build on sparc/powerpc
>>> -ifeq ("$(DEB_HOST_ARCH_CPU)","sparc")
>>> +# supernova (optional alternative to scsynth) uses fancy simd things which
>>> fail to build on non-target architectures
>>> +ifeq (,$(findstring $(DEB_HOST_ARCH_CPU),"i386" "amd64" "ia64"))
>>
>> Maybe this could be replaced with:
>>
>> ifeq (,$(findstring supercollider-supernova,$(DEB_ARCH_PACKAGES)))
>>
>> This would avoid having to encode the list in more than one place.
>
> This fails when I try it.
This is an inverted match:
ifeq (,$(findstring supercollider-supernova,$(DEB_ARCH_PACKAGES)))
DEB_BUILD_SUPERNOVA=off
else
DEB_BUILD_SUPERNOVA=on
endif
> Also, at build time, the machine is building
> all the packages, not just supernova, so I don't think that variable
> could possibly hold the supernova-specific list could it?
Yes, because cdbs puts in that variable only the packages that will
actually be built: it skips architecture-specific packages that are
not a match for the current DEB_HOST_ARCHITECTURE. This is done
through the debhelper command dh_listpackages[1].
You can test this by removing any-amd64 from the sc-supernova list.
[1] http://sources.debian.net/src/cdbs/0.4.135/1/rules/buildvars.mk.in/#L44
--
Saludos,
Felipe Sateler
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] supercollider/master: debian/rules: disabled altivec/vsx for ppc64el
On 17 May 2016 at 18:34, <danstowell-gu...@users.alioth.debian.org> wrote:
> The following commit has been merged in the master branch:
> commit 34e9e171f850b4e589e908752175de90551983dc
> Author: Dan Stowell <danstow...@users.sourceforge.net>
> Date: Tue May 17 23:11:19 2016 +0100
>
> debian/rules: disabled altivec/vsx for ppc64el
>
> since the package does not support the usage for now
>
> patch by Fernando Seiti Furusato,
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766630
>
> diff --git a/debian/changelog b/debian/changelog
> index 611e5d3..a731d0f 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,11 @@
> +supercollider (1:3.7.0~repack-2) UNRELEASED; urgency=medium
> +
> + [ Fernando Seiti Furusato ]
> + * debian/rules: disabled altivec/vsx for ppc64el since the package does not
> +support the usage for now
> +
> + -- Dan Stowell <danstow...@users.sourceforge.net> Tue, 17 May 2016
> 23:09:57 +0100
> +
> supercollider (1:3.7.0~repack-1) unstable; urgency=medium
>
>[ Dan Stowell ]
> diff --git a/debian/rules b/debian/rules
> index e15375a..a072df3 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -28,6 +28,11 @@ else
> DEB_BUILD_SUPERNOVA=on
> endif
>
> +ifeq ("$(DEB_HOST_ARCH_CPU)","ppc64el")
> + CFLAGS=-mno-altivec -mno-vsx
> + CXXFLAGS=-mno-altivec -mno-vsx
> +endif
> +
I'm pretty sure this is wrong, as this will override any other
setting. the flag needs to be appended.
--
Saludos,
Felipe Sateler
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] supercollider/master: Restrict (optional) supernova to its target archs
On 17 May 2016 at 18:34, <danstowell-gu...@users.alioth.debian.org> wrote:
> The following commit has been merged in the master branch:
> commit 837440f53425195c71a63651856e1717678bd4b5
> Author: Dan Stowell <danstow...@users.sourceforge.net>
> Date: Tue May 17 23:05:00 2016 +0100
>
> Restrict (optional) supernova to its target archs
>
> i386, ia64, amd64
>
> diff --git a/debian/control b/debian/control
> index f5ae176..ed8035e 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -117,7 +117,7 @@ Description: integrated development environment for
> supercollider audio system
> working with SuperCollider code.
>
> Package: supercollider-supernova
> -Architecture: any-i386 any-amd64 armel armhf ia64 mips mipsel s390 s390x
> +Architecture: any-i386 any-amd64 ia64
> Depends: ${shlibs:Depends}, ${misc:Depends}, jackd
> Description: real time audio synthesis server (multiprocessor version)
> SuperCollider is an environment and programming language for real time
> diff --git a/debian/rules b/debian/rules
> index 3d36e0a..e15375a 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -21,15 +21,11 @@ DEB_INSTALL_MANPAGES_supercollider-language =
> debian/sclang.1
> DEB_INSTALL_MANPAGES_supercollider-vim = debian/scvim.1
> debian/sclangpipe_app.1
> DEB_INSTALL_MANPAGES_supercollider-ide = debian/scide.1
>
> -# supernova (alternative to scsynth) uses fancy simd things which fail to
> build on sparc/powerpc
> -ifeq ("$(DEB_HOST_ARCH_CPU)","sparc")
> +# supernova (optional alternative to scsynth) uses fancy simd things which
> fail to build on non-target architectures
> +ifeq (,$(findstring $(DEB_HOST_ARCH_CPU),"i386" "amd64" "ia64"))
Maybe this could be replaced with:
ifeq (,$(findstring supercollider-supernova,$(DEB_ARCH_PACKAGES)))
This would avoid having to encode the list in more than one place.
--
Saludos,
Felipe Sateler
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#824114: rtaudio: use cmake build to allow building in non-linux-archs
Source: rtaudio Version: 4.1.1~ds0-4 Severity: normal The cmake build should allow building in non-linux archs, which should allow removal of special casing for reverse build-depends. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: supercollider 3.7.0 in alioth to try
On 10 May 2016 at 17:43, Dan S <danstowell+de...@gmail.com> wrote: > 2016-05-10 21:33 GMT+01:00 Felipe Sateler <fsate...@debian.org>: >> On 10 May 2016 at 17:05, Dan S <danstowell+de...@gmail.com> wrote: >>> 2016-05-10 18:23 GMT+01:00 Felipe Sateler <fsate...@debian.org>: >>>> On 6 May 2016 at 13:32, Dan S <danstowell+de...@gmail.com> wrote: >>>>> 2016-05-04 16:09 GMT+01:00 Felipe Sateler <fsate...@debian.org>: >>>>>> On 4 May 2016 at 11:57, Dan S <danstowell+de...@gmail.com> wrote: >>>>>>> 2016-04-26 19:23 GMT+01:00 Felipe Sateler <fsate...@debian.org>: >>>>>>>> On 25 April 2016 at 18:12, Felipe Sateler <fsate...@debian.org> wrote: >>>>>>>>> On 20 March 2016 at 12:52, Dan S <danstowell+de...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> There's a new release of SuperCollider out (3.7) and I've imported >>>>>>>>>> and >>>>>>>>>> updated the packaging at pkg-multimedia/supercollider.git . It builds >>>>>>>>>> and works for me (on x64), and I'd like to ask others to have a look >>>>>>>>>> at it and consider testing/uploading it. >>>>>>>>> >>>>>>>>> I reproduce the same failure as Hanno, also on x64: >>>>>>>>> >>>>>>>>> /usr/bin/ld: ../../external_libraries/libtlsf.a(tlsf.c.o): relocation >>>>>>>>> R_X86_64_32S against `.rodata' can not be used when making a shared >>>>>>>>> object; recompile with -fPIC >>>>>>>>> ../../external_libraries/libtlsf.a: error adding symbols: Bad value >>>>>>>>> >>>>>>>>> adding said -fPIC flag to tlsf target continues until: >>>>>>>> >>>>>>>>> /usr/bin/ld: cannot find -lQt5::OpenGL >>>>>>>>> >>>>>>>>> >>>>>>>>> Could you have a look? >>>>>>>> >>>>>>>> This seems to be a missing build-dep on libqt5opengl5-dev. It builds >>>>>>>> fine after that. >>>>>>>> >>>>>>>> BTW, why do we disable the testsuite? >>>>>>> >>>>>>> (Sorry for the delay - didn't spot your second message) >>>>>>> >>>>>>> Regarding the testsuite: IIRC it doesn't succeed on all archs, and >>>>>>> that's beyond our control. In 2013 you asked the same question, you >>>>>>> asked "Why disable the testsuite? After all, if it is failing, its for >>>>>>> a reason" and my answer was the following: >>>>>>> >>>>>>>> That's what I thought too at first. However it's not intended to be >>>>>>>> packaged (it doesn't build anything), and after discussion with the >>>>>>>> developer who actually made and maintains that testsuite, he wanted it >>>>>>>> that way... (It's not really a testsuite of supercollider, btw, I >>>>>>>> think covers the 'supernova' component.) >>>>>> >>>>>> Heh, sorry for forgetting about that. I added a comment to that effect >>>>>> to debian/rules. >>>>> >>>>> Thanks. Also thanks for the suggested build fixes. Now I've upgraded >>>>> my OS I can finally confirm them, so I've pushed them (and proposed >>>>> them upstream too). >>>> >>>> So now we have several build failures: >>>> >>>> https://buildd.debian.org/status/package.php?p=supercollider >>>> >>>> All of them in the embedded oscpack, but not all of them the same. I >>>> was going to suggest using the available library, but it is orphaned. >>>> Anyone up to take the maintainance of oscpack? >>> >>> One thing to note: it's only "supernova" that makes use of oscpack, >>> and supernova is optional since it's a drop-in replacement for >>> "scsynth". >>> So, one cop-out alternative available to us (if oscpack isn't getting >>> fixed) is that on some platforms we could disable building it >>> (-DSUPERNOVA=0) and disable packaging it. >> >> We are already doing that[1], so that is a possible course of action. >> >> BTW, is it possible to use a system oscpack? It looks like the library >> is barely ever updated, so maybe I could just bite the bullet and >> upload it. > > Possible, yes, should be. However note that the pack did get a minor > tweak in the supercollider local copy, see first commit here: > https://github.com/supercollider/supercollider/commits/master/external_libraries/oscpack_1_1_0 Hmm. Should be possible to include in the debian version of oscpack. I'm not sure if that breaks abi, though. Would the inlined method still show up in the shared library? > I guess by "upload" you mean upload the latest (1.1.0) oscpack to unstable? > https://packages.debian.org/source/sid/oscpack > I don't see much harm in uploading, though I've no idea of the > present/future state of the lib - seems to be a little stale at > present. As long as there are users... Right now sc would be the only one. But if the lib is dead, then probably sc (upstream) should not rely on it. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: supercollider 3.7.0 in alioth to try
On 10 May 2016 at 17:05, Dan S <danstowell+de...@gmail.com> wrote: > 2016-05-10 18:23 GMT+01:00 Felipe Sateler <fsate...@debian.org>: >> On 6 May 2016 at 13:32, Dan S <danstowell+de...@gmail.com> wrote: >>> 2016-05-04 16:09 GMT+01:00 Felipe Sateler <fsate...@debian.org>: >>>> On 4 May 2016 at 11:57, Dan S <danstowell+de...@gmail.com> wrote: >>>>> 2016-04-26 19:23 GMT+01:00 Felipe Sateler <fsate...@debian.org>: >>>>>> On 25 April 2016 at 18:12, Felipe Sateler <fsate...@debian.org> wrote: >>>>>>> On 20 March 2016 at 12:52, Dan S <danstowell+de...@gmail.com> wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> There's a new release of SuperCollider out (3.7) and I've imported and >>>>>>>> updated the packaging at pkg-multimedia/supercollider.git . It builds >>>>>>>> and works for me (on x64), and I'd like to ask others to have a look >>>>>>>> at it and consider testing/uploading it. >>>>>>> >>>>>>> I reproduce the same failure as Hanno, also on x64: >>>>>>> >>>>>>> /usr/bin/ld: ../../external_libraries/libtlsf.a(tlsf.c.o): relocation >>>>>>> R_X86_64_32S against `.rodata' can not be used when making a shared >>>>>>> object; recompile with -fPIC >>>>>>> ../../external_libraries/libtlsf.a: error adding symbols: Bad value >>>>>>> >>>>>>> adding said -fPIC flag to tlsf target continues until: >>>>>> >>>>>>> /usr/bin/ld: cannot find -lQt5::OpenGL >>>>>>> >>>>>>> >>>>>>> Could you have a look? >>>>>> >>>>>> This seems to be a missing build-dep on libqt5opengl5-dev. It builds >>>>>> fine after that. >>>>>> >>>>>> BTW, why do we disable the testsuite? >>>>> >>>>> (Sorry for the delay - didn't spot your second message) >>>>> >>>>> Regarding the testsuite: IIRC it doesn't succeed on all archs, and >>>>> that's beyond our control. In 2013 you asked the same question, you >>>>> asked "Why disable the testsuite? After all, if it is failing, its for >>>>> a reason" and my answer was the following: >>>>> >>>>>> That's what I thought too at first. However it's not intended to be >>>>>> packaged (it doesn't build anything), and after discussion with the >>>>>> developer who actually made and maintains that testsuite, he wanted it >>>>>> that way... (It's not really a testsuite of supercollider, btw, I >>>>>> think covers the 'supernova' component.) >>>> >>>> Heh, sorry for forgetting about that. I added a comment to that effect >>>> to debian/rules. >>> >>> Thanks. Also thanks for the suggested build fixes. Now I've upgraded >>> my OS I can finally confirm them, so I've pushed them (and proposed >>> them upstream too). >> >> So now we have several build failures: >> >> https://buildd.debian.org/status/package.php?p=supercollider >> >> All of them in the embedded oscpack, but not all of them the same. I >> was going to suggest using the available library, but it is orphaned. >> Anyone up to take the maintainance of oscpack? > > One thing to note: it's only "supernova" that makes use of oscpack, > and supernova is optional since it's a drop-in replacement for > "scsynth". > So, one cop-out alternative available to us (if oscpack isn't getting > fixed) is that on some platforms we could disable building it > (-DSUPERNOVA=0) and disable packaging it. We are already doing that[1], so that is a possible course of action. BTW, is it possible to use a system oscpack? It looks like the library is barely ever updated, so maybe I could just bite the bullet and upload it. [1] https://anonscm.debian.org/cgit/pkg-multimedia/supercollider.git/tree/debian/rules#n25 -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: supercollider 3.7.0 in alioth to try
On 6 May 2016 at 13:32, Dan S <danstowell+de...@gmail.com> wrote: > 2016-05-04 16:09 GMT+01:00 Felipe Sateler <fsate...@debian.org>: >> On 4 May 2016 at 11:57, Dan S <danstowell+de...@gmail.com> wrote: >>> 2016-04-26 19:23 GMT+01:00 Felipe Sateler <fsate...@debian.org>: >>>> On 25 April 2016 at 18:12, Felipe Sateler <fsate...@debian.org> wrote: >>>>> On 20 March 2016 at 12:52, Dan S <danstowell+de...@gmail.com> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> There's a new release of SuperCollider out (3.7) and I've imported and >>>>>> updated the packaging at pkg-multimedia/supercollider.git . It builds >>>>>> and works for me (on x64), and I'd like to ask others to have a look >>>>>> at it and consider testing/uploading it. >>>>> >>>>> I reproduce the same failure as Hanno, also on x64: >>>>> >>>>> /usr/bin/ld: ../../external_libraries/libtlsf.a(tlsf.c.o): relocation >>>>> R_X86_64_32S against `.rodata' can not be used when making a shared >>>>> object; recompile with -fPIC >>>>> ../../external_libraries/libtlsf.a: error adding symbols: Bad value >>>>> >>>>> adding said -fPIC flag to tlsf target continues until: >>>> >>>>> /usr/bin/ld: cannot find -lQt5::OpenGL >>>>> >>>>> >>>>> Could you have a look? >>>> >>>> This seems to be a missing build-dep on libqt5opengl5-dev. It builds >>>> fine after that. >>>> >>>> BTW, why do we disable the testsuite? >>> >>> (Sorry for the delay - didn't spot your second message) >>> >>> Regarding the testsuite: IIRC it doesn't succeed on all archs, and >>> that's beyond our control. In 2013 you asked the same question, you >>> asked "Why disable the testsuite? After all, if it is failing, its for >>> a reason" and my answer was the following: >>> >>>> That's what I thought too at first. However it's not intended to be >>>> packaged (it doesn't build anything), and after discussion with the >>>> developer who actually made and maintains that testsuite, he wanted it >>>> that way... (It's not really a testsuite of supercollider, btw, I >>>> think covers the 'supernova' component.) >> >> Heh, sorry for forgetting about that. I added a comment to that effect >> to debian/rules. > > Thanks. Also thanks for the suggested build fixes. Now I've upgraded > my OS I can finally confirm them, so I've pushed them (and proposed > them upstream too). So now we have several build failures: https://buildd.debian.org/status/package.php?p=supercollider All of them in the embedded oscpack, but not all of them the same. I was going to suggest using the available library, but it is orphaned. Anyone up to take the maintainance of oscpack? -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: supercollider is marked for autoremoval from testing
On 9 May 2016 at 11:20, Hanno Zulla <a...@hanno.de> wrote: > Hi, > >> Felipe is correct - 3.7.0 is on track, and looking good IMHO. Looks good, except that for some reason, the ide icon does not display correctly on my kde system. It displays as a small point in the upper left corner. Can anyone else see this? https://people.debian.org/~fsateler/supercollider.png If I change the desktop file to use supercollider.png, then the problem goes away. Maybe the svg file has something funky? I'd say this is relatively minor, so I'm uploading anyway. Also, if someone with more dep5 skills can take a look at the following lintian warnings it would be great (AFAICT, the file is ok by content, only the format may be a bit wrong). W: supercollider source: dep5-copyright-license-name-not-unique (paragraph at line 271) W: supercollider source: dep5-copyright-license-name-not-unique (paragraph at line 296) W: supercollider source: missing-license-paragraph-in-dep5-copyright lgpl-2.1+ (paragraph at line 212) W: supercollider source: missing-license-paragraph-in-dep5-copyright bsl-1.0 (paragraph at line 166) > That's great. > > We probably should keep in mind that after the release of supercollider > 3.7.0, the supercollider-sc3-plugins source package needs a minor > version bump too, to get its binaries compiled against the new > supercollider-dev package. Why does it need a minor version bump? As IOhannes says, the libraries should have SONAME bumped if they broke compat. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: supercollider is marked for autoremoval from testing
On 9 May 2016 at 06:11, Hanno Zulla <a...@hanno.de> wrote: > Hi, > > Am 02.05.2016 um 06:39 schrieb Debian testing autoremoval watch: >> supercollider 1:3.6.6~repack-2-2 is marked for autoremoval from testing on >> 2016-06-07 >> >> It is affected by these RC bugs: >> 822467: supercollider: FTBFS: error: 'random_device' is not a member of 'std' > > As Sonic Pi depends on SuperCollider (thanks, great piece of software!), > I wanted to ask if assistance with fixing this is needed. > > Is the packaging of supercollider 3.7.0 on track or should 3.6.6 be > fixed, first? I think[1] that 3.7.0 is on track, all that is left is some local testing and then an actual upload. Please test the current version in git and report success/failure, I will upload soonish (but haven't found time yet). [1] Dan, please speak up if not the case -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: supercollider 3.7.0 in alioth to try
On 4 May 2016 at 11:57, Dan S <danstowell+de...@gmail.com> wrote: > 2016-04-26 19:23 GMT+01:00 Felipe Sateler <fsate...@debian.org>: >> On 25 April 2016 at 18:12, Felipe Sateler <fsate...@debian.org> wrote: >>> On 20 March 2016 at 12:52, Dan S <danstowell+de...@gmail.com> wrote: >>>> >>>> Hi all, >>>> >>>> There's a new release of SuperCollider out (3.7) and I've imported and >>>> updated the packaging at pkg-multimedia/supercollider.git . It builds >>>> and works for me (on x64), and I'd like to ask others to have a look >>>> at it and consider testing/uploading it. >>> >>> I reproduce the same failure as Hanno, also on x64: >>> >>> /usr/bin/ld: ../../external_libraries/libtlsf.a(tlsf.c.o): relocation >>> R_X86_64_32S against `.rodata' can not be used when making a shared >>> object; recompile with -fPIC >>> ../../external_libraries/libtlsf.a: error adding symbols: Bad value >>> >>> adding said -fPIC flag to tlsf target continues until: >> >>> /usr/bin/ld: cannot find -lQt5::OpenGL >>> >>> >>> Could you have a look? >> >> This seems to be a missing build-dep on libqt5opengl5-dev. It builds >> fine after that. >> >> BTW, why do we disable the testsuite? > > (Sorry for the delay - didn't spot your second message) > > Regarding the testsuite: IIRC it doesn't succeed on all archs, and > that's beyond our control. In 2013 you asked the same question, you > asked "Why disable the testsuite? After all, if it is failing, its for > a reason" and my answer was the following: > >> That's what I thought too at first. However it's not intended to be >> packaged (it doesn't build anything), and after discussion with the >> developer who actually made and maintains that testsuite, he wanted it >> that way... (It's not really a testsuite of supercollider, btw, I >> think covers the 'supernova' component.) Heh, sorry for forgetting about that. I added a comment to that effect to debian/rules. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#823316: stk: contains non-free Steinberg ASIO library
Control: found -1 4.5.0-1 On 3 May 2016 at 09:58, James Cowgill <jcowg...@debian.org> wrote: > On Tue, 2016-05-03 at 09:54 -0300, Felipe Sateler wrote: >> Control: fixed -1 4.5.0-1 >> >> On 3 May 2016 at 08:27, James Cowgill <jcowg...@debian.org> wrote: >> > >> > Source: stk >> > Version: 4.4.3-2 >> > Severity: serious >> > >> > Hi, >> > >> > stk contains a bundled copy of the Steinberg ASIO library headers >> > in >> > src/include. These files are under very strict licensing terms >> Indeed. Fortunately, the latest release has already fixed this issue. > > Err, no it hasn't: > https://sources.debian.net/src/stk/4.5.0-3/src/include/asio.h/ Meh, I only looked at ./include, not ./src/include. Sorry about that. Patches still welcome though ;) -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#823316: stk: contains non-free Steinberg ASIO library
Control: fixed -1 4.5.0-1 On 3 May 2016 at 08:27, James Cowgill <jcowg...@debian.org> wrote: > Source: stk > Version: 4.4.3-2 > Severity: serious > > Hi, > > stk contains a bundled copy of the Steinberg ASIO library headers in > src/include. These files are under very strict licensing terms Indeed. Fortunately, the latest release has already fixed this issue. I suppose all we need is to repack source to remove the file for stable. We are not using the ASIO driver anyway. Patches (and uploads) welcome. Otherwise it'll take me a few days to do this. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: QasTools 0.21.0 package ready. Please test/upload.
On 28 April 2016 at 12:46, James Cowgill <jcowg...@debian.org> wrote: > Hi, > > On Thu, 2016-04-28 at 00:13 +0200, Sebastian Holtermann wrote: >> Hi all, >> the new package for QasTools 0.21.0 is ready. >> It builds on Qt5 now. >> >> Git: >> https://anonscm.debian.org/git/pkg-multimedia/qastools.git >> Browser: >> https://anonscm.debian.org/gitweb/?p=pkg-multimedia/qastools.git >> >> Please review/upload. > > Just a few minor points: > > Can you enable parallel building for this package (dh --parallel)? > Standards is now 3.9.8. > debian/docs is empty (and is therefore useless). > > The Vcs-Browser field should now be: > https://anonscm.debian.org/cgit/pkg-multimedia/qastools.git > (and yes it's a PITA that these URLs keep changing) The command cme can do this and more automatic fixes: $ cme fix dpkg -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: supercollider 3.7.0 in alioth to try
On 25 April 2016 at 18:12, Felipe Sateler <fsate...@debian.org> wrote: > On 20 March 2016 at 12:52, Dan S <danstowell+de...@gmail.com> wrote: >> >> Hi all, >> >> There's a new release of SuperCollider out (3.7) and I've imported and >> updated the packaging at pkg-multimedia/supercollider.git . It builds >> and works for me (on x64), and I'd like to ask others to have a look >> at it and consider testing/uploading it. > > I reproduce the same failure as Hanno, also on x64: > > /usr/bin/ld: ../../external_libraries/libtlsf.a(tlsf.c.o): relocation > R_X86_64_32S against `.rodata' can not be used when making a shared > object; recompile with -fPIC > ../../external_libraries/libtlsf.a: error adding symbols: Bad value > > adding said -fPIC flag to tlsf target continues until: > /usr/bin/ld: cannot find -lQt5::OpenGL > > > Could you have a look? This seems to be a missing build-dep on libqt5opengl5-dev. It builds fine after that. BTW, why do we disable the testsuite? -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: supercollider 3.7.0 in alioth to try
On 20 March 2016 at 12:52, Dan S <danstowell+de...@gmail.com> wrote: > > Hi all, > > There's a new release of SuperCollider out (3.7) and I've imported and > updated the packaging at pkg-multimedia/supercollider.git . It builds > and works for me (on x64), and I'd like to ask others to have a look > at it and consider testing/uploading it. I reproduce the same failure as Hanno, also on x64: /usr/bin/ld: ../../external_libraries/libtlsf.a(tlsf.c.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC ../../external_libraries/libtlsf.a: error adding symbols: Bad value adding said -fPIC flag to tlsf target continues until: [ 70%] Linking CXX executable sclang cd "/tmp/build-area/supercollider-3.7.0~repack/obj-x86_64-linux-gnu/lang" && /usr/bin/cmake -E cmake_link_script CMakeFiles/sclang.dir/link.txt --verbose=1 /usr/bin/g++ -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -msse -msse -mfpmath=sse -msse2 -std=c++11 -O2 -g -DNDEBUG -std=c++11 -Wl,-z,relro CMakeFiles/sclang.d ir/LangSource/cmdLineFuncs.cpp.o -o sclang -rdynamic libsclang.a -lpthread /usr/lib/x86_64-linux-gnu/libQt5WebKitWidgets.so.5.5.1 /usr/lib/x86_64-linux-gnu/libQt5WebKit.so.5.5.1 /usr/lib/x86_64-linux-gnu/libQt5PrintSupport .so.5.5.1 /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.5.1 -lQt5::OpenGL /usr/lib/x86_64-linux-gnu/libQt5Sensors.so.5.5.1 /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5.5.1 /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.5.1 /usr/lib/ x86_64-linux-gnu/libQt5Qml.so.5.5.1 /usr/lib/x86_64-linux-gnu/libQt5Network.so.5.5.1 /usr/lib/x86_64-linux-gnu/libQt5Sql.so.5.5.1 /usr/lib/x86_64-linux-gnu/libQt5Positioning.so.5.5.1 /usr/lib/x86_64-linux-gnu/libQt5Core.so. 5.5.1 -lm -lX11 ../external_libraries/hidapi/linux/libhidapi.a -ludev ../external_libraries/hidapi/hidapi_parser/libhidapi_parser.a -lboost_regex -lboost_filesystem ../server/scsynth/libscsynth.so.1.0.0 ../external_librarie s/libtlsf.a -ldl -lavahi-common -lavahi-client -ljack -lboost_thread -lboost_system -lfftw3f -lreadline -lasound -lsndfile -lrt ../external_libraries/libyaml.a /usr/bin/ld: cannot find -lQt5::OpenGL Could you have a look? -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#822566: stk: please make the build reproducible (fileordering)
Hi, On 25 April 2016 at 10:11, Alexis Bienvenüe <p...@passoire.fr> wrote: > Source: stk > Version: 4.5.0-3 > Severity: wishlist > Tags: patch upstream > User: reproducible-bui...@lists.alioth.debian.org > Usertags: fileordering > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > While working on the “reproducible builds” effort [1], we have noticed > that 'stk' could not be built reproducibly. > > The attached patch fixes the order in which *.o files are merged. Once > applied, stk can be built reproducibly in our current experimental > framework. Thanks, but couldn't this be simpler by using the already-defined variable $(OBJECTS)? Does using that fix the problem? -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#821825: csoundqt: please split out examples
On 19 April 2016 at 12:49, Aaron M. Ucko <a...@alum.mit.edu> wrote: > Package: csoundqt > Version: 0.9.2.1-1 > Severity: normal > > Hi, Felipe. I see that the csoundqt binary package has gained just > over 70 MB of examples, which I presume are architecture-independent > and not necessary to run the application. Please split these out into > a dedicated Architecture: all binary package, which the main csoundqt > package can list in either Recommends or Suggests (your call). Yes, I've been meaning to do this. But I also want to talk to upstream about the possibility of having the examples on a separate repository entirely, as they appear to have separate release schedules. I intend to fix this soon, one way or the other. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#817879: csound: FTBFS: libmvec_nonshared.a(svml_finite_alias.oS): relocation R_X86_64_PC32 against undefined symbol `_ZGVbN2v_log@@GLIBC_2.22' can not be used when making a shared object; recompil
Control: tags -1 help On 11 March 2016 at 05:51, Chris Lamb <la...@debian.org> wrote: > > Source: csound > Version: 1:6.05~dfsg1-7 > Severity: serious > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > csound fails to build from source in unstable/amd64: > > [..] > > CMakeFiles/csound64.dir/InOut/libmpadec/mp3dec.c.o > CMakeFiles/csound64.dir/csound_orclex.c.o > CMakeFiles/csound64.dir/csound_orcparse.c.o > CMakeFiles/csound64.dir/csound_prelex.c.o > CMakeFiles/csound64.dir/Engine/csound_orc_semantics.c.o > CMakeFiles/csound64.dir/Engine/csound_orc_expressions.c.o > CMakeFiles/csound64.dir/Engine/csound_orc_optimize.c.o > CMakeFiles/csound64.dir/Engine/csound_orc_compile.c.o > CMakeFiles/csound64.dir/Engine/new_orc_parser.c.o > CMakeFiles/csound64.dir/Engine/symbtab.c.o > CMakeFiles/csound64.dir/Engine/cs_new_dispatch.c.o > CMakeFiles/csound64.dir/Engine/cs_par_base.c.o > CMakeFiles/csound64.dir/Engine/cs_par_orc_semantic_analysis.c.o > CMakeFiles/csound64.dir/Engine/cs_par_dispatch.c.o -lsndfile -lpthread -lm > -ldl > /usr/bin/ld: > /usr/lib/x86_64-linux-gnu/libmvec_nonshared.a(svml_finite_alias.oS): > relocation R_X86_64_PC32 against undefined symbol `_ZGVbN2v_log@@GLIBC_2.22' > can not be used when making a shared object; recompile with -fPIC My first guess this is a bug in libc. The linker script in libm.so instructs the inclusion of libmvec_nonshared, so one would expect to libmvec_nonshared to be something that can be linked into a shared object. Dear libc maintainers, is the above assessment correct, or is csound doing something unexpected? Some data points: 1. The failure is at linking a shared library libcsound 2. The shared library uses -lm 2. The library uses OpenMP 3. Removing the mvec_nonshared makes the shared library link pass, but not the end executables that link with libcsound, complaining about undefined references. 4. The binaries do not use -lm Assistance on this matter is appreciated, I do not know what can be done to fix this. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Status of sonic-pi and supercollider-sc3-plugins (Re: Request for review & inclusion: sonic-pi, see #796550)
Hi, On 22 February 2016 at 06:59, Hanno Zulla <a...@hanno.de> wrote: > Hi Petter, > Hi multimedia-maintainers, > > first of all, thanks for getting the packages up to speed and ready for > Debian. It took a while, but I learned a lot. :-) > > Thanks Petter, I have noticed the issues you mentioned already. > > > supercollider-sc3-plugins fails to build due to a problem with the cmake > configure run. Apparently, something goes wrong when cmake is calling > another cmake as a sub-process. As a result, on some, but not on all > platforms the cmake TEST_BIG_ENDIAN call fails. As sc3-plugins ought to > be endian-aware, I think this is a cmake problem. > I see the problem is in the stk subdir. Maybe the endianness test can be skipped if using a system stk? -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: preparing new RtMidi release, question about SO version
On 17 February 2016 at 12:51, Stephen Sinclair <radars...@gmail.com> wrote: > On Wed, Feb 17, 2016 at 12:34 PM, Felipe Sateler <fsate...@debian.org> wrote: >> On 17 February 2016 at 12:02, Stephen Sinclair <radars...@gmail.com> wrote: >>> Thanks very much Felipe, that clarifies things immensely. >> >> :) >> >>> >>> A last question, is there a difference between using this -release >>> style versioning and simply bumping the SO name on every release? >> >> The only appreciable difference I see is aesthetics, and ease of use >> if you already use libtool. A SONAME libfoo-x.y.z.so allows moving to >> SONAME libfoo.so.0 once the ABI is deemed stable. The alternative >> would be to have SONAME libfoo.so.LargeNumber as the first stable ABI >> release. And libtool has a flag/option/command/something so that the >> autotools project version is automatically used as the soname version, >> instead of manually bumping the version on each release. > > Ahh.. did not know this! > > I thought I'd done my research, but these little bits of technical > knowledge always seem to catch me. > > https://www.gnu.org/software/libtool/manual/html_node/Release-numbers.html BTW, you might want to apply this as well to rtaudio: https://github.com/thestk/rtaudio/issues/17 -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: preparing new RtMidi release, question about SO version
On 17 February 2016 at 12:02, Stephen Sinclair <radars...@gmail.com> wrote: > Thanks very much Felipe, that clarifies things immensely. :) > > A last question, is there a difference between using this -release > style versioning and simply bumping the SO name on every release? The only appreciable difference I see is aesthetics, and ease of use if you already use libtool. A SONAME libfoo-x.y.z.so allows moving to SONAME libfoo.so.0 once the ABI is deemed stable. The alternative would be to have SONAME libfoo.so.LargeNumber as the first stable ABI release. And libtool has a flag/option/command/something so that the autotools project version is automatically used as the soname version, instead of manually bumping the version on each release. > > In any case, I'll keep these recommendations in mind for all my > projects (which for some reason always seem to be libraries.. god... > :P), thanks. Thanks for caring about Rt*. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#814984: Supercollider: Add hardening flags to debian/rules in supercollider source package
On 17 February 2016 at 10:14, Hanno Zulla <a...@hanno.de> wrote: > Hi, > >> I have not tested this, does this actually pass the right variables? >> I'm wary of the interactions between the cdbs rules and including >> dpkg's makefile snippet. Unfortunately , bug #712729 means the >> built-int support in cdbs is currently broken :( > > When I tested it locally, lintian stopped complaining about missing > hardening, so it seemed to work. But as I have no experience with cdbs, > it may be better to do this through cdbs instead of my patch and push > for 712729 to be fixed. Yeah, unfortunately my make-fu was not enough to catch the problem in that bug. Moreover, what would happen if we apply the patch, and then later on cdbs is fixed? Would we get flags twice, and if so, would it be a problem? -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#814984: Supercollider: Add hardening flags to debian/rules in supercollider source package
On 17 February 2016 at 07:42, Hanno Zulla <a...@hanno.de> wrote: > Source: supercollider > Version: 1:3.6.6_repack-2-2 > Severity: minor > > Hi there, Hi, > > sid's lintian complains about missing hardening in the supercollider > build. This patch adds the needed flags. > > Please let me know > > a) if this patch is correct I have not tested this, does this actually pass the right variables? I'm wary of the interactions between the cdbs rules and including dpkg's makefile snippet. Unfortunately , bug #712729 means the built-int support in cdbs is currently broken :( > > b) if this is the proper format to submit it This is OK, although given you are already in the team you could have pushed a branch and asked for review/merge to the git repo directly (or an ACK to do the merge yourself). > > c) if this is the proper channel to submit patches like this. This is OK, as it also helps keeping track of patches. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: preparing new RtMidi release, question about SO version
On 15 February 2016 at 16:38, Stephen Sinclair <radars...@gmail.com> wrote:
> On Mon, Feb 15, 2016 at 12:05 PM, Felipe Sateler <fsate...@debian.org> wrote:
>> Hi Stephen
>>
>> On 10 February 2016 at 14:21, Stephen Sinclair <radars...@gmail.com> wrote:
>>>
>>> Hello,
>>>
>>> I am helping to update RtMidi, a C++ class for cross-platform MIDI
>>> support. There is a Debian librtmidi package. Although this is just
>>> a bug-fix release, and is planned to go from 2.1.0 to 2.1.1, we have
>>> added some automake/libtool infrastructure, and a last debate is
>>> whether to properly start supporting SO version according to libtool's
>>> rules.
>>
>> Cool. I would be careful, though, because for C++ seemingly innocent
>> changes can break the ABI. STK[1] was recently updated to use
>> libtool's -release style versioning to avoid problems, as some changes
>> broke ABI and were not noticed by upstream as such. This is
>> particularly important for libraries that are used as static libraries
>> (as this kind of breakage might go unnoticed for a while).
>
> So that's sort of part of my question -- I'd like to integrate better
> ABI testing into the usual procedure, so as to avoid changes that
> "were not noticed by upstream." If such problems are more likely
> noticed by packagers, would it be good practice to always request a
> pre-release review by packagers before doing an upstream release? Or
> would that be too much noise? (Not that releases are done very
> often.. but I'm asking in the general case, I'll likely apply this as
> a rule of thumb to other software I maintain.)
Well, I'm not sure packagers do anything special. We do have symbols
files that can help, but those are not currently in use by rtmidi (in
c++ in general they can be a bit of a pain). There are external tools
that can help (like the
abi-{compliance-checker,monitor,viewer,tracker} tools), but I think
the main way to keep this is to do it pre-emptively: be aware of
changes that can change ABI and do not merge those. For C++, this is
quite limiting, though[1]. ABI stability of C++ libraries is hard.
[1]
https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts
>
>> [1] https://github.com/thestk/stk/pull/27
>>>
>>> Previous versions have made the error of treating SO version like the
>>> version number, and producing binaries e.g. librtmidi.so.2.1.0.
>>>
>>> I was recommending changing this to properly reflect ABI
>>> compatibility. What would Debian maintainers prefer here?
>>
>> If (and only if) proper ABI versioning can be done, then I'd prefer
>> that, of course. But using a -release style versioning would also be
>> ok, and force rebuild of all reverse depedends on each upstream
>> version. This should be ok, as there aren't many (6 by my count). This
>> has the advantagae for upstream that they do not have to care about
>> abi.
>
> I don't think it's a huge overhead to check for ABI changes between
> releases, provided this can be done (largely) automatically. Which
> should be possible, although I haven't explored the available tools
> yet. I'm not 100% sure what you mean by -release style versioning.
> You mean append the library version as if it were the SO name?
> Doesn't that lead to complications when there's a bugfix release that
> happens to change the ABI? Or rather you seem to be suggesting a full
> SO bump on every release. I'm not sure if I follow.
Yes, I suggest a full bump on every release. That, while not optimal
from a downstream perspective, is still manageable, and is much more
convenient for upstream and less error-prone.
Note that -release style versioning is setting SONAME as
libfoo-x.y.z.so instead of libfoo.x
>
>>> I proposed making the new SO version 3.0.0, to really emphasize that
>>> the ABI version is new, however since it's a bugfix release I don't
>>> know if that's the recommended strategy.
>>>
>>> https://github.com/thestk/rtmidi/pull/59
>>>
>>> In any case I notice that the interface has changed a bit, e.g. some
>>> functions have lost parameters, others have new parameters, since the
>>> last release.
>>
>> I see the pull request has already been merged. I hope this message
>> doesn't come too late.
>
> Yes, the release has been done. However, I think bumping the SO name
> was the right call, seeing as the ABI signature of setErrorCallback()
> changed. I just figured we may as well use it as an opportunity to
> make it significantly different from the release version while we'
Re: preparing new RtMidi release, question about SO version
Hi Stephen On 10 February 2016 at 14:21, Stephen Sinclair <radars...@gmail.com> wrote: > > Hello, > > I am helping to update RtMidi, a C++ class for cross-platform MIDI > support. There is a Debian librtmidi package. Although this is just > a bug-fix release, and is planned to go from 2.1.0 to 2.1.1, we have > added some automake/libtool infrastructure, and a last debate is > whether to properly start supporting SO version according to libtool's > rules. Cool. I would be careful, though, because for C++ seemingly innocent changes can break the ABI. STK[1] was recently updated to use libtool's -release style versioning to avoid problems, as some changes broke ABI and were not noticed by upstream as such. This is particularly important for libraries that are used as static libraries (as this kind of breakage might go unnoticed for a while). [1] https://github.com/thestk/stk/pull/27 > > Previous versions have made the error of treating SO version like the > version number, and producing binaries e.g. librtmidi.so.2.1.0. > > I was recommending changing this to properly reflect ABI > compatibility. What would Debian maintainers prefer here? If (and only if) proper ABI versioning can be done, then I'd prefer that, of course. But using a -release style versioning would also be ok, and force rebuild of all reverse depedends on each upstream version. This should be ok, as there aren't many (6 by my count). This has the advantagae for upstream that they do not have to care about abi. > > I proposed making the new SO version 3.0.0, to really emphasize that > the ABI version is new, however since it's a bugfix release I don't > know if that's the recommended strategy. > > https://github.com/thestk/rtmidi/pull/59 > > In any case I notice that the interface has changed a bit, e.g. some > functions have lost parameters, others have new parameters, since the > last release. I see the pull request has already been merged. I hope this message doesn't come too late. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#805549: Patch for strech, jessie, wheezy
On 12 Jan 2016 03:08, "Adam D. Barratt" <a...@adam-barratt.org.uk> wrote: > > On Tue, 2015-12-15 at 13:18 +, Adam D. Barratt wrote: > > On 2015-12-15 13:04, Felipe Sateler wrote: > > > Hi, > > > > > > Dear release team, I'm copying you to ask if the attached patch would > > > be OK to upload to stable/oldstable, fixes bug #805549. This error > > > makes some builds against stk impossible, since there are two headers > > > missing. > > > > > > The version in unstable is a different upstream version, so the patch > > > is not exactly the same (attached is a patch on a patch, currently we > > > patch the real file, as the previous patch was accepted upstream). > > > > In isolation, the patch looks okay. In order to get approval for actual > > uploads for stable and oldstable, however, please open a p-u bug for > > each, including a full source debdiff for a package built and tested on > > that distribution. > > I note that there are now #810760 and #810761. For future reference, > "[i]n order to get approval", implied opening the bugs _before_ the > uploads, not afterwards. Oops. Sorry, will do correctly next time. I suppose I somehow let "built and tested" also include "uploaded". Saludos ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#810760: jessie-pu: package stk/4.4.4-5
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
This fixes bug 805549 in jessie. This bug makes the dev package useless
in certain conditions.
Package is already uploaded to p-u, diff is attached.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/changelog b/debian/changelog
index 258ec0c..2a73017 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+stk (4.4.4-5+deb8u1) jessie; urgency=medium
+
+ [ Hanno Zulla ]
+ * Install missing SKINI.{msg,tbl} include files
+
+ -- Felipe Sateler <fsate...@debian.org> Fri, 18 Dec 2015 16:33:16 -0300
+
stk (4.4.4-5) unstable; urgency=medium
* Prepare for new rtaudio and rtmidi
diff --git a/debian/gbp.conf b/debian/gbp.conf
index cec628c..0e268a7 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,2 +1,3 @@
[DEFAULT]
pristine-tar = True
+debian-branch = debian/jessie
diff --git a/debian/patches/01-makefile.patch b/debian/patches/01-makefile.patch
index 3452268..7fb1106 100644
--- a/debian/patches/01-makefile.patch
+++ b/debian/patches/01-makefile.patch
@@ -64,7 +64,7 @@ Forwarded: no
+install-headers:
+ install -d $(DESTDIR)/usr/include/stk
-+ cp -r ../include/*.h $(DESTDIR)/usr/include/stk
++ cp -r ../include/* $(DESTDIR)/usr/include/stk
+
+install: $(SHAREDLIB) install-headers
+ install -d $(DESTDIR)/usr/share/stk
diff --git a/debian/rules b/debian/rules
index 4096934..b309804 100755
--- a/debian/rules
+++ b/debian/rules
@@ -34,6 +34,9 @@ override_dh_auto_configure:
mkdir -p src/Release
mkdir -p projects/demo/Release
+override_dh_auto_install:
+ dh_auto_install
+ rm -f debian/tmp/usr/include/stk/*.bak
override_dh_link:
dh_link
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#810761: wheezy-pu: package stk/4.4.3-2
Package: release.debian.org
Severity: normal
Tags: wheezy
User: release.debian@packages.debian.org
Usertags: pu
This update fixes bug 805549 on wheezy. This bug makes the dev package
useless for certain uses. Package is uploaded to p-u, diff is attached.
Saludos
-- System Information:
Debian Release: stretch/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/changelog b/debian/changelog
index 1b2036a..820f37b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+stk (4.4.3-2+deb7u1) wheezy; urgency=medium
+
+ [ Hanno Zulla ]
+ * Install missing SKINI.{msg,tbl} include files
+
+ -- Felipe Sateler <fsate...@debian.org> Fri, 18 Dec 2015 16:41:38 -0300
stk (4.4.3-2) unstable; urgency=low
[ Felipe Sateler ]
diff --git a/debian/gbp.conf b/debian/gbp.conf
index cec628c..d3f1da8 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,2 +1,4 @@
[DEFAULT]
pristine-tar = True
+debian-branch = debian/wheezy
+
diff --git a/debian/patches/01-makefile.patch b/debian/patches/01-makefile.patch
index 26fa351..db34483 100644
--- a/debian/patches/01-makefile.patch
+++ b/debian/patches/01-makefile.patch
@@ -64,7 +64,7 @@ Forwarded: no
+install-headers:
+ install -d $(DESTDIR)/usr/include/stk
-+ cp -r ../include/*.h $(DESTDIR)/usr/include/stk
++ cp -r ../include/* $(DESTDIR)/usr/include/stk
+
+install: $(SHAREDLIB) install-headers
+ install -d $(DESTDIR)/usr/share/stk
diff --git a/debian/rules b/debian/rules
index f6a9bb8..809929b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -21,6 +21,10 @@ override_dh_auto_configure:
dh_auto_configure -- $(CONFIGURE_FLAGS)
mkdir -p src/Release
+override_dh_auto_install:
+ dh_auto_install
+ rm -f debian/tmp/usr/include/stk/*.bak
+
override_dh_installchangelogs:
dh_installchangelogs doc/ReleaseNotes.txt
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: New version of multimedia metapackages ready
On 7 January 2016 at 13:47, Ross Gammon <r...@the-gammons.net> wrote: > On 01/07/2016 02:01 PM, Felipe Sateler wrote: > [...] > >> Hi, I've been meaning to grant you DM upload rights, but I've found >> myself short on time. I hope to do this this afternoon. > > No problems. There is no real urgency for the metapackages. Would be > good to have the latest in Ubuntu before their freeze in February. I've granted the upload rights. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#805549: Patch for strech, jessie, wheezy
(Dropping release team while we prepare)
On 15 December 2015 at 10:18, Adam D. Barratt <a...@adam-barratt.org.uk> wrote:
> On 2015-12-15 13:04, Felipe Sateler wrote:
>>
>> Hi,
>>
>> Dear release team, I'm copying you to ask if the attached patch would
>> be OK to upload to stable/oldstable, fixes bug #805549. This error
>> makes some builds against stk impossible, since there are two headers
>> missing.
>>
>> The version in unstable is a different upstream version, so the patch
>> is not exactly the same (attached is a patch on a patch, currently we
>> patch the real file, as the previous patch was accepted upstream).
>
>
> In isolation, the patch looks okay. In order to get approval for actual
> uploads for stable and oldstable, however, please open a p-u bug for each,
> including a full source debdiff for a package built and tested on that
> distribution.
Hanno, could you please test on a wheezy and on a jessie system that
what is living in the debian/{wheezy,jessie} branches works? I don't
foresee any problems, but we should test first.
--
Saludos,
Felipe Sateler
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#805549: Patch for strech, jessie, wheezy
Hi, Dear release team, I'm copying you to ask if the attached patch would be OK to upload to stable/oldstable, fixes bug #805549. This error makes some builds against stk impossible, since there are two headers missing. The version in unstable is a different upstream version, so the patch is not exactly the same (attached is a patch on a patch, currently we patch the real file, as the previous patch was accepted upstream). However, it is functionally the same[1]. [1] http://anonscm.debian.org/cgit/pkg-multimedia/stk.git/tree/debian/patches/0006-Install-missing-include-files-SKINI.msg-and-SKINI.tb.patch On 15 December 2015 at 06:38, Hanno Zulla <a...@hanno.de> wrote: > Hi, > > thanks for fixing this in sid's package. I can confirm that it works to > package supercollider-sc3-plugins. > > It would be beneficial if this could be fixed for > > strech This will make it automatically in a few days. > jessie > wheezy These won't, we need release team ACK for this. > too. Why even back to wheezy? Because supercollider-sc3-plugins is also > meant to be used by Raspbian, which is packaging their distribution > based on wheezy and jessie. > > Please find an attached patch which will fix this for all three versions > of the current Debian source package. -- Saludos, Felipe Sateler *** stk-4.4.4/debian/patches/01-makefile.patch 2015-09-21 19:17:01.0 +0200 --- stk-4.4.4.patched/debian/patches/01-makefile.patch 2015-12-15 10:19:37.320848851 +0100 *** *** 64,70 +install-headers: + install -d $(DESTDIR)/usr/include/stk ! + cp -r ../include/*.h $(DESTDIR)/usr/include/stk + +install: $(SHAREDLIB) install-headers + install -d $(DESTDIR)/usr/share/stk --- 64,70 +install-headers: + install -d $(DESTDIR)/usr/include/stk ! + cp -r ../include/* $(DESTDIR)/usr/include/stk + +install: $(SHAREDLIB) install-headers + install -d $(DESTDIR)/usr/share/stk ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#807621: transition: stk
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, A transition is needed for stk. I have confirmed that both rdeps, csound and lmms, build with the new version that I am about to upload. The package has already gone through binNEW and is in experimental. Ben file: title = "stk"; is_affected = .depends ~ "libstk0v5" | .depends ~ "libstk-4.5.0"; is_good = .depends ~ "libstk-4.5.0"; is_bad = .depends ~ "libstk0v5"; -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Comments regarding stk_4.5.0-1_amd64.changes
Hi Thorsten On 3 December 2015 at 11:13, Thorsten Alteholz <ftpmas...@ftp-master.debian.org> wrote: > Hi Felipe, > > I marked your package for accept, Thanks! > but please take care of: > E: stk source: source-is-missing doc/html/jquery.js I will make sure that the docs are rebuilt so this isn't used. This is a doxygen artifact. This file does not even appear to be used at all by the documentation, so I will ask upstream if this file could be skipped entirely. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#781938: RFS: vid.stab/0.98b-1
On 29 November 2015 at 18:17, Vincent Pinon <vpi...@april.org> wrote: > Hello, > > One month later, I still haven't forgotten that task, sorry for the delay ;) > new upload here: > http://mentors.debian.net/package/vid.stab > > Le mardi 27 octobre 2015, 00:16:57 Andreas Cadhalpun a écrit : > [snip] >> * d/control: >> - 'Priority: optional' not extra >> - packages should be 'Multi-Arch: same' >> * d/copyright: misses copyright of 'Alexey Osipov' > Done, thanks for guidance! > >> The tests could be run e.g. with: >> cd tests; cmake .; make all; ./tests >> However, the return code is wrong [2]. > I included your patch, but I'm not sure how to add & run test target in > debian/rules. You can do: override_dh_auto_test: #test commands here > This might go into future improvements, with the runtime loading of SSE on > i386? (Felipe's suggestion) I'd add -DSSE2_FOUND=false to the cmake invocation when run on i386. This appears to be enough to disable the sse flags > > I don't know if this packaging activity is worth versioning on alioth, as > upstream doesn't seem to evolve any/much more? > If yes anyway, am I allowed to initialize a git repo? I think git history is always useful, although pre-first release history not so much (so we can create the repo with the uploaded package). Please apply to the pkg-multimedia project on alioth, and read the wiki https://alioth.debian.org/projects/pkg-multimedia https://wiki.debian.org/DebianMultimedia/DevelopPackaging -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Retry CsoundQt build in arm64
On 10 November 2015 at 12:34, Wookey <woo...@wookware.org> wrote: > > +++ Felipe Sateler [2015-11-10 10:58 -0300]: > > Hi, > > > > I'm wondering what happened to csoundqt on arm64. It appears as building > > for 3 > > days, which is not normal (eg, it took a few minutes in armel if Build-Time > > is > > in seconds). Maybe it needs to be retried? There is no log currently for > > arm64 > > so there is not much clue as to what is going on. > > yeah. something stalled/died. given-back. Thanks! I see it now built correctly. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Retry CsoundQt build in arm64
Hi, I'm wondering what happened to csoundqt on arm64. It appears as building for 3 days, which is not normal (eg, it took a few minutes in armel if Build-Time is in seconds). Maybe it needs to be retried? There is no log currently for arm64 so there is not much clue as to what is going on. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: upcoming ffmpeg transition
On 2 November 2015 at 14:40, Andreas Cadhalpun <andreas.cadhal...@googlemail.com> wrote: > On 02.11.2015 00:57, Felipe Sateler wrote: >> On 1 November 2015 at 19:51, Andreas Cadhalpun >> <andreas.cadhal...@googlemail.com> wrote: >>> >>> building: 30 >>> simple changes: 61 >>> complex changes:21 >>> -- >>> total: 112 >> >> How did you come up with those numbers? Did you actually make a patch for >> each?? > > Yes, of course. That's the only way to get accurate numbers. ;) Excellent. That makes the transition much smoother. > >>> I'll file bug reports for the affected packages with: >>> User: pkg-multimedia-maintainers@lists.alioth.debian.org >>> Usertags: ffmpeg2.9 >> >> Do the required changes work already? IOW, if a patch is applied can >> it build with ffmpeg 2.8? > > Yes, the only exception is, as always, taoframework with its hardcoded > SONAMEs. Ugh. Feel free to ping me for NMUs if packages are not updated in time for the transition. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: upcoming ffmpeg transition
On 1 November 2015 at 19:51, Andreas Cadhalpun <andreas.cadhal...@googlemail.com> wrote: > Hi, > > ffmpeg upstream removed some deprecated APIs, so the next release will require > a transition. A large number of reverse dependencies need source code patches. > Most of those are simple changes like renaming functions/macros, but some are > more complex: > > building: 30 > simple changes: 61 > complex changes:21 > -- > total: 112 How did you come up with those numbers? Did you actually make a patch for each?? > > I'll file bug reports for the affected packages with: > User: pkg-multimedia-maintainers@lists.alioth.debian.org > Usertags: ffmpeg2.9 Do the required changes work already? IOW, if a patch is applied can it build with ffmpeg 2.8? > Additionally, there are five unrelated FTBFS bugs among the affected packages: > bino: #802374 > gazebo:#797809 > mrpt: #803700 > ovito: #803701 > pjproject: #793094 > > It would be good if most of this was fixed, when the next ffmpeg > version gets released. I'd use severity: important. When the release gets done, then the severity is bumped to serious. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Introduction and request to join the Multimedia Team: Víctor Cuadrado Juan (viccuad)
Hi Victor, On 28 October 2015 at 12:27, Víctor Cuadrado Juan <m...@viccuad.me> wrote: > Hello, > My name is Víctor Cuadrado Juan, and I would like to become part of the > Debian Multimedia Team. Welcome! > > I'm a Spanish guy whose background is Computer Science Engineering, and > I'm interested in digital audio processing (apart from FOSS :). I have > used Ardour and audio plugins briefly a couple of times in the past, and > I (somewhat :) play drums and guitar. > > I intend to maintain at least the drumgizmo package[1][2], > and help with other packages under the Multimedia Team umbrella when > it's under my possibilities. > > I have already subscribed to pkg-multimedia-maintainers and > pkg-multimedia-commits mailing lists, and my alioth account is > "viccuad-guest". I have added you on alioth. Please make sure to read our wiki[1] as well! [1] wiki.debian.org/DebianMultimedia/DevelopPackaging -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: RFS: vid.stab/0.98b-1
On 26 October 2015 at 02:00, Vincent Pinon <vpi...@april.org> wrote: >> - You might want to keep the epoch so that people installing those >> packages can upgrade to this version when it lands in debian. > I also think that we should start with a clear base in Debian, > so I reset the changelog (wiping the dmo & ubuntu-ppa mix, but keeping > copyright)... > >> - Please use the alioth list as the maintainer (check any other team >> package [eg, csound] for the name and address). In general please read >> the guidelines in the wiki[1] > Sorry, fixed, and read again the ref page :) > >> - Please drop the builddeb override, xz is the default. > done > >> - On i386, we need to disable sse, as it is not guaranteed to be >> available on all hosts. I think it can be loaded at runtime by using >> the hardware capabilities feature of glibc linker: >>- Compile the package twice, once with and once without sse. >>- Ship the non-sse version in /usr/lib/i386-linux-gnu/ >>- Ship the sse version in /usr/lib/i386-linux-gnu/sse2 >>- Then ld.so will choose the appropriate version at runtime (see >> the ld.so manpage for details). > Hum, a bit beyond my packaging knowledge... > Do you have an example? It is a bit convoluted. Maybe we could start by force-disabling SSE on i386 and then later add a second sse version? > >> - debian/copyright needs dates updated (2010-2014 for the upstream part). > Done > > All these changes in forced-upload again: > https://mentors.debian.net/package/vid.stab > >> - You might want to forward the patch upstream. > Right, I will do it I see that Andreas Cadhalpun (in CC) expressed interest in this package and apparently already forwarded that patch upstream. Andreas, did you ever get a response on that? I'm adding the ITP (and all participants) back to CC to let them know about your work. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: rtkit diff in Ubuntu
On 22 October 2015 at 09:56, Felipe Sateler <fsate...@debian.org> wrote: > On 21 October 2015 at 11:28, Martin Pitt <mp...@debian.org> wrote: >> Hey Felipe, >> >> Felipe Sateler [2015-10-18 12:52 -0300]: >>> It took me a while to do this, but I've finally uploaded a rtkit that >>> can be (I think) synced back to ubuntu. I also had to apply the rt >>> linkage fix. If anything remains, please let me know! >> >> Thanks for this! The only remaining delta is now that >> debian/patches/ubuntu.series still has old patch names >> (01-no_ptrace_cap.patch and configure.patch) which don't actually >> exist, and is missing some patches. >> >> But in fact, the Debian and Ubuntu patches are now exactly the same, >> so if you could just completely kill debian/patches/ubuntu.series, we >> would be in perfect sync again. > > Huh, I thought I did. I guess since my build just ignored it, I didn't notice. > > I don't think I can do this in the next few days, but I've added this > to my TODO. NMUs or team uploads welcome! OK, I uploaded a new version nuking the ubuntu.series file. We should be able to sync now. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: RFS: vid.stab/0.98b-1
On 25 October 2015 at 17:21, Vincent Pinon <vpi...@april.org> wrote: > Le dimanche 25 octobre 2015 16:54:59, Felipe Sateler a écrit : >> On 25 October 2015 at 16:14, Vincent Pinon <vpi...@april.org> wrote: >> > Sorry for the late answer, I was on holiday trip with family... >> > I just re-uploaded both vid.stab_0.98b-1_amd64.changes and added >> > vid.stab_0.98b-1_source.changes >> > (added symbols file and fixed last lintian warnings in the meantime). >> >> I need a link to the sources ;) > I sent the files through "dput mentors vid.stab_0.98b-1_amd64.changes" OK, so this is the package: http://mentors.debian.net/package/vid.stab But it seems it is not the new version, as it does not have the symbols file. Anyway, some more comments: - You might want to keep the epoch so that people installing those packages can upgrade to this version when it lands in debian. - Please use the alioth list as the maintainer (check any other team package [eg, csound] for the name and address). In general please read the guidelines in the wiki[1] - Please drop the builddeb override, xz is the default. - On i386, we need to disable sse, as it is not guaranteed to be available on all hosts. I think it can be loaded at runtime by using the hardware capabilities feature of glibc linker: - Compile the package twice, once with and once without sse. - Ship the non-sse version in /usr/lib/i386-linux-gnu/ - Ship the sse version in /usr/lib/i386-linux-gnu/sse2 - Then ld.so will choose the appropriate version at runtime (see the ld.so manpage for details). - debian/copyright needs dates updated (2010-2014 for the upstream part). - You might want to forward the patch upstream. This library looks very cool :) [1] https://wiki.debian.org/DebianMultimedia/DevelopPackaging -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: rtkit diff in Ubuntu
On 21 October 2015 at 11:28, Martin Pitt <mp...@debian.org> wrote: > Hey Felipe, > > Felipe Sateler [2015-10-18 12:52 -0300]: >> It took me a while to do this, but I've finally uploaded a rtkit that >> can be (I think) synced back to ubuntu. I also had to apply the rt >> linkage fix. If anything remains, please let me know! > > Thanks for this! The only remaining delta is now that > debian/patches/ubuntu.series still has old patch names > (01-no_ptrace_cap.patch and configure.patch) which don't actually > exist, and is missing some patches. > > But in fact, the Debian and Ubuntu patches are now exactly the same, > so if you could just completely kill debian/patches/ubuntu.series, we > would be in perfect sync again. Huh, I thought I did. I guess since my build just ignored it, I didn't notice. I don't think I can do this in the next few days, but I've added this to my TODO. NMUs or team uploads welcome! -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: rtkit diff in Ubuntu
Hi again, On 3 May 2015 at 20:10, Luke Yelavich <luke.yelav...@canonical.com> wrote: > On Wed, Apr 29, 2015 at 11:01:47PM AEST, Felipe Sateler wrote: >> On 28 April 2015 at 11:07, Felipe Sateler <fsate...@debian.org> wrote: >> > On 28 April 2015 at 10:32, Martin Pitt <mp...@debian.org> wrote: >> >> Hey Felipe, >> >> >> >> Felipe Sateler [2015-04-24 18:25 -0300]: >> >>> I see that rtkit has diverged in Ubuntu. Should debian incorporate the >> >>> patch added to check for mq_getattr? Why is it necessary? >> >> >> >> TBH I don't know; I figure back then it failed to build with >> >> -Wl,--as-needed (as we have in Ubuntu by default) because it forgot to >> >> link against -lrt, but this doesn't happen on current 15.04. So I >> >> figure we can drop this patch. >> >> >> >> So if you could also apply the unfuzzing of 01-no_ptrace_cap.patch in >> >> Debian, I think we would be back in sync. >> > >> > Ok, I will do that for the next upload. I will request a sync when I >> > do so pointing to this discussion. >> >> Hmm, so 01-no_ptrace_cap.patch is not applied by debian. Maybe we >> should apply it as well? If so we should also probably drop the >> CAP_SYS_PTRACE from the systemd unit. >> >> Luke, why did you add this patch? The ubuntu changelog does not give >> hints as to why it is there... > > As per the Ubuntu main inclusion request bug, > https://bugs.launchpad.net/bugs/396396 the Ubuntu security team requested it > be removed. > > I also believe it was originally in the changelog when the Ubuntu package was > created, but that changelog entry was lost when Debian took the diff, and the > package was synced. It took me a while to do this, but I've finally uploaded a rtkit that can be (I think) synced back to ubuntu. I also had to apply the rt linkage fix. If anything remains, please let me know! -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#801886: xbmc: systemd support
Control: user pkg-systemd-maintain...@lists.alioth.debian.org Control: usertags -1 systemd-units Hi Ritesh On 15 October 2015 at 13:38, Ritesh Raj Sarraf <r...@debian.org> wrote: > Source: xbmc I think this should have been kodi ? > Severity: wishlist > > Hello Balint, > > As much as I wished to move back to Debian with my RPi 2, I > unfortunately cannot because the graphics driver is not well free. > > Until then, I'll send you patches. Attached is my small adaptation of > systemd .service to work on my Raspbian Jessie image. > [Unit] > Description = Starts instance of Kodi Please don't use spaces around the = separator. Although systemd currently parses that ok, dh-systemd doesn't and it is not part of the official spec so it may break in the future. > After = systemd-user-sessions.service network.target sound.target > mysqld.service > > [Service] > User = kodi > Type = simple > ExecStart = /usr/bin/kodi-standalone Does kodi-standalone signal that it is ready somehow? If it has an option to daemonize itself, you should use that + Type=forking instead. > Restart = on-abort > > [Install] > WantedBy = multi-user.target -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Changing the wiki suggestion to push using --tags to --follow-tags ?
On 9 October 2015 at 02:12, Jaromír Mikeš <mira.mi...@gmail.com> wrote: > 2015-10-05 9:21 GMT+02:00 Jaromír Mikeš <mira.mi...@gmail.com>: >> 2015-10-02 21:31 GMT+02:00 Felipe Sateler <fsate...@debian.org>: > > Hi Felipe, > >>> I recently became aware of the --follow-tags option to git push. The >>> advantage over --tags is that --follow-tags only pushes the tags that >>> are reachable from the commits pushed. So unrelated tags (eg, upstream >>> ones) are not pushed along to the alioth repository. >>> >>> What do you think about changing the wiki recommendation to use it? I >>> think we should change it. >> >> looks like there are clear advantages and no objections, so lets go to >> change it. > > Should I edit our wiki pages [1] or you will do it yourself? > > [1] https://wiki.debian.org/DebianMultimedia/DevelopPackaging I changed this. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: RFS: vid.stab/0.98b-1
Hi Vincent, On 12 October 2015 at 01:08, Vincent Pinon <vpinon@gmail.com> wrote: > Hello, > > I posted my introduction message to the wrong list, just understanding 1 > month after... > Here it comes again ;-) Do you have a link to the source package? -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: qxgedit review
On 2 October 2015 at 03:49, Jaromír Mikeš <mira.mi...@gmail.com> wrote: > > 2015-09-29 14:59 GMT+02:00 Felipe Sateler <fsate...@debian.org>: > > On 29 September 2015 at 03:12, Jaromír Mikeš <mira.mi...@gmail.com> wrote: > >> 2015-06-15 16:30 GMT+02:00 Jaromír Mikeš <mira.mi...@gmail.com>: > >>> 2015-05-14 1:50 GMT+02:00 Jaromír Mikeš <mira.mi...@gmail.com>: > >>>> Hello, > >>>> > >>>> qxgedit is almost ready. > >>>> I'm having this two warnings which I am not able currently fix ;( > >>>> > >>>> I would be happy if somebody would find a time to review a package and > >>>> possibly upload. > >>> > >>> Nobody? :( > >> > >> Hi, > >> > >> qxgedit is updated to latest upstream version now. > >> Can some DD upload it to NEW please? > > > > I can probably take a look during the weekend (hopefully earlier). > > Please ping me again on friday or so if I haven't uploaded, so that I > > don't forget. > > Ping ;) Uploaded! OT, I recently found out about the --follow-tags git push option, which helps not forgetting to push the tags :) -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: qxgedit review
On 2 October 2015 at 15:17, Jaromír Mikeš <mira.mi...@gmail.com> wrote: > 2015-10-02 18:26 GMT+02:00 Jonas Smedegaard <d...@jones.dk>: >> Quoting Jaromír Mikeš (2015-10-02 18:04:15) >>> 2015-10-02 15:03 GMT+02:00 Felipe Sateler <fsate...@debian.org>: >>>> OT, I recently found out about the --follow-tags git push option, >>>> which helps not forgetting to push the tags :) >> >> Ohh, cool! I wasn't aware of that one. >> >>> Hmm ... not sure if I am understanding advantage against --tags option :( >>> Can you explain pls? >> >> Problem with --tags is it pushes _all_ tags, also ones irrelevant for >> the the work being pushed (e.g. ones tied to upstream branches). > > Got it ;) > Than we should maybe use it rather than --tags option and edit our > wiki pages [1] > Should we change it in all cases? I think so. I don't see any reason why we should prefer using --tags rather than --follow-tags. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Changing the wiki suggestion to push using --tags to --follow-tags ?
Hi, I recently became aware of the --follow-tags option to git push. The advantage over --tags is that --follow-tags only pushes the tags that are reachable from the commits pushed. So unrelated tags (eg, upstream ones) are not pushed along to the alioth repository. What do you think about changing the wiki recommendation to use it? I think we should change it. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: qxgedit review
On 29 September 2015 at 03:12, Jaromír Mikeš <mira.mi...@gmail.com> wrote: > 2015-06-15 16:30 GMT+02:00 Jaromír Mikeš <mira.mi...@gmail.com>: >> 2015-05-14 1:50 GMT+02:00 Jaromír Mikeš <mira.mi...@gmail.com>: >>> Hello, >>> >>> qxgedit is almost ready. >>> I'm having this two warnings which I am not able currently fix ;( >>> >>> I would be happy if somebody would find a time to review a package and >>> possibly upload. >> >> Nobody? :( > > Hi, > > qxgedit is updated to latest upstream version now. > Can some DD upload it to NEW please? I can probably take a look during the weekend (hopefully earlier). Please ping me again on friday or so if I haven't uploaded, so that I don't forget. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: linuxsampler?
On 29 September 2015 at 11:59, IOhannes m zmölnig <zmoel...@umlaeute.mur.at> wrote: > On 09/29/2015 04:49 PM, Alessio Treglia wrote: >> On Tue, Sep 29, 2015 at 3:29 PM, IOhannes m zmölnig (Debian/GNU) >> <umlae...@debian.org> wrote: >>> it apparently is non-free, but is this the only reason? >>> (i searched the net, but couldn't find anything) >> >> It's a long standing issue, upstream releases it under a sort GPL with >> a commercial exception [1], that makes >> >> 1. no sense at all >> 2. the whole software package in conflict with the GPL itself >> >> I don't think we could even upload it to non-free, though I'm not 100% sure. >> > > i'm aware of the exception, but thought that non-free might be ok. > > while i don't care much about your 1st point, the 2nd one is obviously > important (and the FSF seems to agree with you [1]). > > [1] http://www.gnu.org/licenses/gpl-faq.en.html#NoMilitary This FAQ suggests to me that the clause is just void, but the wording is not very clear. -- Saludos, Felipe Sateler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#799977: libjack-jackd2-dev: needless dependency on libdbus-dev
Package: libjack-jackd2-dev Version: 1.9.10+20150825git1ed50c92~dfsg-1 Severity: minor Hi, While jackd2 provides a dbus api, that does not mean that jack clients need to build with dbus. The dependency is unnecessary. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libjack-jackd2-dev depends on: ii libdbus-1-dev 1.10.0-3 ii libjack-jackd2-0 1.9.10+20150825git1ed50c92~dfsg-1 ii pkg-config0.28-1 libjack-jackd2-dev recommends no packages. libjack-jackd2-dev suggests no packages. -- no debconf information ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
