freetuxtv 0.6.6~dfsg1-1 is marked for autoremoval from testing on 2015-06-29
It is affected by these RC bugs:
787351: freetuxtv: [RC][cc-by-nc-sa] Please clarify license of a few svg files
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-main
Source: laditools
Version: 1.0.1-2
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs vte3-removal
Hi,
We plan to remove vte3 package from archive soon.
Your package laditools declares a build-dependency on libvte-2.90-dev
or depends on either gir1.2-vte-2.
Your message dated Sun, 07 Jun 2015 22:21:25 +
with message-id
and subject line Bug#763885: fixed in isrcsubmit 2.0.1-1
has caused the Debian Bug report #763885,
regarding isrcsubmit: documenting the Recommends
to be marked as done.
This means that you claim that the problem has been dealt wi
binary:linuxptp is NEW.
source:linuxptp is NEW.
Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid), so please be patient.
Packages are routinely processe
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Sun, 07 Jun 2015 23:46:29 +0200
Source: isrcsubmit
Binary: isrcsubmit
Architecture: source all
Version: 2.0.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Multimedia Maintainers
Changed-By: Sebastian Ra
isrcsubmit_2.0.1-1_amd64.changes uploaded successfully to localhost
along with the files:
isrcsubmit_2.0.1-1.dsc
isrcsubmit_2.0.1.orig.tar.gz
isrcsubmit_2.0.1-1.debian.tar.xz
isrcsubmit_2.0.1-1_all.deb
Greetings,
Your Debian queue daemon (running on host franck.debian.org)
__
linuxptp_1.5-1_amd64.changes uploaded successfully to localhost
along with the files:
linuxptp_1.5-1.dsc
linuxptp_1.5.orig.tar.gz
linuxptp_1.5-1.debian.tar.xz
linuxptp_1.5-1_amd64.deb
Greetings,
Your Debian queue daemon (running on host franck.debian.org)
On 02/17/2015 01:22 PM, Tino Mettler wrote:
> I CCd the debian-multimedia list on Alioth. However, the archive seems
> to contain only autogenerated mails and spam, so I'm not sure if someone
> reads this list.
Uploaded to unstable.
thanks for your work to make Debian a better place.
gfmdsar
IOha
On Sat, Jun 6, 2015 at 3:05 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> Hi Reinhard,
>
> On 06.06.2015 20:30, Reinhard Tartler wrote:
>> On Sat, Jun 6, 2015 at 1:51 PM, Bálint Réczey
wrote:
The problem is that Debian users must be allowed to redistribute it,
but as
Processing commands for cont...@bugs.debian.org:
> tags 788002 - moreinfo
Bug #788002 [easytag] easytag: crashes when opening a directory containing an
mp3 with a long comment
Removed tag(s) moreinfo.
> notfound 788002 1:2.2.6-dmo1
Bug #788002 [easytag] easytag: crashes when opening a directory c
> Please can you try the version of easytag from the Debian archives
> rather than the one from deb-multimedia.org. Running this should install
> it:
> apt-get install easytag=2.2.6-1
>
> If you can, try 2.3.7-1 from experimental too. I'll have a better look
> at this bug in a few days - I have l
Control: tags -1 moreinfo
On Sun, 2015-06-07 at 12:15 -0400, Anne C. Hanna wrote:
> Package: easytag
> Version: 1:2.2.6-dmo1
> everity: normal
>
> When I open a directory containing an mp3 with a long comment, easytag crashes
> with the following message:
Please can you try the version of easyta
Processing control commands:
> tags -1 moreinfo
Bug #788002 [easytag] easytag: crashes when opening a directory containing an
mp3 with a long comment
Added tag(s) moreinfo.
--
788002: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788002
Debian Bug Tracking System
Contact ow...@bugs.debian.or
Hi Bálint,
On 07.06.2015 19:17, Bálint Réczey wrote:
> 2015-06-07 15:24 GMT+02:00 Andreas Cadhalpun
> :
>> Hi Fabian,
>>
>> On 07.06.2015 14:39, Fabian Greffrath wrote:
>>> Am Samstag, den 06.06.2015, 21:29 +0200 schrieb Andreas Cadhalpun:
Maybe we could even find a reasonable way to impleme
Apologies, I need to make a correction to the initial bug submission. I forgot
an important step in the process of causing the crash.
The mp3 I linked to will not cause the crash by itself. Rather, it is necessary
to perform an additional step of replacing the carriage returns in the id3
comment
Hi Andreas,
2015-06-07 15:24 GMT+02:00 Andreas Cadhalpun :
> Hi Fabian,
>
> On 07.06.2015 14:39, Fabian Greffrath wrote:
>> Am Samstag, den 06.06.2015, 21:29 +0200 schrieb Andreas Cadhalpun:
>>> Maybe we could even find a reasonable way to implement this in a dh7-style
>>> debian/rules file withou
Package: easytag
Version: 1:2.2.6-dmo1
everity: normal
When I open a directory containing an mp3 with a long comment, easytag crashes
with the following message:
(easytag:20858): Gdk-ERROR **: The program 'easytag' received an X Window System
error.
This probably reflects a bug in the pr
Hi Bálint,
On 07.06.2015 15:36, Bálint Réczey wrote:
> 2015-06-06 21:29 GMT+02:00 Andreas Cadhalpun
> :
>> Maybe, but I don't really look forward to more legal discussions.
>> (One reason to avoid the libavcodec-extra flavor.)
>> Would you be willing to ask debian-legal for clarification?
> I did
Hi Andreas,
2015-06-06 21:29 GMT+02:00 Andreas Cadhalpun :
> Hi Bálint,
>
> On 06.06.2015 21:00, Bálint Réczey wrote:
>> 2015-06-06 20:10 GMT+02:00 Andreas Cadhalpun
>> :
>>> That's not how I interpret DFSG §1 [1]:
>>> "1. Free Redistribution
>>> The license of a Debian component may not restrict
Hi Fabian,
On 07.06.2015 14:39, Fabian Greffrath wrote:
> Am Samstag, den 06.06.2015, 21:29 +0200 schrieb Andreas Cadhalpun:
>> Maybe we could even find a reasonable way to implement this in a dh7-style
>> debian/rules file without doubling the build-time.
>
> yes, most probably. I do strongly b
Hi Bernhard,
Am Sonntag, den 07.06.2015, 14:36 +0200 schrieb Bernhard Übelacker:
> your patch fixes the issue.
\o/
> But I fear by using static we potentially introduce a race condition,
> if there are any applications encoding in two threads?
I see, maybe we could add a "security net" there (
Hello Fabian,
your patch fixes the issue.
But I fear by using static we potentially introduce a race condition,
if there are any applications encoding in two threads?
(May I ask if there are any reasons against "__attribute__((aligned(0x20)))"?)
Kind regards,
Bernhard
I used following to build
Hi Andreas,
Am Samstag, den 06.06.2015, 21:29 +0200 schrieb Andreas Cadhalpun:
> Maybe we could even find a reasonable way to implement this in a dh7-style
> debian/rules file without doubling the build-time.
yes, most probably. I do strongly believe that it is not necessary to
clean the source
Hi Reinhard,
Am Mittwoch, den 03.06.2015, 20:32 -0400 schrieb Reinhard Tartler:
> I think the statistics indicate that the situation is much worse than
> I expected. Please keep in mind that because of the daily merges, all
> commits that are made in Libav also appear in FFmpeg, but not the
> oth
Hi Bernhard et al.,
Am Samstag, den 06.06.2015, 14:59 +0200 schrieb Bernhard Übelacker:
> Hello Fabian,
> after some more searching and testing here is my "opinion" on this issue:
thank you for your analysis of the issue. However, I think I have come
up with a simpler fix meanwhile: By declaring
Source: openni-sensor-pointclouds
Version: 5.1.0.41.4-1
Tags: patch
Here's a patch.
diff -N -ru openni-sensor-pointclouds-5.1.0.41.4.orig/Platform/Linux/Build/Common/CommonDefs.mak openni-sensor-pointclouds-5.1.0.41.4/Platform/Linux/Build/Common/CommonDefs.mak
--- openni-sensor-pointclouds-5.1.0.4
26 matches
Mail list logo
