retitle 870787 liboss4-salsa*: please add six snd_{midi,seq}_* functions
affects 870787 src:portmidi
thanks
Hello again,
we also need the following symbols in oss-salsa:
• snd_midi_event_encode_byte
• snd_midi_event_free
• snd_midi_event_new
• snd_seq_delete_port
• snd_seq_disconnect_from
On Thu, 5 Apr 2018, Fabian Greffrath wrote:
> Have you considered to trigger a transition in backports from
> fluidr3mono-gm-soundfont to musescore-general-soundfont by turning the
> former into a dummy package with a dependency on the latter?
No, first and foremost because we don't do this in
Hi everyone (especially Fabian and Toddy),
now that MuseScore 2.2.1 has entered unstable, I would like to
share my plans for how to deal with backports.
musescore-sftools (needed to compile soundfonts) is currently
in backports-NEW for stretch-backports.
fluidr3mono-gm-soundfont is in good and
dia-maintainers@lists.alioth.debian.org>
Changed-By: Thorsten Glaser <t...@mirbsd.de>
Description:
musescore - Free music composition and notation software
musescore-common - Free music composition and notation software (common files)
Closes: 802710
Changes:
musescore (2.2.1+dfsg1-1) unstable;
<pkg-multimedia-maintainers@lists.alioth.debian.org>
Changed-By: Thorsten Glaser <t...@mirbsd.de>
Description:
musescore - Free music composition and notation software
musescore-common - Free music composition and notation software (common files)
Changes:
musescore (2.2~pre2018
pkg-multimedia-maintainers@lists.alioth.debian.org>
Changed-By: Thorsten Glaser <t...@mirbsd.de>
Description:
musescore - Free music composition and notation software
musescore-common - Free music composition and notation software (common files)
Changes:
musescore (2.1.0+dfsg3-3) unstable; ur
pkg-multimedia-maintainers@lists.alioth.debian.org>
Changed-By: Thorsten Glaser <t...@mirbsd.de>
Description:
musescore - Free music composition and notation software
musescore-common - Free music composition and notation software (common files)
Changes:
musescore (2.2~pre2018
pkg-multimedia-maintainers@lists.alioth.debian.org>
Changed-By: Thorsten Glaser <t...@mirbsd.de>
Description:
musescore - Free music composition and notation software
musescore-common - Free music composition and notation software (common files)
Changes:
musescore (2.1.0+dfsg3-2) unstable;
tl;dr: I’m working on *all* MuseScore soundfont issues.
Hi Fabian,
> Am Dienstag, den 10.10.2017, 21:18 +0200 schrieb Thorsten Glaser:
> > They could switch to a different one, is what I meant.
> >
> > (or embed it in the C source… *shudder*)
>
> Whoa, I t
dia-maintainers@lists.alioth.debian.org>
Changed-By: Thorsten Glaser <t...@mirbsd.de>
Description:
musescore - Free music composition and notation software
musescore-common - Free music composition and notation software (common files)
Changes:
musescore (2.1.0+dfsg3-1) unstable;
<pkg-multimedia-maintainers@lists.alioth.debian.org>
Changed-By: Thorsten Glaser <t...@mirbsd.de>
Description:
musescore - Free music composition and notation software
musescore-common - Free music composition and notation software (common files)
Closes: 802710
Changes:
mu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Format: 1.8
Date: Mon, 05 Mar 2018 02:54:25 +0100
Source: fluidr3mono-gm-soundfont
Binary: fluidr3mono-gm-soundfont
Architecture: source all
Version: 2.315-1
Distribution: unstable
Urgency: high
Maintainer: Thorsten Glaser <t...@mirbsd.de>
C
retitle 842926 musescore: Segment violation when Musescore opens with wizard
(start center) active
thanks
Hi,
does this still occur?
If so, I have a hunch that this will be fixed
in 2.2~pre20180302+dfsg1-1 (which will be uploaded
after ftpmaster process the other two NEW packages).
If not,
Things are getting fixed upstream.--- Begin Message ---
Comment by ericfontainejazz:
Please see https://github.com/musescore/MuseScore/pull/3498 [1] which removes
that private header entirely. That might fix this bug as well.
Cross-linking to that PR's issue: #269845: may crash before splash
James Cowgill dixit:
>I guess you want to change it to "%5.4gx" or something else? The point
>where we change from normal to scientific notation is fairly arbitrary.
I guess I'd expect to never see scientific notation for
speed/progress indicators (the numbers switch very quickly,
and length is
Package: ffmpeg
Version: 7:3.4-4+b2
Severity: wishlist
size= 71457kB time=01:10:25.91 bitrate= 138.5kbits/s speed=1.4e+03x
I guess my computer is just too fast for that task ☺ Command was:
for x in *.mp4; do ffmpeg -i "$x" -vn -sn -c:a copy ./"${x%.mp4}.wma"; done
So basically just
Hi Chris,
>Did you mean to include, for example:
>
> 363 License: Apache-2.0
> 364 Copyright [] [name of copyright owner]
>
>in d/copyright? (Same with the BSD-3-clause section)
I see what you mean. This is a part from the previous package
I did not change, and I guess the previous packager
Hi Fabian,
> I have problems parsing the last sentence in the package description for
> fluidr3mono-gm-soundfont. I am sure you dodn't mean a "slow footprint" and
oops, indeed not. That’s what I get for doing this late in
the day while being distracted by coworkers… ;)
> Let me suggest the
On Tue, 10 Oct 2017, Fabian Greffrath wrote:
> Hi again,
same,
> Am Dienstag, den 10.10.2017, 17:41 +0200 schrieb Thorsten Glaser:
> > What if they decide to stop shipping it?
>
> then we would proceed as we did for the previous soundfont they
> provided, i.e. timgm6mb-s
tags 871920 + pending
thanks
Hi Fabian,
> If upstream finds a way to further improve the soundfont and decides to
> ship a modified version in the next release, I am fine with that.
>
> The actual file format, I believe, can be considered stable, though. It
> has already been adopted by other
Hi Fabian,
> in the SF3 format that musescore introduced. It is thus appropriate to
> split out the FluidR3Mono_GM.sf3 sound font that comes bundled with
> musescore into its own package, install it into /usr/share/sounds/sf3/
as far as I’m informed, the soundfont is not an “API” of MuseScore,
Hi Fabian,
>if you had to go through NEW anyway, why didn't you consider to
I think you’re confused ;-)
This is backports-NEW, not unstable-NEW. I uploaded 2.1 to
stretch-backports as discussed in the MuseScore IRC channel,
and tvaz agreed I can comaintain this.
>separate the SF3 soundfont out
Lucas Nussbaum dixit:
>During a rebuild of all packages in sid, your package failed to build on
>amd64.
>
>Relevant part (hopefully):
>> make[4]: *** No rule to make target 'all.h', needed by
>> 'thirdparty/singleapp/src/CMakeFiles/qtsingleapp_autogen'. Stop.
Yes, it is, thanks. I fought with
Source: gsequencer
Severity: normal
Hi,
please update the Suggests so it still works after removal
of the transitional package — the old soundfont was renamed.
Thanks!
-- System Information:
Debian Release: buster/sid
APT prefers unreleased
APT policy: (500, 'unreleased'), (500,
Package: vlc-plugin-fluidsynth
Severity: normal
Hi,
please update the dependency so it still works after removal
of the transitional package — the old soundfont was renamed.
Thanks!
-- System Information:
Debian Release: buster/sid
APT prefers unreleased
APT policy: (500, 'unreleased'),
Source: musescore
Severity: normal
Hi,
as I already pointed out to tvaz in IRC (no idea if Toby is in IRC):
MuseScore 2.1 got released recently, and having it in experimental
would be great (not in unstable due to the freeze), especially as
they managed to make the data format compatible in both
Package: musescore
Version: 2.0.3+dfsg1-2
Severity: normal
MuseScore recently creates a directory ~/MuseScore2 with
a subdirectory Soundfonts. All other MuseScore data is
in ~/.MuseScore2/ instead.
-- System Information:
Debian Release: stretch/sid
APT prefers buildd-unstable
APT policy:
On Sun, 1 May 2016, Forrest Cahoon wrote:
> When playing back music inside of MuseScore, the volume is really low.
Just hit F11 (play panel) then raise it. I think this is an
upstream default, to not shock people close by, as playback
is also enabled during note input and note selection.
bye,
Daniel Schepler dixit:
>Sorry about that, I did in fact have to do manual builds for the
>reason mentioned (and it looks like essentially the same situation
Ah okay. I do them occasionally to, but…
>still exists on hppa and sparc64). I thought the build system would
>automatically separate out
Package: libavutil55
Version: 7:3.1.3-1+b3
Severity: normal
[…]
Unpacking dput (0.10.3) over (0.9.6.4) ...
Preparing to unpack .../08-libavutil55_7%3a3.1.3-1+b3_i386.deb ...
De-configuring libavutil55:x32 (7:3.1.3-1) ...
Unpacking libavutil55:i386 (7:3.1.3-1+b3) over (7:3.1.3-1) ...
Preparing to
James Cowgill dixit:
>Woops I think that was my fault. It should be fixed in 2.0.3+dfsg1-2.
For what’s worth, 2.0.3+dfsg1-2 works fine on my amd64 laptop
in a quick test.
Thanks,
//mirabilos
--
cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten
die nicht noch 3 Jahre warten
Fabian Greffrath dixit:
>Ah, whatever. It compiled fine and so I uploaded it. So users can
Looks like build-arch/binary-arch is broken.
bye,
//mirabilos (no, I probably wouldn’t have caught that either)
--
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to
Fabian Greffrath dixit:
>I could do a team upload of the current state in GIT this evening.
Thanks!
>Could you confirm this is fine for uploading as it is now?
I’ll compile and test it now (modulo time needed for cooking,
eating, etc). and mail back.
bye,
//mirabilos
--
„Cool,
Hi everyone,
the version in the packaging repository allegedly fixes the
problem with the new Qt version. If it works as-is, can an
NMU be done to get people able to dist-upgrade their sid
systems at least, even if the version in the packaging git
is UNRELEASED?
I’m considering building it as
forcemerge 824956 830715
thanks
Will there be anything done about it soon, please?
Thanks,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer:
Dear maintainer,
can we please have this fixed? This is keeping my sid system rioting.
Thanks,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Package: musescore
Version: 2.0.2+dfsg-2
Severity: normal
tg@leee:~ $ musescore
QXcbConnection: Failed to initialize XRandr
Qt: XKEYBOARD extension not present on the X server.
initScoreFonts 0x9a75008
init Help from:
cannot setup data
-maintainer upload.
+ * New patch to disable unused CPU detection
+
+ -- Thorsten Glaser t.gla...@tarent.de Fri, 28 Aug 2015 10:37:14 +0200
+
mjpegtools (1:2.1.0+debian-3) unstable; urgency=medium
[ Alessio Treglia ]
diff -Nru mjpegtools-2.1.0+debian/debian/patches/18_no-simd.patch mjpegtools
x32 patch (Closes: #778777)
+
+ -- Thorsten Glaser t.gla...@tarent.de Wed, 26 Aug 2015 15:14:07 +0200
+
libffado (2.2.1-2) unstable; urgency=medium
* Team upload.
diff -Nru libffado-2.2.1/debian/patches/series libffado-2.2.1/debian/patches/series
--- libffado-2.2.1/debian/patches/series 2014
On Mon, 27 Jul 2015, Miguel A. Colón Vélez wrote:
I pushed a commit to git which changes /etc/mplayer/mplayer.conf in x32 from
ao=pulse,alsa,sdl:aalib
to
ao=pulse,alsa,oss,sdl:aalib
Does this helps?
Thanks, I can confirm that this helps.
bye,
//mirabilos
--
tarent solutions GmbH
Hi everyone,
I just installed mplayer on my Debian/x32 desktop and can
confirm it’s working fine. Thanks a lot for bringing it back!
Some observations:
• the default -ao alsa does not work because it uses an ioctl
that appears to be broken on x32 (and possibly some MIPS
variants), as ioctls
:17:18.0 +0200
@@ -1,3 +1,10 @@
+libass (0.12.3-1+x32.1) unreleased; urgency=medium
+
+ * Non-maintainer upload.
+ * Do not depend on yasm on x32 to disable asm
+
+ -- Thorsten Glaser t...@mirbsd.de Mon, 27 Jul 2015 09:16:57 +0200
+
libass (0.12.3-1) unstable; urgency=medium
* New
Sebastian Ramacher dixit:
If you want to port the asm code to x32, please submit your work upstream. I
don't intend to carry patches for the asm code in a package where the asm code
changes a lot with every release:
OK, completely understandable.
But, for now, just getting x265 compiled on x32
Hi *,
using build profiles breaks debian-ports architectures, all of them:
http://buildd.debian-ports.org/status/package.php?p=x264
│Dependency installability problem for [33]x264 on alpha, hppa, m68k, sh4,
sparc64 and x32:
│
│x264 build-depends on missing:
│- empty-dependency-after-parsing
On Fri, 17 Jul 2015, John Paul Adrian Glaubitz wrote:
On 07/17/2015 09:31 AM, Thorsten Glaser wrote:
using build profiles breaks debian-ports architectures, all of them:
What exactly is a build profile in this context?
Build-Depends: […] libgpac-dev (= ⌦0.5.0+svn4288~),⌫ ▶0.5.0+svn4288
On Fri, 29 Aug 2014, Adam Borowski wrote:
Hi! I'm afraid your package fails to build on x32, and blocks a load of
stuff because of deep Build-Dependency chains.
Here's a fix. I did not bother porting this code, just ripped the whole
Hi *, I just built gavl with Adam’s fix in order to get
+0200
+++ libav-11.4/debian/changelog 2015-07-13 14:29:56.0 +0200
@@ -1,3 +1,15 @@
+libav (6:11.4-2+x32.1) unreleased; urgency=high
+
+ [ Thorsten Glaser ]
+ * Non-maintainer upload.
+ * (Closes: #760433)
+
+ [ Daniel Schepler ]
+ * Set --arch='x32' instead of --arch='amd64' for x32
:49.0 +0200
+++ libffado-2.2.1/debian/changelog 2015-06-11 10:29:13.0 +0200
@@ -1,3 +1,10 @@
+libffado (2.2.1-2+x32.1) unreleased; urgency=medium
+
+ * Non-maintainer upload.
+ * Add x32 patch
+
+ -- Thorsten Glaser t...@mirbsd.de Thu, 11 Jun 2015 10:29:03 +0200
+
libffado (2.2.1-2
Emmanuel Bourg dixit:
This issue only affects non arch all packages depending on antlr, I
don't think there are many of them and fixing the issue with an extra
command line parameter is trivial.
Hmm.
udd= SELECT source, version, architecture FROM sources WHERE release='sid' AND
build_depends
libx265.so.35: undefined reference to `__sync_val_compare_and_swap_8'
libx265.so.35: undefined reference to `__sync_or_and_fetch_8'
Please do not assume all architectures have 64-bit atomics.
http://buildd.debian-ports.org/status/fetch.php?pkg=x265arch=m68kver=1.4-5stamp=1421114612
bye,
Sebastian Ramacher dixit:
Please do not assume all architectures have 64-bit atomics.
This is fixed upstream and will be included in the 1.5 release.
Cool, thanks!
bye,
//mirabilos
--
This space for rent.
___
pkg-multimedia-maintainers mailing
On Fri, 2 Jan 2015, Emmanuel Bourg wrote:
Le 02/01/2015 10:23, Thorsten Glaser a écrit :
Hm, so what can we do here? Increase the timeout in antlr3 for
“slow” platforms? (Could it look at /proc/cpuinfo or something?
Except, that file is platform-specific… so a list of known to
be slow
Bálint Réczey dixit:
Not exactly a standalone test, but XBMC uses libpostproc. You can
Yeah, but unfortunately, that doesn’t help; xbmc is so far up in
the A/V chain that it has never even be built.
I’m going from low to high…
bye,
//mirabilos
--
“ah that reminds me, thanks for the stellar
Hi *,
please see http://article.gmane.org/gmane.comp.video.ffmpeg.devel/182554
for a patch I forwarded upstream, which allows us to build libpostproc
on Debian/x32.
As I said there, we’ll need to run-time test the built package, but at
least we got strigi ⇒ subversion ⇒ git building again (which
Andreas Cadhalpun wrote:
* Do you intend to replace Libav by FFmpeg in Debian?
No, there is no need to replace anything as long as it is maintained.
Currently the main goal is to give multimedia maintainers a choice
between the two sets of libraries to link against, and our users
Debian Bug Tracking System dixit:
This is an automatic notification regarding your Bug report
which was filed against the src:mplayer package:
#728772: mplayer: FTBFS: The architecture of your CPU (UNKNOWN) is not
supported
It has been closed by Debian FTP Masters
Jaromír Mikeš dixit:
Sebastian tried reproduce unsuccessfully this issue on a mips porterbox.
Any advice what more we do for fixing this problem?
No idea offhand but this might have to do with timing granularity
and/or floating point precision.
If you can give me freestanding test code I can
Source: radium-compressor
Version: 0.5.1-2
Severity: serious
Justification: FTBFS
https://buildd.debian.org/status/package.php?p=radium-compressorsuite=sid
audio/typepunning.h: In function 'float pun_int_to_float(int)':
Source: mixxx
Version: 1.10.1~dfsg0-1
Severity: important
Justification: fails to build from source (but built successfully in the past)
Hi,
your package fails to build for mysterious reasons.
Please see the attached build log.
-- System Information:
Debian Release: 7.0
APT prefers unreleased
IOhannes zmölnig dixit:
Well, your puredata is from before stable... With the current build
depends pd-zexy can be built in stable.
as a matter of fact, i'm not entirely sure about this.
Mh. I’m just building to catch up, m68k had five thousand and then
some packages in Needs-Build one month
Hi,
pd-zexy has alternative Build-Depends, however, they don’t work:
[…]
pbuilder-satisfydepends-dummy : Depends: puredata-core which is a virtual
package. or
puredata ( 0.43) but it is not going
to be installed.
The following actions will resolve
Felipe Sateler dixit:
(CCing you because I don't know if you are suscribed)
I’m not, thanks.
Well, your puredata is from before stable... With the current build
depends pd-zexy can be built in stable.
Hmh. Strictly speaking, you need to version the B-D then.
I'm not sure complicating the
Debian Bug Tracking System dixit:
Their explanation is attached below along with your original report.
This is a known problem with ia32-libs. Don't use it, use multiarch
Hm, this doesn’t work for stuff that directly depends on ia32-libs.
But I guess it would be best for ia32-libs to use an
From: Debian Ports Archive Maintainer ftpmas...@debian-ports.org
Message-ID: e1swehx-0007to...@leda.debian.net
X-Spam-Status: No, hits=0.00 required=0.90
To: Thorsten Glaser t...@mirbsd.de
Date: Tue, 31 Jul 2012 15:50:05 +
Subject: libav_0.8.3-5_m68k.changes ACCEPTED
Maintainer: Thorsten
Package: libjack-jackd2-0
Severity: important
Justification: release goal Multi-Arch
Hi,
libjack-jackd2-0 conflicts with libjack0, which is a bit
unfortunate, as some things depend on either; waldi suggested
to either take over the binary package if it’s the same lib,
or use a different library
Jonas Smedegaard dixit:
gstreamer0.10-plugins-good favors libjack-jackd2-0 but is also satisfied
with libjack0.
Hrm. Then, libjack0 is not M-A yet, I guess, from the symptoms.
bye,
//mirabilos
--
13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good
guy. But he's always
Alessio Treglia dixit:
Ciao Thorsten!
How are you mate? I hope you're doing well.
I’m well, thanks, hope you too.
On Sat, Jun 23, 2012 at 4:58 PM, Thorsten Glaser t...@mirbsd.de wrote:
Ciao Alessio ;-) and greetings from your favourite croatian restaurant ☺
Ohh jealousy here, the best soups
Alessio Treglia dixit:
Hi all,
Ciao Alessio ;-) and greetings from your favourite croatian restaurant ☺
good idea, Fabian!
I also found the ideas and thread upon which I happened by accident
intriguing but the official implementation scary (considering I write
a shell, not surprising) and did
Fabian Greffrath dixit:
Yep, from the next upload on it is.
Actually, not even that is needed. I just took the current git HEAD,
versioned it lower than the current sid package, dropped all the
unnecessary B-D for bootstrapping from debian/control, and will
upload that to debian-ports.org
Reinhard Tartler dixit:
AFAIUI, the yasm package should be available on any architecture. You
can build libav without it, but you'll miss a number of important
architecture specific optimizations. For m86k, I doubt that there are
Yes, it’s installable – but a quick grep shows it’s only used
in
Fabian Greffrath dixit:
Great, so a bootstrap libav should be decently easy.
Yep, from the next upload on it is.
Ok, thanks a lot. I’m still working on other packages like pygtk,
so no need to hurry for me.
bye,
//mirabilos
--
FWIW, I'm quite impressed with mksh interactively. I thought it
Fabian Greffrath dixit:
and friends the OP meant library packages built from libav sources in
general.
Yes.
Thorsten, that's three circular build-dependencies. Which one is the fourth
one
that you mentioned in your report?
frei0r, via some corners, too.
Anyway, all of these codecs are
Fabian Greffrath dixit:
Am 19.06.2012 12:35, schrieb Jonas Smedegaard:
What would be even better is to add a hint to control file which exact
packages can be skipped to generate a crippled-but-usable-for-rebuild
package. I forgot what that hint is called or its syntax (even if I was
at the
Hi,
m68k currently has no libpostproc-dev and friends, built from src:libav.
How do you recommend to bootstrap this, considering several (at least
four) build dependencies of libav, all codecs or something like that,
build-depend on libav’s binaries again? Can libav be built without any
of those
Source: jack-audio-connection-kit
Version: 0.121.0+svn4538-3
Severity: minor
Tags: upstream
On m68k, I get these warnings during compilation:
../config/cpu/generic/atomicity.h:23:2: warning: #warning stub atomicity
functions are not atomic on this platform [-Wcpp]
However, there's a
75 matches
Mail list logo
