Bug#1065860: fonts-cantarell: Please drop dependencies on python3-distutils

[Fabian Greffrath]

Hi Emmanuel,

Am Freitag, dem 12.07.2024 um 17:23 -0300 schrieb Emmanuel Arias:
> Please if you have any objection or you want to do any change please
> let
> me know.

no objections, please feel free to upload asap.

Thanks,

 - Fabian



signature.asc
Description: This is a digitally signed message part

Bug#1041264: fonts-recommended: depends on removed fonts-liberation2

[Fabian Greffrath]

Why the severity? The fonts-liberation2 package is now a transitional package 
which pulls in the actual fonts-liberation package. Von meinem/meiner Galaxy 
gesendet

Bug#1041264: fonts-recommended: depends on removed fonts-liberation2

[Fabian Greffrath]

Why the severity? The fonts-liberation2 package is now a transitional package 
which pulls in the actual fonts-liberation package. Von meinem/meiner Galaxy 
gesendet

Bug#1041242: libheif1: 1.16.2-1+b1 breaks displaying any pictures

[Fabian Greffrath]

Do you have the heif-gdk-pixbuf package installed? Von meinem/meiner Galaxy 
gesendet

Bug#1040360: marked as pending in openal-soft

[Fabian Greffrath]

Control: tag -1 pending

Hello,

Bug #1040360 in openal-soft reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/openal-soft/-/commit/cb8855883f5b91dc157fd81dd9c7997d333aacbb


Bump versioned Breaks+Replaces for openal-info

Thanks Helmut Grohne (Closes: #1040360)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1040360

Bug#694320: [gsfonts] Fonts include copyrighted adobe fragment all rights reserved

[Fabian Greffrath]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

unblock 694320 by 694308

The fonts files in fonts-urw-core35 are not built by fontforge anymore.

 - Fabian

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAmMUfacACgkQy+qOlwzN
Wd9hghAA0ZNlg3JqcZYSOI6XRWCSz22Q8hYKpFdqzXNSkY0O/aA9fFIPN2OC/p2b
FIBWEgjZZ0o7aa060fu0hfYTajjQly9vRxZdmynYdxcISjmJ85qyVrkmYY0sMrWT
yMpakN52mXK/E5lbwFdI0LNk6OZ9VKcPY09lxfXKZMPKZtBDEtVdnCD+hHOJ6MQs
iF7wLB+R9Nf/E7sARv97FqprqIIkCU1pCuqmgD5/YxdcNlqYz3lDCv2IKqk53UFk
wAQjedXM+OHAvE0zeo7UmAZraufVxyOC++U6yU0zcSiJlbTEkbVZSn/WsyxXjnk1
bSLl8PBuVfpRFY+ZMNhF6M27PEMa94AiVFaT06ZIFJByoP5BHqho1tJAMIlQAkFk
ksaW7dPJz2FYDlDsC6HVVkMYg8t+cqii0vuZK9IabdQ49tF2RxYBYVhTybW+GRw8
Wc6/uW80Z+lqnrQ8l8pViMghQg1CGjShCdDL6J2DMJY4BboGM0Qd+hHONRhRStmX
SrCKgBWRZLxYds/Iw3T+2TW1pWf8EZ1ElTAXQRiIMgaeOqMvkzGidD8eKYES5/Qz
uwPyXyIQnLPrp2gMc05BC7VF47PR7SpE1E6rldqSESNxjY/PcNeVFDq8YC3ZEdPV
RYgQPBwWONma16YHy65UXycrCRIWmru3hs3v+OwnbwMHSrqhzmo=
=uJpJ
-END PGP SIGNATURE-

Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35

[Fabian Greffrath]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Samstag, dem 27.08.2022 um 19:40 +0200 schrieb Jonas Smedegaard:
> Yes, Ghostscript contains a script update-gsfonts which makes use of
> it.

I see, thank you . So, I'll keep the file.

Do you guys think I will have to post a heads-up to debian-devel for
the transition?

 - Fabian

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAmMKexQACgkQy+qOlwzN
Wd+l3xAA2hXXT0zFjuNnsyqJT9dY6eDrH0CFG8JhI21dkBBl/DBEAov8Mxdv/a7x
kZ683Vcx+5z4oa7ig4Ik7LGmTcRLdz0F023IG84a31UuWWEnt9IeWm5sFB1AugSC
OMvqOp+4VFLMTxCb1RBGKJ9nLELCeRXKDULoc/4PWHLxicTQTaT958wmq5IbxgJf
bsXHWy+u2w8X72R+h1CVPlh1KwNtL8V73PITBODSLnxWPdHZS3kHMMF0X4slBI/P
ej96A2upjnyYJF5NUwkzHAkXMBUGL/3l/AMowIm28bBhBFiVuWme5KzuXJ5gvptt
KKZ0qDNXRCDmoEjSRqMFJWC8L8OSs4Gw3ajq6Fn/tojpvGl4mz3N7qdMO8LETD6J
q0EGa+UW32HCz/WUe1lRvSgrHyZe7igGmhdbnNZgT8XHpQG8DKaPoMWMt7MjxIIb
p+8yU58tIfg27SQfEsEmiZ3gXMp/WYkVnCAbJAqxLejohA5XB2Hfn5XDNhZHibAM
iP/KcPUyUlBr59/x8I1++Z4BJrVwHsuwpCAbWMdIXzVqE8Ufe00piG1z68/8xw3k
tnztmEIFgHfkiP/K+D1EdeyA9QJlTFVc6AohJC4JzTiTsk53Ej6C27g4k6eusOXw
+IFcgHLCcn+AsMUk38jzQP5K/BT44nTOFZwCzX7nMng7A7bOEx0=
=/rte
-END PGP SIGNATURE-

Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35

[Fabian Greffrath]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

@Jonas: Is the file /etc/ghostscript/fontmap.d/10fonts-urw-base35.conf
[1] even necessary now that the font files are directly symlinked in
the libgs9-common package?

Cheers,

 - Fabian

[1] 
https://salsa.debian.org/fonts-team/fonts-urw-base35/-/blob/master/debian/10fonts-urw-base35.conf

Am Samstag, dem 27.08.2022 um 14:12 +0200 schrieb Fabian Greffrath:
> Am Freitag, dem 26.08.2022 um 09:52 +0200 schrieb Roland Rosenfeld:
> > Just go for it.
> 
> I have just uploaded fonts-urw-base35_20200910-2 to experimental
> which
> takes over the gsfonts and gsfonts-x11 packages. So, if you guys
> could
> check if the transition works out for you as expected, that'd be
> appreciated.
> 
> Thanks!
> 
>  - Fabian
> 

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAmMKS3gACgkQy+qOlwzN
Wd/OEw/+LaO8ZtZFtXNTRCbr0pybxPhIMpqOL16b1vhnT31XwQvGAzuRhuNF2/9g
pL2mNe01HKE5FldwuH9+XawdfYnH0P9dMRzm1CXZAwdrVjefwQkhISfFgta+zwG9
A744jNnC7zk/ChQRapmrRKilUjK7MqA3GhC+0jr7I6NF7qNEsi+EUpMDSn5KeqXc
d8l2dbmvSFYaajVxTvnNkq3y7feLCyDKIsJKFbVD+FpBs/Om4MRJDBGuc9FKOjTS
4+tsQaWi6FFbdVu4NbEGhcYi3u6b3MWUAfo4MgAQuiE3fpv1rRSE4Hw6aRP7YSwZ
6YKVVURiXbNDdmYjP3lS4yaQ+KWvvIjezUcTuD8RAPgcqUic70+UFU7ytNLR/yXm
lP4L0aQuALQD3QFtWh+wFS3Kk/o98afGoqd8gxkDsoUAkwAejHzLAPa2H3j2dpRf
4fgRCVCi4cFroILW/gB7S2ytqvhxGaVoBTYm0XcaTe1KsOt/P1n4CUzf2hVEwFOI
UCOet2tzGe34HEvYxFyJoa9nLZu2IE/Qy2BYLNJMBWBZLgi5LHiYfVdh1XRaEx1p
lpn2pf+l4ETHwH3/G7aekf1Ew2A6xvIKuja8lSNKsGoQ/jXViIqmPWiCVZGzDA7L
oU476E1e3TNhyPIu2G7YH59m7pv8h4LHr5QIGeKRjOUdeCIFkMY=
=U7BW
-END PGP SIGNATURE-

Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35

[Fabian Greffrath]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Freitag, dem 26.08.2022 um 09:52 +0200 schrieb Roland Rosenfeld:
> Just go for it.

I have just uploaded fonts-urw-base35_20200910-2 to experimental which
takes over the gsfonts and gsfonts-x11 packages. So, if you guys could
check if the transition works out for you as expected, that'd be
appreciated.

Thanks!

 - Fabian

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAmMKCiYACgkQy+qOlwzN
Wd/wnhAAwwgzhqlgOuioHah1qrqaNeJZIasP1oQ7uPFq6wKDkKSGSMP4pvR2rNSp
GHtdh+PzCij/5ADfEl8wEB0b3kkVmKhPPH8uMmUH4TZW+YxBypem6fsLAP7P0cSH
kUeFMqjmQFQtuB1rcjT2UXQS5daG/UYE2f5RMxOsh5zxx5Wja4NAYUdOm2qdrLQG
73zczLWK3rX7+jJh7nEn48IjC8LmRAOr77tOnazVhWMjGIuEQqJ+klKaRFz8jY0R
rb1LvWves+kpwMmNW8G+GoTrUqhArHqngAWszq6eW/A+VeBM9ZZdDTrmwVOhCoeO
csh+y11e2QIlzJsZ8fp3KI/8UDfOBD5RmzlfvTVfYc+V/Zs0eh6DXhcrfYFJIeGZ
TAiRm4eEKlqzZF2kdwn5mQsrmgVoSC8Ox/qLgVS9FCwVDCqjYQIb9mTDnS+td5gS
+gvbZOruEdQd1pcRhcA+z3Dvi4c9DCsR3ixre8f2iWmhw07HFT7IGBGqy7+kz8nL
JA/uSzrMTDg7Kyzsx0GAVOmhxABFur6Cy23iRW4btsJGij7GdMggRIBjIfs1CsMD
91nV96GsPbLXM/HUrr7XBmTrDFaMTdtgmyp0zbDVRFfDas8mFBt3BDBc3JofLVv3
RALcjqc3AdfpJZtlELV/SYR1Y9RXI+WzafRDN87Jrg8VxRiqy50=
=aC/0
-END PGP SIGNATURE-

Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35

[Fabian Greffrath]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 28 Jul 2022 10:21:17 +0200 Fabian Greffrath  
wrote:
> > Maybe now is the time?
> Indeed my plan is to tackle this issue in about four weeks.

I currently despair of the format of the fonts.scale and fonts.alias
files that are provided by the gsfonts-x11 package and that I somehow
need to adjust to the new font file and family names in the course of
replacing the gsfonts-x11 package (which will get disfunct as soon as
fonts-urw-base35 replaces and provides gsfonts).

 - Fabian

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAmMHHsYACgkQy+qOlwzN
Wd/NnRAAk1flQ4W7nXO/IDxCIL/kLxY7QbVdiwU3J5dwPnlCLclpIb10PoNCmwEo
Zb3OW/fvT7tFuDQpiCZJU4XiT92vqQjMqcCRtInpZaKlzuu1rc5+13qeqYlht41E
KuAHKhjvRbXUtBLodYKutVYw9iZKbFeHblx5tbpyBbvQcJUn89kF5vmAKUqAZ9Gr
gKQTH8iniREayC4PV6TuLFQwIZdvKS5XYnSkhqfNyYpLwHZ3IoREsaQcBPvI/cAO
26BjI9AmRyPL11DNi2G0KAJm5ieyhvlE3BFo6UN5f3Mqc4SO/8fhdMTxpAkm0O+s
l6C/sPEnRL3/XT4DaYWxPo05Dn0Vqb1MMnrReL/qDZPlywPk4AT6fiTbxvxEJC+Y
bvKdjfsEZqoAYYybxiyDZG3kOc9qupmTHbrW/+7oxzhLxJ4Z8W566ABFucKDgdSA
89VmpgdABPW981oViF74yTjkGC71XuRr1c1YhcIGFePUk5VAd2AlaNkAoxllRn3e
d705WrRQiJ7dCueHKizrXuiqAl7iJ2xaJDDv/Tqtlf1JIqx0jj2+vmsiDVasjSY8
BE40uRcKhqtbgDlzgUQQ8ctCPHV+udBWtqisJ16G7fqEIL3lra73VQrUSh8JO3k6
GSGNoaSnJJ4nhrF5CxuPGKo3vjNtgcPWzubuDDFicP5tRziHf6M=
=YtHR
-END PGP SIGNATURE-

Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35

[Fabian Greffrath]

> Maybe now is the time?Indeed my plan is to tackle this issue in about four 
> weeks.  - Fabian Von meinem/meiner Galaxy gesendet
 Ursprüngliche Nachricht Von: Chris Hofstaedtler 
 Datum: 28.07.22  01:02  (GMT+01:00) An: Fabian Greffrath 
, 977...@bugs.debian.org Cc: Jonas Smedegaard 
, Paul Gevers  Betreff: Re: Bug#977765: 
[Pkg-fonts-devel] Bug#977765: src:gsfonts: package
  superseded by fonts-urw-base35 * Fabian Greffrath  
[220727 23:01]:[..]> My stance on this: In theory it should be technically 
possible to replace> the gsfonts (and gsfonts-x11) package with 
fonts-urw-base35 and I believe> this would be the right step, given that the 
latter font set is actively> maintained and extended - and actually used by 
ghostscript both upstream and> in Debian. And as a matter of fact, I have 
prepared this transition since I> uploaded the fonts-urw-base35 package for the 
first time. So, why haven't I> triggered this transition yet?[..]> So, to 
summarize: Yes, I think we should replace gsfonts+gsfonts-x11 with> 
fonts-urw-base35 at a given time and this transition is already prepared for> 
the most part. But I don't see this as a pressing issue right now, given the> 
lack of real-world issues this apparently causes, given the lack of bug> 
reports we received during the past 5 years - and given how late in the> 
release cycle we are to introduce a potentially disruptive change like 
this.Maybe now is the time?Chris

Bug#1008424: marked as pending in flac

[Fabian Greffrath]

Control: tag -1 pending

Hello,

Bug #1008424 in flac reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/multimedia-team/flac/-/commit/4b4c810ca7d15b436c67f458687904a2b68dc9b5


Merge branch 'fix_seeking' into 'master'

Add upstream patch to fix seeking bug (closes: #1008424)

See merge request multimedia-team/flac!2


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1008424

Bug#1008424: marked as pending in flac

[Fabian Greffrath]

Control: tag -1 pending

Hello,

Bug #1008424 in flac reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/multimedia-team/flac/-/commit/b138df45a8dda1fc569e4f3ebccda8e6da724111


Add upstream patch to fix seeking bug (closes: #1008424)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1008424

Bug#1001791: fonts-cantarell: Renders system hardly usable

[Fabian Greffrath]

Hi,

Am 16.12.2021 11:22, schrieb G. Heine:
this version displays only letters a-z correctly thus making the system 
hardly
usable, unless you change to a different font. The problem is best 
shown with

the attached screen-shot.


this seems to be a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788791

Have you restarted your desktop session after the fonts have been 
upgraded?


 - Fabian

Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35

[Fabian Greffrath]

Hi all,

Am 07.02.2021 22:51, schrieb Jonas Smedegaard:

Added now explicitly.


well, thanks. I can't wait to participate in this discussion.

My stance on this: In theory it should be technically possible to 
replace the gsfonts (and gsfonts-x11) package with fonts-urw-base35 and 
I believe this would be the right step, given that the latter font set 
is actively maintained and extended - and actually used by ghostscript 
both upstream and in Debian. And as a matter of fact, I have prepared 
this transition since I uploaded the fonts-urw-base35 package for the 
first time. So, why haven't I triggered this transition yet?


First, we have packaged the urwcyr fork in the gsfonts package which has 
added cyrillic glyphs to most (all?) fonts and I have been told that we 
set parts of official Debian documentation with these fonts, and this 
includes translations into languages which depend on the presence of 
cyrillic glyphs. Granted, nowadays there are dozens of alternative fonts 
available in Debian that provide these glyphs. Anyway, back then when I 
proposed the transition I have been told to please wait. I guess it was 
late in a release cycle...


Second, I have never experienced any "name space clash" in real life. In 
my experience, fonts are either selected directly by file path or by 
means of fontconfig. And the latter has sophisticated heuristics to 
return "the right font" for a given search pattern. If it finds two 
fonts with the same name, it chooses the one with a higher version 
number or glyph count or whatever. I don't know if there is some special 
case that ghostscript can't properly handle, though.


So, to summarize: Yes, I think we should replace gsfonts+gsfonts-x11 
with fonts-urw-base35 at a given time and this transition is already 
prepared for the most part. But I don't see this as a pressing issue 
right now, given the lack of real-world issues this apparently causes, 
given the lack of bug reports we received during the past 5 years - and 
given how late in the release cycle we are to introduce a potentially 
disruptive change like this.


Cheers,

 - Fabian

PS: Also, please note that there is a third (outdated) copy of the same 
fonts available in the texlive-fonts-recommended package which the TeX 
people want to keep, though, for TeX reasons I guess.

Bug#977765: [Pkg-fonts-devel] Bug#977765: src:gsfonts: package superseded by fonts-urw-base35

[Fabian Greffrath]

Hi Jonas,

Am Sonntag, den 20.12.2020, 14:10 +0100 schrieb Jonas Smedegaard:
> This package has been superseded by fonts-urw-base35, which contains
> the
> same fonts but a newer release and using policy-compliant package
> name.

indeed, I have prepared fonts-urw-base35 to take over both gsfonts and
gsfonts-x11 since the very beginning:

https://salsa.debian.org/fonts-team/fonts-urw-base35/-/blob/master/debian/control#L15

However, I have hesitated to do so. The reason is that we have the
urwcyr fork in the gsfonts package, and last time I checked not all
cyrillic glyphs that this fork added were also available in the urw
releases.

> Setting severity to serious, as this package is not fit for release.

Why do you think the package is not fit for release? Because it did not
have a maintainer upload for the last 10 years? It is static font data,
after all? Or because it does not follow a naming convention that isn't
even Debian policy?

Cheers,

 - Fabian



signature.asc
Description: This is a digitally signed message part

Bug#974090: [Pkg-fonts-devel] Bug#974090: fonts-gfs-artemisia breaks lcdf-typetools autopkgtest: lots of failures

[Fabian Greffrath]

Am 2020-11-09 20:58, schrieb Paul Gevers:

#   Failed test 'Testing stderr'
#   at debian/tests/cfftot1.t line 24.
#  got: 'cfftot1:
/usr/share/fonts/truetype/artemisia/GFSArtemisia.otf: No such file or
directory


This is looking for an opentype font in the truetype directory, which is 
quite probably wrong.


 - Fabian

Bug#957394: marked as pending in jumpnbump

[Fabian Greffrath]

Control: tag -1 pending

Hello,

Bug #957394 in jumpnbump reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/games-team/jumpnbump/-/commit/7a3a913370edb1e176a2bcd191cf052c28b3e337


Backport post-release patch from upstream to add future gcc default -fno-common 
and fix code (Closes: #957394).


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/957394

Bug#961336: prboom-plus FTBFS on big endian

[Fabian Greffrath]

Control: tags -1 confirmed pending fixed-upstream
Control: forwarded -1 
https://github.com/coelckers/prboom-plus/commit/29320630c9ae878e537f451f173dbf9007d6786b

Bug#961336: prboom-plus FTBFS on big endian

[Fabian Greffrath]

Hi Adrian,

Am Samstag, den 23.05.2020, 15:39 +0300 schrieb Adrian Bunk:
> cd /<>/obj-s390x-linux-gnu/data && ./rdatawad -I [...]
> /<>/obj-s390x-linux-gnu/prboom-plus.wad
> Segmentation fault
> make[3]: *** [data/CMakeFiles/prboomwad.dir/build.make:257: prboom-
> plus.wad] Error 139

are these platforms cross-built? I am asking, because one step in
building prboom-plus is to compile a helper tool called "rdatawad" and
run this to combine several graphics and sound files into a data "wad"
file needed by the engine.

 - Fabian



signature.asc
Description: This is a digitally signed message part

Bug#958646: ffmpegfs: FTBFS caused by passing custom target flags in CFLAGS

[Fabian Greffrath]

Control: reopen -1
Control: found -1 1.98-1

Bug#958075: crispy-doom: file conflict with chocolate-doom

[Fabian Greffrath]

Hi Sven,

Am 18.04.2020 07:50, schrieb Sven Joachim:

Since chocolate-doom was there first to ship the offending file, I
assume it should be removed from crispy-doom.


I'll take care of that with the next upload, thank you!

 - Fabian

Bug#946474: marked as pending in fluidsynth

[Fabian Greffrath]

Control: tag -1 pending

Hello,

Bug #946474 in fluidsynth reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/multimedia-team/fluidsynth/commit/e50669e6b61747e300842a06be86f4bb342ca626


Review debian/copyright (Closes: #946474).


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/946474

Bug#941559: marked as pending in xvidcore

[Fabian Greffrath]

Control: tag -1 pending

Hello,

Bug #941559 in xvidcore reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/multimedia-team/xvidcore/commit/57faa77ceeae42d6da6f87f654e18ae134d6b0e6


Define a standard ELF .text section in ASM code, instead of .rotext (Closes: 
#941559).


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/941559

Bug#941559: libxvidcore4: immediately crashes on amd64 since binNMU

[Fabian Greffrath]

Hi James,

Am 02.10.2019 01:45, schrieb James Cowgill:

Indeed readelf contains some non-executable program headers in
2:1.3.5-1+b1 which do not appear in 2:1.3.5-1 in buster. The
".rotext" section sounds suspicious.


indeed, the check_cpu_feature() function is defined in 
src/utils/x86_asm/cpuid.asm [1] which includes src/nasm.inc, which in 
turn declares a .rotext section [2] for any other output format than 
macho32 and macho64.


It would probably be the best patch this to simply declare a .text 
section for all output formats. The question remains, however, why this 
is an issue now but not when xvidcore_2:1.3.5-1 was uploaded?


 - Fabian

[1] 
https://sources.debian.org/src/xvidcore/2:1.3.5-1/src/utils/x86_asm/cpuid.asm/?hl=94#L94

[2] https://sources.debian.org/src/xvidcore/2:1.3.5-1/src/nasm.inc/#L177

Bug#930363: faad2: fix build with gcc-9 [patch]

[Fabian Greffrath]

Am Donnerstag, den 29.08.2019, 09:54 -0400 schrieb Hugo Lefeuvre:
> Ack, I'll NMU then. Good luck with the baby :)

Thank you! \o/

 - Fabian



signature.asc
Description: This is a digitally signed message part

Bug#930363: faad2: fix build with gcc-9 [patch]

[Fabian Greffrath]

Dear Hugo,

Am Donnerstag, den 29.08.2019, 08:04 -0400 schrieb Hugo Lefeuvre:
> Fabian (faad2 maintainer and upstream), do you want to handle this?
> Otherwise I can NMU a second time with this patch.

please go ahead with a second NMU. I am a bit short on time currently
(home alone with the 10mo baby...).

Thanks!

 - Fabian



signature.asc
Description: This is a digitally signed message part

Bug#919721: [Pkg-fonts-devel] Bug#919721: fonts-firacode: looks broken on at least kitty and hexchat

[Fabian Greffrath]

Control: severity -1 normal

Hi Antonio,

thanks for the report, but I fail to see how a change in vertical
spacing could justify grave severity for a font package.

 - Fabian



signature.asc
Description: This is a digitally signed message part

Bug#916948: [Pkg-fonts-devel] Bug#916948: fonts-hack FTBFS: Unable to execute ttfautohint on the Hack-Regular variant set

[Fabian Greffrath]

Control: severity -1 normal
Control: tags -1 +unreproducible

Am Donnerstag, den 20.12.2018, 21:38 +0200 schrieb Adrian Bunk: 
> Warning: Option `-w G' is deprecated!  Use option `-a qsq' instead
> postbuild_processing/tt-hinting/Hack-Regular-TA.txt:3:1: invalid
> glyph name (0x204)
>   uni0023 touch 0,1,2,3,18,19,20,21,22,23,24,25,26,27,28,31 x 0.25  @
> 13
>   ^
> Unable to execute ttfautohint on the Hack-Regular variant set.  Build
> canceled.
> make[2]: *** [Makefile:26: ttf] Error 1

I have just successfully rebuilt the package in a sid chroot without a
single warning.

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#916948: [Pkg-fonts-devel] Bug#916948: fonts-hack FTBFS: Unable to execute ttfautohint on the Hack-Regular variant set

[Fabian Greffrath]

Adrian Bunk wrote:
> Warning: Option `-w G' is deprecated!  Use option `-a qsq' instead
> postbuild_processing/tt-hinting/Hack-Regular-TA.txt:3:1: invalid glyph
> name (0x204)
>   uni0023 touch 0,1,2,3,18,19,20,21,22,23,24,25,26,27,28,31 x 0.25  @ 13
>   ^
> Unable to execute ttfautohint on the Hack-Regular variant set.  Build
> canceled.

Oh, but what would be the right glyph name? Maybe the fontmake maintainers
can help out here?

Cheers,

 - Fabian

Bug#887664: openal-soft: FTBFS: nothing is built

[Fabian Greffrath]

Hi,

Simon McVittie wrote:
> .PHONY: build

isn't the "clean" rule called before anything else? Couldn't we just
remove this directory in the "clean" rule?

 - Fabian

Bug#879513: lame will not run at all

[Fabian Greffrath]

Hi Klaumi,

Am Sonntag, den 22.10.2017, 15:24 +0200 schrieb Klaumi Klingsporn:
> Maybe it helps to upgrade libmp3lame0 to 3.100-2 as well?
> In this case lame should depend on this version (or above)
> of course!

the point is that in the lame 3.100-2 upload the library got a symbols
file that maps all symbols to a dependency on libmp3lame0 (>= 3.100).

So, lame 3.100-2 should have pulled in the 3.100-2 library package.
Alex, can you confirn that?

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#879513: lame will not run at all

[Fabian Greffrath]

control: tags -1 +unreproducible

Am Sonntag, den 22.10.2017, 14:01 +0100 schrieb Alex Dekker:
> Package: lame
> Version: 3.100-2

Hi Alex,

I cannot reproduce your issue.

> ii  libmp3lame0  1:3.99.5-0.1

Ahem, please update the library package as well.

Thanks,

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#876837: [Pkg-fonts-devel] Bug#876837: Bug#876837: Bug#876837: Bug#876837: Bug#876837: fonttools bug

[Fabian Greffrath]

Am Freitag, den 29.09.2017, 14:08 + schrieb Holger Levsen:
> As you will have seen, I've done this now. :)

Cool, thanks! I have tagged what I uploaded as -4 yesterday in GIT, so
we should be clean again. ;)

Cheers,

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#876837: [Pkg-fonts-devel] Bug#876837: Bug#876837: Bug#876837: Bug#876837: Bug#876837: fonttools bug

[Fabian Greffrath]

Holger Levsen wrote:
> I think you forgot a tag?

Oh, indeed. I'll push the "-4" tag when I am at home.

> ok, will do!

Thank you!

 - Fabian

Bug#876837: [Pkg-fonts-devel] Bug#876837: Bug#876837: Bug#876837: Bug#876837: fonttools bug

[Fabian Greffrath]

Am Freitag, den 29.09.2017, 00:05 + schrieb Holger Levsen:
> Sure, I'm happy to do that! Did you push everything to git?

Yes, I have pushed everything. The latest commit is my attempt to merge
both of our efforts, i.e. what *should* have become revision -4.

Please upload a new revision, I'll keep my fingers off of this package
until this happened. ;)

Cheers,

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#876837: [Pkg-fonts-devel] Bug#876837: Bug#876837: Bug#876837: fonttools bug

[Fabian Greffrath]

Am Donnerstag, den 28.09.2017, 19:37 + schrieb Holger Levsen:
> just revert my changes and apply your changes… (and then I can
> cherry-pick
> those changes of mine which you didnt do…)

I have already merged our branches and also the changelog, so it would
probably be the cleanest solution to re-upload the current state in GIT
as a new revision. :/

> thanks for your work on fonts-liberation(2)! 

Sure. ;)

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#876837: [Pkg-fonts-devel] Bug#876837: Bug#876837: fonttools bug

[Fabian Greffrath]

Am Donnerstag, den 28.09.2017, 20:23 +0200 schrieb Fabian Greffrath:
> I am on this, about to upload!

Sorry, I have uploaded this before I could realize you already changed
the packaging in GIT. And then my upload was ACCEPTED before I could
send the dcut token to cancel it. Now we have a different packaging
state in GIT than in the archive. /o\

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#876837: [Pkg-fonts-devel] Bug#876837: fonttools bug

[Fabian Greffrath]

Am Donnerstag, den 28.09.2017, 16:22 + schrieb Holger Levsen:
> I've tried to simply set PYTHON=python3 in fonts-liberation2's
> upstream
> Makefile but that just caused a syntax error as the code aint ready
> for
> python3.

I am on this, about to upload!

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#876837: [Pkg-fonts-devel] Bug#876837: fonts-liberation2 FTBFS with fonttools 3.15.1-2

[Fabian Greffrath]

Adrian Bunk wrote:
> python scripts/setisFixedPitch-fonttools.py src/LiberationMono-*.ttf
> /bin/sh: 1: python: not found
> Makefile:58: recipe for target 'ttf-dir' failed
> make[1]: *** [ttf-dir] Error 127
> make[1]: Leaving directory '/build/1st/fonts-liberation2-2.00.1'
> dh_auto_build: make -j1 returned exit code 2
> debian/rules:3: recipe for target 'build' failed
> make: *** [build] Error 2

So, I need to add an explicit B-D on python?

 - Fabia

Bug#868854: marked as pending

[Fabian Greffrath]

tag 868854 pending
thanks

Hello,

Bug #868854 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

http://anonscm.debian.org/git/pkg-multimedia/faad2.git/commit/?id=8d60f32

---
commit 8d60f326aa15111f433ca194ee5b31883160d5fd
Author: Fabian Greffrath <fab...@debian.org>
Date:   Wed Aug 2 20:47:26 2017 +0200

update debian/changelog

diff --git a/debian/changelog b/debian/changelog
index 7987cb6..9a589b3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+faad2 (2.8.1-2) unstable; urgency=medium
+
+  * Set the FAAD2_VERSION macro back to the version string,
+thanks Adrian Bunk (Closes: #868854).
++ In the next upstream release this macro will read "unknown version"
+  and an API will be provided to retrieve the actual library version
+  at run-time.
+
+ -- Fabian Greffrath <fab...@debian.org>  Wed, 02 Aug 2017 20:46:57 +0200
+
 faad2 (2.8.1-1) unstable; urgency=medium
 
   * New upstream version 2.8.1.

Bug#866378: 3dchess: 100 % CPU consumption

[Fabian Greffrath]

control: tags -1 +patch

Am Donnerstag, den 29.06.2017, 12:04 +0100 schrieb James Cowgill:
> It looks to me like the game loop has no sleeps or other waiting in
> it.
> It has probably always consumed 100% CPU.

Good catch! I have simply added a usleep(10) call in the main loop,
effectively capping the game at about 100 FPS, and it settled at around
4% CPU consumption:

--- 3dchess-0.8.1.orig/src/main.c
+++ 3dchess-0.8.1/src/main.c
@@ -201,6 +201,7 @@ DoMain3DcLoop(void)
   XtDispatchEvent();
 }
 
+usleep(10);
 } /* End game loop */
 
   return;

Cheers,

 - Fabian

signature.asc
Description: This is a digitally signed message part

Bug#861612: pixbros: level designs appear to be non-free

[Fabian Greffrath]

Markus Koschany wrote:
> graphics are completely different. Yes, the level design of pixbros
> resembles those of the other non-free games but it is not a direct copy.
> Also the gameplay is much different. I am not aware of any design
> patents for those non-free games hence I am quite sure that there is no
> risk for Debian or any breach of law.

I agree wholeheartedly! If a game should be non-free because it resembles
another, commercial game, then we'd have a huge problem in Debian (and in
free software as a whole).

 - Fabian

Bug#860654: [Pkg-fonts-devel] Bug#860654: fonts-ocr-b: FTBFS on i386: E: Build killed with signal TERM after 150 minutes of inactivity

[Fabian Greffrath]

Control: severity -1 normal
Control: block -1 by 831425

Am Mittwoch, den 19.04.2017, 09:15 +0200 schrieb Lucas Nussbaum:
> E: Build killed with signal TERM after 150 minutes of inactivity

I fail to reproduce this on amd64, so I am sure this is due to the
known issue of fontforge exporting malformed OTF files on i386.

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#860654: [Pkg-fonts-devel] Bug#860654: fonts-ocr-b: FTBFS on i386: E: Build killed with signal TERM after 150 minutes of inactivity

[Fabian Greffrath]

Am Mittwoch, den 19.04.2017, 09:15 +0200 schrieb Lucas Nussbaum:
>   RMOmsk-ocrb10efg.rmo
> > E: Build killed with signal TERM after 150 minutes of inactivity

This is the "remove overlaps" script called rmo.pe, which calls
fontforge with the following shebang line:

#!/usr/local/bin/fontforge

Is there a fontforge version installed in this location on the build
system?

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#851339: [Pkg-fonts-devel] Bug#851339: Bug#851339: fonts-firacode: package in Debian with non-Debian build dependencies

[Fabian Greffrath]

Guys, thanks for taking the time to discuss this issue with me.

Since I am the one who sponsored the 1.204-1 upload, I will also do the
next one. I will just re-upload the package with its section changed to
contrib/fonts. Is this sufficient or is there anything else needed?

Thanks for your patience!

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#851339: [Pkg-fonts-devel] Bug#851339: Bug#851339: Bug#851339: Bug#851339: Bug#851339: fonts-firacode: package in Debian with non-Debian build dependencies

[Fabian Greffrath]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I admit it's a bit hard to argue against three, but I'll try anyway. ;)

Am Mittwoch, den 18.01.2017, 01:12 + schrieb Scott Kitterman:
> DFSG #2 requires that "The program must include source
> code".  Preferred form of modification is the definition of source
> that the FTP team uses.  For Debian DFSG purposes it's not
> exclusively GPL relevant.

Is this the FTP Masters' position on this issue or your personal
opinion?

> FYI, you are mistaken that C code is always "source". C is sometimes
> generated from other forms, via transpilers or lexer generators etc.
> It can also be obfuscated C code from the real C source (cf #383465).
> [...]
> So like C, OTF can be source or not source, depending on the upstream
> project.

I find this by far the most convincing argument, although I still find
it difficult to accept that it should make a difference for Debian as a
mere downstream distributor. We provide many packages with fonts in OTF
format and while this is acepted as a proper source for some, it is not
for others because of upstream design decisions?

> It is unfortunate that the gsfonts upstream didn't ask the right
> questions before integrating these files into the project. They
> really
> should have done that. At that point in time we would have to remove
> the URW++ fonts from Debian since we would not be in compliance with
> the GPL.

Well, RMS himself told me that the Type1 format in which the fonts are
distributed is considered a proper source format. Apparently he doesn't
even care about what tools upstream used to create the fonts as long as
they are distributed in a proper source format.

> Please try to submit a git commit to Firacode upstream containing
> only
> changes to the generated files. Then you will see that this phrase
> has
> meaning in any software context, including in the world of fonts and
> Firacode in particular.

Agreed, but I don't think that this (i.e. "is it easy or even possible
to create a patch that upstream would outright accept in that form?")
should be a criterion to decide if a package is suitable for Debian
main or not (as long as it is possible to create the patch in the first
place, that is).

Cheers,

Fabian
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAliDSGYACgkQy+qOlwzN
Wd8qwxAAwWmJj0YOLdxQsBhXZh7mzC+LcvY3N04MVHPHNgkIsuAuw3LhU4pHf5xC
saninfv7e7GZ29na7i75Ug26v6FS+/3aE7Fej+np1m5pjeVAuvgtzMw4B/lKEeXb
UvoTwvLHSKVB1mrGWe4Bu1HU8mDFOn23dZyJmvDoaRxf4OkHcBtPHUkD7FZ35P70
t0GAEAnhAsAKyzFCsdEBGfdH8SGvw+UhHwhC31aGdCWv6to/CHsUd89HTmW2Ky0o
QZh/4pkHK7qnX+2Zd6C0WXDdhDVNLFHyYrZT/h8LbFYozLJROksncwIMOKmGhIrK
/pYKsqfTKshXO8X0luaQbJHCbldtyv/LbUMVmBGwr24a0+HS5rUPwM5AIhwu6MCk
qx4W5vaifunhkxr8Z6CMwBgkKzaK7MZB4BBh+D/C5XbSHcOZHf8HoE65btM8BZyd
8PIEWHZedUAt+HjYkY4RQfdV18XJHkVRiKK2VxCfTWz9bRF/y2+MmXF3/Cd0R09G
jrsxW0vsUFp3WaJXTJw3P810deSYvCJpwXAsTvzApHMvTSY9kal+xKVq9moEU34+
dvTtfV9ABf8ETooEd9FRk5R0Q+63aBoK8wU8dkzOP557UPuBeOfXqwBczi2WG4tR
1YzraE5mYf2VonXN8HanePQMC4QpmdZhV/+ds6f5AnbGu56372U=
=Qgwt
-END PGP SIGNATURE-

Bug#851339: [Pkg-fonts-devel] Bug#851339: Bug#851339: Bug#851339: Bug#851339: Bug#851339: fonts-firacode: package in Debian with non-Debian build dependencies

[Fabian Greffrath]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Oh, I just remembered I once had a short conversation with RMS about
the distribution of the ghostscript fonts in binary Type1 format albeit
being licensed under the terms of the GPL:


Date: Sun, 13 Feb 2011 14:02:32 -0500
From: Richard Stallman <r...@gnu.org>
To: Fabian Greffrath <fab...@greffrath.com>
Subject: Re: [ghostscript] opentypefont

These fonts, however, are supplied in a binary, though editable, format
called PFB. In our opinion this file format corresponds to object code
and is clearly not "the preferred form of the work for making
modifications to it."

Karl Berry is the GNU expert on fonts.  He thinks that a Type 1 font
is suitable source code.

Could you tell me how you consider it falls short?

 We sure could do the transformations
from the binary font files, but it just felt "wrong". ;)

Would the files made by this transformation be different from the
source files that the developers might release?


Date: Mon, 14 Feb 2011 14:18:57 -0500
From: Richard Stallman <r...@gnu.org>
To: Fabian Greffrath <fab...@greffrath.com>
Subject: Re: [ghostscript] opentypefont

They are binary files, so you cannot create diffs between two 
versions. That is, the advantage of the openness of the source is void.

I see your point.  That is an aid for maintenance.

At the same time, the Type 1 font contains all the information
and can be converted automatically to the textual format.
So it is a valid source format.

Thus, I think these packages are valid and free as they are.
However, distributing the ASCII source would be an improvement.
So why not add that to your packages?
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAlh+iIkACgkQy+qOlwzN
Wd+/ORAAr5M6KHbkBoUDNUkKu9KlKvC0hDJnaieJdxCUtuHH3sHGTmhAcpXbYjZo
VqqkeTkOrwiPvVs/vQcoQTyplE/TjKhLFC0w74PCUuY/dzPYm7kWmTNeyjdR/UCG
R2fsZNdLKu31/m/FEVAm7Cj3pp8o2DIRVNo75QabDJu6K4oIbVB2Okt4XE2BJJT5
nKHWYC+RthTiAUo9nlRJ+l3xm0zNdZngf99HrV654G0etheMoj9m2XPTeCU6pe1Z
VaegO7lb0/uBtnUm2fwhi6WEsIcx4wQqkXSaH1tlYgBqU4WkEKaRi15sXTmGvQV7
vj5c9Knvaz7AEDbB1cYh0a3M32qJ0v4UEUPUYeUxfRAqMy8l0shzZ7prxWDJBQas
CeqJxihL+aWXvRMhI7cUZ+0C953X2nSNuxnJ27na54NHkDzQ9dW62SDYB3fM6VxQ
8+UWjzbtuQBm+LyNe6VG27eu1ewZKovIGsewCl5GGms6ssbrdYbMHyj6wMF/jPqj
lBp15vDdaM72zXLbO2veNGqZ8tDtEWwwIo8kkm36ydx5lz1xYiwdWAgo8J8bF+O9
MK7oq71eEoZBB9HXC/XX2oXVOBcfvL3jVOoBu4lZf3efV6do5T/q0yn5+VTfrVSI
9grvjEl6dCa73GsWu4gkAdWr/NG3KD82Aoh3btOFt/FKS/u0uZ4=
=9XWx
-END PGP SIGNATURE-

Bug#851339: [Pkg-fonts-devel] Bug#851339: Bug#851339: Bug#851339: Bug#851339: fonts-firacode: package in Debian with non-Debian build dependencies

[Fabian Greffrath]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Mittwoch, den 18.01.2017, 03:24 +1100 schrieb Ben Finney:
> Debian recipients should have equal access to make modifications to
> the work, build the work from modified source, and install the
> result.

All these modifications could be made to the OTF files *just as well*,
there is no advantage in using the same font format as upstream does
for their development. But I figure we are running in circles now. ;)

> The fact of the matter is the Glyphs data files are the preferred
> form
> of the work to make modifications.

Please note that the "preferred form for modification" is a term
exclusive to the GPL, it does not necessarily apply to fonts licensed
under any other license. Also, I am not sure if this is really exactly
what is meant by the "missing sources" paragraph of the REJECTS FAQs.

> It would reveal that Debian recipients do not have equal access to
> the source, for modifying building, and installing the work.

And thus you would file a bug requesting the removal of this package
from Debian main? Are you even aware of the vast consequences that this
overly strict interpretation of the "missing sources" paragraph may
have?

 - Fabian
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAlh+g2oACgkQy+qOlwzN
Wd/hVA//X+zpFiwIdA2AUgAuQarC/zLV9RI1SHv4z+ASIvWyALzsLstxinD5fCOY
M6X6ySeU9ek7O/ZygHg1STgOzcBF42FvEIZscdFF6jMu5eH1zuW+t+8AoEJwMQLK
Uf50XrN0/ZR5DHHXKqMwfPZ39OOIJ5A9iYlHZEe8bkSYjbwF/HlIcUL53xddwOq9
bvETmHCeKJYst/QQsmR6sBNtYY2OV0onSoLxVxsbwLmlcKBA5Sg8DpjZBk407MFo
NGllJACTuEWXZDDypAdohEsln3/yw61F/B3LbakvobEnh4pT9iNiOlOCT5MuIOiu
yAs0tRFo5sH2rgt3HIlzfHqnCkm4U3+Y4+fHCXJTt5X9HnzC/GuExqP83o21fH3/
qRFSnx4hDfh/D89HiL/SRhj3mx5xGbjqvYuIuoRpH67loTw73nyv2qblv37eFXUg
uWTzoc3ln+/AQLaeFmzz8vZM2NPWff9PAKD+0QL9tbbRbAJsNpLZJbxXVC1sLP5Q
pyjESFt7DinDXPUWUgr1NXiaPJd9+sxcOnOje94B6cZpz3RWKsteTWWjJVmWfrbf
T5sVcwPo6ALHKX6MVXplO/prLKzvwivpO+U0wq9qKQe0M3PtJ+a6eZxKjOX/9re3
Qg0zsjagw2V/tYsszATyETAvU9gK21dVAJ8PDPiMduFsXdOV4WE=
=s0k/
-END PGP SIGNATURE-

Bug#851339: [Pkg-fonts-devel] Bug#851339: Bug#851339: Bug#851339: fonts-firacode: package in Debian with non-Debian build dependencies

[Fabian Greffrath]

Paul Wise wrote:
> The issue isn't that they currently use proprietary software to
> convert to OTF format. The issue is that there is no Free Software in
> Debian main that can build the OTF from source. This is a clear
> violation of Debian policy and that indicates the package needs to be
> in contrib.

But the OTF format itself is just as suitable a source format for fonts as
any other format. Why is it so important what upstream has chosen? It is
not that font composition is a human-readable-to-binary-one-way-road like
compilation C source files into object code or HTML documentation to PDF.

> In this case, if you look at the commits to the github repo, there is
> a clear canonical source format and that is the proprietary Glyphsapp
> format that can only be converted to OTF by the proprietary Glyphsapp
> software.

Thought experiment: Would it feel more "correct" if I forked the firacode
upstream project, converted their OTF files into fontforge's SFD format,
checked these into a GIT repo and then distributed these?

> I would vastly prefer the correct source of PNG images to be
> distributed in source packages and the PNG images created at build
> time to the current, fairly horrible, situation. Choice of source
> format is up to upstream though.

Another thought experiment: We have a fairly prominent example of
binary-only Type1 fonts available in the gsfonts package. They are
licensed under the GPL, so there is even a "preferred form for
modification" term that applies to them. Nobody knows how URW++ created
these fonts and what tools they used, nevertheless a number of viable
forks have been developed from them, among them GNU FreeFont and TeX Gyre.
Now, what would happen if URW++ suddenly revealed that they used
proprietary software to create the fonts and that the files that we have
are not the canonical sources. Why should it make a difference at all?

 - Fabian

Bug#851339: [Pkg-fonts-devel] Bug#851339: fonts-firacode: package in Debian with non-Debian build dependencies

[Fabian Greffrath]

Dear Ben,

thank you very much for your bug report. However, I believe you are wrong
with applying RC severity to this issue and I have added FTP-Masters to CC
in the hope for clarification.

Ben Finney wrote:
> I see now that this refers to a proprietary program named Glyphs, as a
> program used in the build procedure.
>
> So the correct description of this bug is that the package must not be
> in Debian until all its build dependencies are also in Debian. See
>  “Non-Main”.
>
> Packages that have a build dependency on a non-Debian package may be
> in the “contrib” archive area.

I don't think that it should make a difference if upstream uses
proprietary software to convert the fonts from some kind of source format
into the OTF format in which they are distributed. There are many fonts in
Debian which are only distributed in OTF format, either because upstream
uses this format to develop the fonts or because upstream simply does not
tell which other format they use. As long as the license allows for binary
distribution (and it does) I do not consider this an issue.

Generally, there is no canonical source format for fonts and any of the
common formats [1] retains the possibility to modify them, e.g. using
fontforge scripting. The OTF format is not restricted to being an "end
product". This makes a huge difference to e.g. PDF or PS documents which
are given as examples in the "Missing Sources" section of the REJECTS FAQs
that you refer to. Once converted into these formats, it is nearly
impossible to modify the documents or convert them back into their
respective source formats.


I hope this all makes sense.

Thank you ,

 - Fabian


[1] Think of e.g. graphics in PNG format of which we have plenty in
Debian. It wouldn't help if they were distributed in some other format
that upstream chose to use for creating them.

Bug#841868: Segfault in Gtk::Widget::show() since upgrading to 5.*

[Fabian Greffrath]

It's just a wild guess, but this

Pietro Battiston wrote:
> Package: ardour
> Version: 1:5.4.0~dfsg-1
[...]
> ii  ardour-data   1:4.2~dfsg-5

just doesn't seem corect to me!

 - Fabian

Bug#824956: Re. the Musescore situation in sid

[Fabian Greffrath]

Am Sonntag, den 17.07.2016, 16:24 +0100 schrieb James Cowgill:
> Woops I think that was my fault. It should be fixed in 2.0.3+dfsg1-2.

Thanks for taking care of this!

Is there a way to tell pbuilder to build arch:all and arch:any parts
separately, so bugs like this become apparent during a usual build?

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#824956: Re. the Musescore situation in sid

[Fabian Greffrath]

Am Samstag, den 16.07.2016, 19:17 + schrieb Thorsten Glaser:
> I’ll compile and test it now (modulo time needed for cooking,
> eating, etc). and mail back.

Ah, whatever. It compiled fine and so I uploaded it. So users can
upgrade their sid systems. Everything else could be buffed out in a
revision -2 upload.

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#824956: Re. the Musescore situation in sid

[Fabian Greffrath]

Hi Thorsten,

I could do a team upload of the current state in GIT this evening.
Could you confirm this is fine for uploading as it is now?

 - Fabian


Am Samstag, den 16.07.2016, 12:18 + schrieb Thorsten Glaser:
> 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 2.0.3+dfsg1-0.1 locally (on
> x32) and testing that it at least works for basic functions,
> but I need a willing sponsor. Otherwise, if someone else
> does it, that’d be just fine with me as well.
> 
> Thanks in advance,
> //mirabilos (current hat: music performer)

signature.asc
Description: This is a digitally signed message part

Bug#817199: transcode: should this package be removed?

[Fabian Greffrath]

Am Sonntag, den 13.03.2016, 21:25 +0100 schrieb Sebastian Ramacher:
> Yes, dvdwizard would have to be RoQ-ed if we are going to remove
> transcode. But it's also dead upstream and orphaned.

Alright, let's go for it.

Anyway, since transcode is a command-line utility, it should be rather
straightforward to convert dvdwizard to use something more advanced,
e.g. ffmpeg. But until someone who urgently needs dvdwizard volunteers
to do this, I think it should be alright to remove it from the archive.

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#817199: transcode: should this package be removed?

[Fabian Greffrath]

Am Dienstag, den 08.03.2016, 23:39 +0100 schrieb Sebastian Ramacher:
> What do you think?

No objections, except for this:

$ apt-cache rdepends transcode
transcode
Reverse Depends:
  transcode-doc
  xjadeo
  transcode-dbg
  multimedia-video
  python-mecavideo
  dvdwizard

It appears that at least dvdwizard has a hard Depends on transcode.

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#801251: ⚠ Bug#801251: monster-masher: FTBFS: error: #error This file requires compiler and library support for the ISO C++ 2011 standard

[Fabian Greffrath]

Hi Chris,

Am Mittwoch, den 07.10.2015, 21:18 +0100 schrieb Chris Lamb:
> The full build log is attached [...]

that's 1.8 MB.

Please consider using gzip when transmitting files of this size. I am
reading mails over my phone on the train and incidently hitting a mail
like this may come out costy.

Thanks,

Fabian


signature.asc
Description: This is a digitally signed message part

Bug#801251: ⚠ Bug#801251: monster-masher: FTBFS: error: #error This file requires compiler and library support for the ISO C++ 2011 standard

[Fabian Greffrath]

Am Donnerstag, den 08.10.2015, 09:07 +0100 schrieb Chris Lamb:
> Good grief, apologies. Let me know if you get dinged for this and
> I'll get you some BTC or somthing.

Never mind! By "costy" I meant "it drains off my high-speed volume". It
was not meant in the monetary sense, sorry for the confusion. ;)

Cheers,

Fabian


signature.asc
Description: This is a digitally signed message part

Bug#800118: binary directory problems loading mods

[Fabian Greffrath]

Control: severity -1 minor

Hi,

Am Samstag, den 26.09.2015, 21:49 -0430 schrieb PICCORO McKAY Lenz:
> Severity: grave

there is a policy regarding bug severities:

https://www.debian.org/Bugs/Developer#severities

This does not even remotely justify for a release-critical severity.

> debian oficial yquake set base directory to binary installed engine
> at /usr/lib/yamagi-quake2/ but last 5.30 release already set that
> as changelog describes..

Alright, so this doesn't seem too wrong.

> so i think this cause a problem, with debian package 5.21 or my
> own build of 5.31 i can load doom2 mod but with the debian 5.30
> i cannot load, and got and error:

How do you exactly attempt to load this mod?

> When i installed the mod doom2 as root in the base lib dir (as
> defined in rules)
> the mod loads! ( i put the doom2 directory in the binary dir a side
> baseq2)

So, if you install the mod into the game data directory, it loads? This
doesn't seem wrong to me, but I guess you want to load it from a user
-writable directory, right?

> I think the game path must not be set or maybe the system may change

I have no idea what this is supposed to mean?

> i still not report that to the upstream due i build a unchanged
> binary and works

How did you build an unchanged binary? What is required in the Debian
packaging to make loading mods from directories outside the hard-coded
data paths work?

Thank you!

 - Fabian

PS: It is not necessary to include the pkg-games-devel list in the
bug's CC, bugs maintained by the Debian Games Team are reported to a
public list anyway.


signature.asc
Description: This is a digitally signed message part

Bug#787398: Stable update? Bug#787398 (evolution-data-server: SMTP connection lost while reading message data)

[Fabian Greffrath]

Am Dienstag, den 18.08.2015, 09:58 +0200 schrieb Fabian Greffrath:
> unfortunately, I had no luck convincing the SRM to accept my proposed e
> -d-s update in Jessie in #789429. I didn't even receive a singly reply
> after ~2 months. Maybe one of you wants to try his luck with it?

So, 8.2 has been released without even a single comment to this
request. I am done with it. Feel free to reopen and try your luck. :/

 - Fabian



signature.asc
Description: This is a digitally signed message part

Bug#793961: Update on TimGM6mb bug?

[Fabian Greffrath]

Hi Jack,

Am Mittwoch, den 26.08.2015, 00:20 +0200 schrieb Jack Underwood:
> Any news on this bug?  It looks like quite a simple fix, I would do it 
> myself but I don't know how to use the debian git system (I have only 
> ever used github before).

it should have made it to testing now.

Cheers,

Fabian


signature.asc
Description: This is a digitally signed message part

Bug#793961: Update on TimGM6mb bug?

[Fabian Greffrath]

Hi all,

Am Mittwoch, den 26.08.2015, 00:20 +0200 schrieb Jack Underwood:
 Any news on this bug?  It looks like quite a simple fix, I would do it 
 myself but I don't know how to use the debian git system (I have only 
 ever used github before).

would anyone object if I nmu, ne team-upload this?

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#787398: Stable update? Bug#787398 (evolution-data-server: SMTP connection lost while reading message data)

[Fabian Greffrath]

Hi there,

Am Montag, den 15.06.2015, 10:46 +0200 schrieb Josselin Mouette:
 I put 3.12.11 in unstable precisely so that it gets a little testing,
 and I’d indeed like to see it in 8.2 if the diff is acceptable.

unfortunately, I had no luck convincing the SRM to accept my proposed e
-d-s update in Jessie in #789429. I didn't even receive a singly reply
after ~2 months. Maybe one of you wants to try his luck with it?

Cheers,

Fabian



signature.asc
Description: This is a digitally signed message part

Bug#787698: supertux: FTBFS on big-endian archs

[Fabian Greffrath]

Control: tags -1 + patch

Am Montag, den 08.06.2015, 09:07 +0200 schrieb Fabian Greffrath:
   *((char *)buffer) = tmp;

Correction: You'll also need to dereference the tmp pointer, i.e.:

--- supertux-0.3.5a.orig/src/audio/wav_sound_file.cpp
+++ supertux-0.3.5a/src/audio/wav_sound_file.cpp
@@ -159,7 +159,7 @@ WavSoundFile::read(void* buffer, size_t
 tmp[2*i+1] = c;
   }
 
-  *buffer = tmp;
+  *(char *)buffer = *tmp;
 #endif
 
   return readsize;

Cheers,

Fabian


signature.asc
Description: This is a digitally signed message part

Bug#791540: FTBFS: undefined reference to symbol 'SDL_UnlockSurface'

[Fabian Greffrath]

Am Donnerstag, den 13.08.2015, 20:05 +0200 schrieb Evgeni Golov: 
   -lSDL_image -lSDL_mixer

 Is there anything special in your setup that would trigger this?

It seems to link against both SDL_image and SDL_mixer, but not against
SDL itself!

 - Fabian



signature.asc
Description: This is a digitally signed message part

Bug#787398: Stable update? Bug#787398 (evolution-data-server: SMTP connection lost while reading message data)

[Fabian Greffrath]

Am Montag, den 15.06.2015, 10:56 +0200 schrieb Emilio Pozuelo Monfort:
 OK. But beware of http://bugs.debian.org/787624 when trying to push 
 this to jessie.

So, there are two package revisions +deb8u{1,2} that are currently
missing from the jessie branch in SVN, right?

What is the gbp import-dscs pendant in SVN?

Will it be possible to use jessie's evolution 3.12.9~ with e-d-s
3.12.11 or will this have to get updated in lockstep, too?

If we go for 3.12.11 for Jessie, I will need some help to merge this
version into the jessie SVN branch.

 - Fabian



signature.asc
Description: This is a digitally signed message part

Bug#787398: Stable update? Bug#787398 (evolution-data-server: SMTP connection lost while reading message data)

[Fabian Greffrath]

Hi Emilio,

Am Freitag, den 12.06.2015, 19:54 +0200 schrieb Emilio Pozuelo Monfort:
 
 There's already a branch in pkg-evolution/jessie/evolution-data
 -server/. Use
 that, build and test the packages in jessie, then open a p-u bug 
 against
 release.debian.org with a debdiff from jessie attached.

will do so, thanks!

Is there anything else we want to get into stable? Should we try to get
3.12.11 in, any expectations with regard to SRM approval for upstream
point updates?

Cheers,

Fabian



signature.asc
Description: This is a digitally signed message part

Bug#787398: Stable update? Bug#787398 (evolution-data-server: SMTP connection lost while reading message data)

[Fabian Greffrath]

Dear pkg-evolution,

this bug is present in the versions of e-d-s/libcamel currently in
unstable/testing and stable. It is really severe as it prevents mails
from being sent without evolution (and thus the user) taking any notice
of it. It thus may cause (and already has for me) silent data loss.

I really want to see this fixed in stable!

I'd volunteer to do all the conversation with release.d.o and do the
actual packaging and uploading. But I need assisstance with the appropriate 
branching and tagging of the package in SVN. It has been ages 
since I have done this last time.

So, who would like to help me with this?

Thank you very much already!

 - Fabian


signature.asc
Description: This is a digitally signed message part

Bug#787698: supertux: FTBFS on big-endian archs

[Fabian Greffrath]

Hi Vincent,

Am Donnerstag, den 04.06.2015, 00:40 -0700 schrieb Vincent Cheng: 
 /«PKGBUILDDIR»/src/audio/wav_sound_file.cpp:162:4: error: 'void*' is not a 
 pointer-to-object type
*buffer = tmp;
 ^
 make[3]: *** [CMakeFiles/supertux2.dir/src/audio/wav_sound_file.cpp.o] Error 1
 
 Any help (or better yet, patches) would be greatly appreciated!

in the WavSoundFile::read function, the buffer argument is a void
pointer, so de-referencing it is a bad idea. You might want to try
type-punning the pointer by e.g.

  *((char *)buffer) = tmp;

Hope that helps,

Fabian



signature.asc
Description: This is a digitally signed message part

Bug#787398: Acknowledgement (evolution-data-server: SMTP connection lost while reading message data)

[Fabian Greffrath]

Control: fixed -1 3.16.2-1

*sigh* will this work?


signature.asc
Description: This is a digitally signed message part

Bug#787398: evolution-data-server: SMTP connection lost while reading message data

[Fabian Greffrath]

Package: evolution-data-server
Version: 3.12.9~git20141128.5242b0-2+deb8u2
Severity: critical
Tags: patch
Justification: causes serious data loss

Hi there,

there is a serious bug in libcamel 3.12.3. This bug is not fixed in
3.12.11 and since 3.12.11 is the last upstream release of that
branch, it will not get fixed in any 3.12.x version ever.

It happens that you when send a mail in Evolution, the program reports no
error message at all and moves your mail to the Sent folder, whereas
the mail has not been sent at all! On the SMTP server side an error
like SMTP connection lost while reading message data is logged.
This happens especially with mails with attachments. The bug has been
identified upstream and is fixed in the 3.16 series, but not in 3.12 as
mentioned before:

https://bugzilla.gnome.org/show_bug.cgi?id=749292

The patch is simple and replaces a call to g_output_stream_write()
aith one to g_output_stream_write_all(). I have applied this patch to
a local copy I rebuilt of e-d-s and confirm that it fixes the issue
for me.

Since this issue caused silent loss of important data for me, I'd like
to ask for the patch to get applied to the 3.12 version in unstable
ASAP. Also, I believe this must definitely get applied to the version
in stable as well.

Thank you very much already,

 - Fabian


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'experimental'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages evolution-data-server depends on:
ii  evolution-data-server-common  3.12.9~git20141128.5242b0-2+deb8u2
ii  gnome-keyring 3.16.0-2
ii  libc6 2.19-18
ii  libcamel-1.2-49   3.12.9~git20141128.5242b0-2+deb8u2
ii  libdb5.3  5.3.28-9
ii  libebackend-1.2-7 3.12.9~git20141128.5242b0-2+deb8u2
ii  libebook-1.2-14   3.12.9~git20141128.5242b0-2+deb8u2
ii  libebook-contacts-1.2-0   3.12.9~git20141128.5242b0-2+deb8u2
ii  libecal-1.2-163.12.9~git20141128.5242b0-2+deb8u2
ii  libedata-book-1.2-20  3.12.9~git20141128.5242b0-2+deb8u2
ii  libedata-cal-1.2-23   3.12.9~git20141128.5242b0-2+deb8u2
ii  libedataserver-1.2-18 3.12.9~git20141128.5242b0-2+deb8u2
ii  libgcr-base-3-1   3.14.0-2
ii  libgcr-ui-3-1 3.14.0-2
ii  libgdata190.16.1-1
ii  libglib2.0-0  2.45.1-2
ii  libgoa-1.0-0b 3.14.2-1
ii  libgtk-3-03.14.5-1
ii  libgweather-3-6   3.16.1-1
ii  libical1a 1.0-1.3
ii  libldap-2.4-2 2.4.40+dfsg-1
ii  libpango-1.0-01.36.8-3
ii  libsecret-1-0 0.18.2-1
ii  libsoup2.4-1  2.48.0-1
ii  libxml2   2.9.1+dfsg1-5

evolution-data-server recommends no packages.

Versions of packages evolution-data-server suggests:
ii  evolution  3.12.9~git20141130.241663-1+b1
pn  evolution-data-server-dbg  none

-- no debconf information
From bae0c643978a67f5368b6b0e5638b97687ee443a Mon Sep 17 00:00:00 2001
From: Milan Crha mc...@redhat.com
Date: Mon, 9 Feb 2015 12:58:09 +0100
Subject: Make camel_stream_write() try to write all bytes at once

The default implementation of CamelStream::write() used
g_output_stream_write() method, which could write only a partial
content, returning how many bytes had been actually written. That's
fine, but not each caller counted with this, thus for example
a CamelStreamFilter::write() failed when only partial buffer had
been written, which could cause a silent failure on message send.
Easier than taking care of the not-whole-buffer-written state
at each place of the usage is to use g_output_stream_write_all()
function instead, which fails only on errors.

This had been reported downstream as:
https://bugzilla.redhat.com/show_bug.cgi?id=1186815

diff --git a/camel/camel-stream.c b/camel/camel-stream.c
index a4270f5..980c70b 100644
--- a/camel/camel-stream.c
+++ b/camel/camel-stream.c
@@ -147,20 +147,25 @@ stream_write (CamelStream *stream,
   GError **error)
 {
 	GIOStream *base_stream;
-	gssize n_bytes_written = (gssize) n;
+	gssize n_bytes_written = -1;
 
 	base_stream = camel_stream_ref_base_stream (stream);
 
 	if (base_stream != NULL) {
 		GOutputStream *output_stream;
+		gsize n_written = 0;
 
 		output_stream = g_io_stream_get_output_stream (base_stream);
 		stream-eos = FALSE;
 
-		n_bytes_written = g_output_stream_write (
-			output_stream, buffer, n, cancellable, error);
+		if (g_output_stream_write_all (output_stream, buffer, n, n_written, cancellable, error))
+			n_bytes_written = (gssize) n_written;
+		else
+			n_bytes_written = -1;
 
 		

Bug#787398: Acknowledgement (evolution-data-server: SMTP connection lost while reading message data)

[Fabian Greffrath]

Control: notfound -1 3.16.2-1



signature.asc
Description: This is a digitally signed message part

Bug#787398: Acknowledgement (evolution-data-server: SMTP connection lost while reading message data)

[Fabian Greffrath]

Control: found -1 3.12.9~git20141128.5242b0-2+deb8u2
Control: found -1 3.12.11-1
Control: notfound -1 3.16
Control: tags -1 +upstream +patch
Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=749292



signature.asc
Description: This is a digitally signed message part

Bug#785650: How to stick to Debian packages?

[Fabian Greffrath]

Hi there,

Am Samstag, den 30.05.2015, 18:46 +0200 schrieb Niklaas Baudet von
Gersdorff: 
 I already looked for a way to do so but remained unsuccessful. What is 
 the best way to achieve this once the packages have already been 
 installed from deb-multimedia.org ?

please follow the advice here and report back if this has helped you:

https://wiki.debian.org/DebianMultimedia/FAQ#Common_issues

- Fabian



signature.asc
Description: This is a digitally signed message part

Bug#785122: chocolate-doom is marked for autoremoval from testing

[Fabian Greffrath]

Control: severity -1 minor 
Control: forwarded -1 
https://github.com/chocolate-doom/chocolate-doom/issues/479
Control: tags -1 upstream pending
Control: retitle -1 accidental license upgrade to GPLv3+

Upstream also considers this a non-issue, thus downgrading severity:

https://github.com/chocolate-doom/chocolate-doom/issues/479#issuecomment-104072886

Cheers,

Fabian



signature.asc
Description: This is a digitally signed message part

Bug#785122: chocolate-doom is marked for autoremoval from testing

[Fabian Greffrath]

Dear Jonathan,

Am Mittwoch, den 20.05.2015, 04:39 + schrieb Debian testing
autoremoval watch: 
 chocolate-doom 2.1.0-1 is marked for autoremoval from testing on 2015-06-10
 
 It is affected by these RC bugs:
 785122: chocolate-doom: includes licence-incompatible GPLv3 code

this is getting serious. I don't don't understand how GPL2-or-later and
GPL3-or-later could be incompatible with each other. Would you please
either elaborate on this issue or lower the severity of this bug?

Thank you,

- Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785122: chocolate-doom: includes licence-incompatible GPLv3 code

[Fabian Greffrath]

Hi Jon,

Am Dienstag, den 12.05.2015, 14:17 +0100 schrieb Jonathan Dowland: 
 Chocolate-doom includes code taken from GnuPG, which is GPLv3, whereas
 chocolate-doom is GPLv2 (or later). Upstream have fixed this by replacing
 the AES implementation with one from the kernel. See

doesn't mixing GPlv2-or-later code with GPLv3 code result in code that
is GPLv3 only? I fail to see why this would be of RC severity. I mean,
there is no GPLv2-only code involved.

 https://github.com/chocolate-doom/chocolate-doom/commit/b3678129fd7bed6c3287ab682819b075e8bf495a

I have seen this commit but decided to wait for the GPLv3 licensed sha1
implementation to get replaced as well before I take action on the
Debian package.

Cheers,

Fabian



signature.asc
Description: This is a digitally signed message part

Bug#783258: flac: FTBFS due to missing symbols

[Fabian Greffrath]

Hi all, 

thanks for your replies!

Am Sonntag, den 26.04.2015, 01:10 +1000 schrieb Dmitry Smirnov: 
 .symbols seems not to be very useful for C++ and they come with high 
 maintenance cost. I'd probably just remove libflac++6.symbols...

Yes, that would probably be the easiest solution. And I am inclined to
do just this, as I am not really fluent in C++.

But, I'd prefer if someone with more experience in C++ libraries could
chime in as a second (ne, third) Uploader and take care of that file at
least. ;)

Cheers,

Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783258: flac: FTBFS due to missing symbols

[Fabian Greffrath]

Am Sonntag, den 26.04.2015, 19:01 +1000 schrieb Dmitry Smirnov: 
 No worries, I'll do that. :)

Cool, thank you very much for uploading!

- Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783258: flac: FTBFS due to missing symbols

[Fabian Greffrath]

Control: tags -1 + help

Hi Sebastian,

Am Freitag, den 24.04.2015, 21:27 +0200 schrieb Sebastian Ramacher: 
 | - _ZN4FLAC7Decoder4File13read_callbackEPhPm@Base 1.3.0
 | + _ZN4FLAC7Decoder4File13read_callbackEPhPj@Base 1.3.1-1
 | +#MISSING: 1.3.1-1# _ZN4FLAC7Decoder4File13read_callbackEPhPm@Base 1.3.0

WTF is wrong with C++ symbols files? The symbols are all there, they
differ just in name by their last character.

Cheers,

Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#775830: Acknowledgement (deng: has no human maintainer anymore)

[Fabian Greffrath]

Control: reassign -1 doomsday

 I once helped to get the package back up into shape in order to
 provide another alternative engine (besides prboom-plus) that was able
 to run freedoom. This was around the time when vavoom became unusable
 and was eventually removed from Debian.
 
 Meanwhile, however, I have completely lost interest in this port and
 do no longer volunteer to maintain its package. So, someone please
 take over this package.

Filed against the wrong source package, yay!

- Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#775830: deng: has no human maintainer anymore

[Fabian Greffrath]

Source: deng
Version: 1.10.4-2
Severity: serious
Justification: Policy 5.6.3

Hi all,

I once helped to get the package back up into shape in order to
provide another alternative engine (besides prboom-plus) that was able
to run freedoom. This was around the time when vavoom became unusable
and was eventually removed from Debian.

Meanwhile, however, I have completely lost interest in this port and
do no longer volunteer to maintain its package. So, someone please
take over this package.

Thanks,

Fabian


-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771126: Bug#771191: Bug#771126: libav/tests/lena.pnm: also not mentioned in debian/copyright

[Fabian Greffrath]

Am Dienstag, den 02.12.2014, 23:29 +0100 schrieb Bastien ROUCARIES:
 And offencive (sexist) for 50% of the population the women... 

Now it's getting really ridiculous. Gosh, it's a picture of a woman!

- Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#770918: Two CVEs against FLAC

[Fabian Greffrath]

Am Mittwoch, den 26.11.2014, 19:58 -0800 schrieb Erik de Castro Lopo: 
 One more patch to cherry pick:

Thank you very much!

I hope to be able to prepare updated packages by next week.

- Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#767659: poppler: diff for NMU version 0.26.5-2.1

[Fabian Greffrath]

On Mon, 10 Nov 2014 21:44:58 +0100 Pino Toscano p...@debian.org wrote:
 Please drop this NMU, since the approach chosen (bumping shlibs for
 everybody) is not correct.

We once had a very similar issue in the ffmpeg, ne libav packaging,
where we had to declare much stricter dependencies among the packaged
libraries than we had to expose to external packages linking to them.

We solved this by calling dh_makeshlibs twice: First, before calling
dh_shlibdeps, with very strict dependency information. And then again,
after calling dh_shlibdeps, with the relaxed dependency information that
other packages should see.

Maybe you could consider this approach.

Cheers,

Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765825: src:vavoom: Please change build dependency to libjpeg-dev (libjpeg-turbo transition)

[Fabian Greffrath]

Hi Ondřej,

thanks for taking care of the libjpeg-turbo transition!

Am Samstag, den 18.10.2014, 15:48 +0200 schrieb Ondřej Surý: 
 Package: src:vavoom
 Version: 1.33-5
 Severity: serious
 Justification: libjpeg-turbo transition

vavoom is currently only available in stable and experimental, and the
latter version FTBFS. It should have been removed as well when the RoM
request against the version in unstable has been filed. I'll take care
of that, so please don't waste your time with an NMU, it won't build
anyway.

Cheers,

Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762551: RFS: Re: Bug#762551: jumpnbump-levels: Package has no uploaders

[Fabian Greffrath]

Hi all,

Am Dienstag, den 23.09.2014, 00:53 -0700 schrieb Vincent Cheng: 
 jumpnbump-levels does not currently have any human uploaders. This is a
 violation of a must directive in Policy 5.6.3 [1], hence it is a RC bug.

I have prepared a new package in 

http://anonscm.debian.org/cgit/pkg-games/jumpnbump-levels.git/

in which I have also added myself to Uploaders.

Please upload this package, thanks!

- Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762453: brasero: doesn't even start (segfault)

[Fabian Greffrath]

Package: brasero
Version: 3.10.0-1
Severity: critical

This happens when I try to start Brasero, the last line translates to
segmentation fault:

$ brasero

(brasero:32051): GLib-GObject-WARNING **: The property GtkMisc:xalign is
deprecated and shouldn't be used anymore. It will be removed in a future
version.

(brasero:32051): GLib-GObject-WARNING **: The property
GtkSettings:gtk-menu-images is deprecated and shouldn't be used anymore.
It will be removed in a future version.

(brasero:32051): GLib-GObject-WARNING **: The property
GtkSettings:gtk-button-images is deprecated and shouldn't be used
anymore. It will be removed in a future version.

(brasero:32051): GLib-GObject-WARNING **: The property
GtkAlignment:yalign is deprecated and shouldn't be used anymore. It will
be removed in a future version.

(brasero:32051): GLib-GObject-WARNING **: The property
GtkButton:use-stock is deprecated and shouldn't be used anymore. It will
be removed in a future version.

(brasero:32051): Gtk-CRITICAL **: gtk_widget_get_preferred_width:
assertion 'GTK_IS_WIDGET (widget)' failed

(brasero:32051): Gtk-CRITICAL **: gtk_widget_set_size_request: assertion
'GTK_IS_WIDGET (widget)' failed

(brasero:32051): Gtk-CRITICAL **: gtk_widget_get_preferred_width:
assertion 'GTK_IS_WIDGET (widget)' failed

(brasero:32051): Gtk-CRITICAL **: gtk_widget_get_preferred_width:
assertion 'GTK_IS_WIDGET (widget)' failed

(brasero:32051): Gtk-CRITICAL **:
gtk_widget_get_preferred_height_for_width: assertion 'GTK_IS_WIDGET
(widget)' failed

(brasero:32051): Gtk-CRITICAL **:
gtk_widget_get_preferred_height_for_width: assertion 'GTK_IS_WIDGET
(widget)' failed

(brasero:32051): Gtk-CRITICAL **: gtk_widget_get_preferred_width:
assertion 'GTK_IS_WIDGET (widget)' failed

(brasero:32051): Gtk-CRITICAL **: gtk_widget_set_size_request: assertion
'GTK_IS_WIDGET (widget)' failed

(brasero:32051): Gtk-CRITICAL **: gtk_widget_get_preferred_width:
assertion 'GTK_IS_WIDGET (widget)' failed

(brasero:32051): Gtk-CRITICAL **:
_gtk_widget_get_preferred_size_and_baseline: assertion 'GTK_IS_WIDGET
(widget)' failed
Speicherzugriffsfehler


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (900, 'unstable'), (800, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages brasero depends on:
ii  brasero-common  3.10.0-1
ii  gnome-icon-theme3.12.0-1
ii  gstreamer1.0-plugins-base   1.4.1-1
ii  gvfs1.20.3-1
ii  libatk1.0-0 2.12.0-1
ii  libbrasero-media3-1 3.10.0-1
ii  libc6   2.19-11
ii  libcairo-gobject2   1.12.16-5
ii  libcairo2   1.12.16-5
ii  libgdk-pixbuf2.0-0  2.30.8-1
ii  libglib2.0-02.41.5-2
ii  libgstreamer-plugins-base1.0-0  1.4.1-1
ii  libgstreamer1.0-0   1.4.1-1
ii  libgtk-3-0  3.13.9-2
ii  libice6 2:1.0.9-1
ii  libnautilus-extension1a 3.12.2-1
ii  libpango-1.0-0  1.36.7-1
ii  libpangocairo-1.0-0 1.36.7-1
ii  libsm6  2:1.2.2-1
ii  libtotem-plparser18 3.10.2-3
ii  libtracker-sparql-1.0-0 1.0.4-1
ii  libxml2 2.9.1+dfsg1-4

Versions of packages brasero recommends:
ii  yelp  3.12.0-1

Versions of packages brasero suggests:
pn  libdvdcss2  none
ii  tracker 1.0.4-1
pn  vcdimager   none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762453: Acknowledgement (brasero: doesn't even start (segfault))

[Fabian Greffrath]

This is the backtrace (sorry, no additional debug symbols installed):

0x76334e86 in gtk_widget_size_allocate_with_baseline ()
from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
(gdb) bt
#0  0x76334e86 in gtk_widget_size_allocate_with_baseline ()
from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#1  0x7633592f in gtk_widget_size_allocate ()
from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#2  0x76076972 in ?? ()
from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#3  0x73ee4223 in g_cclosure_marshal_VOID__BOXEDv
(closure=0x6a8900, return_value=optimized out, instance=optimized
out, args=optimized out, marshal_data=optimized out, 
n_params=optimized out, param_types=0x678600)
at /tmp/buildd/glib2.0-2.41.5/./gobject/gmarshal.c:1160
#4  0x73ee13c2 in _g_closure_invoke_va (closure=0x0,
closure@entry=0x6a8900, return_value=0x7fffa7f0,
return_value@entry=0x0, instance=0x, instance@entry=0xa66510,
args=0x7fffa7f0, 
args@entry=0x7fffab00, n_params=61440, param_types=0x1027200)
at /tmp/buildd/glib2.0-2.41.5/./gobject/gclosure.c:831
#5  0x73efb057 in g_signal_emit_valist (instance=0xa66510,
signal_id=optimized out, detail=0,
var_args=var_args@entry=0x7fffab00)
at /tmp/buildd/glib2.0-2.41.5/./gobject/gsignal.c:3218
#6  0x73efb9af in g_signal_emit (instance=optimized out,
signal_id=optimized out, detail=optimized out)
at /tmp/buildd/glib2.0-2.41.5/./gobject/gsignal.c:3365
#7  0x76335689 in gtk_widget_size_allocate_with_baseline ()
from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#8  0x7633592f in gtk_widget_size_allocate ()
from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#9  0x75fd875c in ?? ()
from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#10 0x75fd673f in ?? ()
from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#751039: quake: FTBFS - WARNING **: Object with id=layer-quake-24 was not found in the document. Nothing exported.

[Fabian Greffrath]

Hi Simon,

Am Dienstag, den 10.06.2014, 23:01 +0100 schrieb Simon McVittie: 
 Looks like a change in make(1) behaviour: a rule to build
 build/24/quake.png used to take precedence over one for
 build/%/quake.png (and the same for 3 other basenames), and now it doesn't.
 
 This was more fragile than it should have been, anyway.

could you please git push your commits?

Thanks,

Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#737803: chocolate-doom: FTBFS: race during parallel installation

[Fabian Greffrath]

Am Samstag, den 10.05.2014, 21:27 -0700 schrieb Vincent Cheng: 
 Built, signed, and uploaded, thanks for your work!

Thank you so much for uploading the packages!

Best regards,

Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#737803: chocolate-doom: FTBFS: race during parallel installation

[Fabian Greffrath]

Am Montag, den 05.05.2014, 23:15 -0700 schrieb Vincent Cheng: 
 Don't forget that the Debian Games team
 has a sponsorship queue [1] that you can use if you're looking for a
 sponsor within the team; I aim to regularly check the queue for
 packages to sponsor.

Alright, I have added my pending uploads there.

- Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#737803: chocolate-doom: FTBFS: race during parallel installation

[Fabian Greffrath]

Am Montag, den 05.05.2014, 23:15 -0700 schrieb Vincent Cheng: 
 Built, signed, and uploaded. 

Thank you!

 Don't forget that the Debian Games team
 has a sponsorship queue [1] that you can use if you're looking for a
 sponsor within the team; I aim to regularly check the queue for
 packages to sponsor.

I just realize I have problems singing in into my Debian Wiki account.
Thanky anyway!

Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#737803: chocolate-doom: FTBFS: race during parallel installation

[Fabian Greffrath]

Dear Andreas,

this bug is fixed in GIT since the day you reported it. However,
unfortunately my regular sponsor is short of time and has somwhow thrown
the towel for package uploads in the short term. Since I don't want to
keep this (otherwise perfectly fine) package from testing any longer and
since you reported that bug, would you mind sponsoring the upload?

The package can be found here, it builds with git-buildpackage:
http://anonscm.debian.org/gitweb/?p=pkg-games/chocolate-doom.git

Thank you very much!

- Fabian


Am Donnerstag, den 06.02.2014, 02:36 +0100 schrieb Andreas Beckmann: 
 Source: chocolate-doom
 Version: 2.0.0-1
 Severity: serious
 Justification: fails to build from source (but built successfully in the past)
 
 Hi,
 
 your package failed to build on i386 [1] with a race condition during a
 parallel make install. This is caused by overriding the documentation
 destination to point to the same directory (which is not a problem,
 but it requires the install to be done sequentially).
 I could reproduce this race on the first attempt on amd64 with
 DEB_BUILD_OPTIONS=parallel=16
 
 The fix is easy: disable parallel installation in debian/rules by
 using
 
 dh_auto_install --max-parallel=1 -- ...
 
 
 [1] 
 https://buildd.debian.org/status/fetch.php?pkg=chocolate-doomarch=i386ver=2.0.0-1stamp=1388787898
 
 Andreas
 
 ___
 Pkg-games-devel mailing list
 pkg-games-de...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-games-devel
 


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#740988: vavoom fails to run if rebuilt against unstable

[Fabian Greffrath]

Dear Olly,

Am Freitag, den 07.03.2014, 15:07 +1300 schrieb Olly Betts: 
 If I rebuild vavoom 1.33-4 with current unstable, then install it and
 run vavoom, it fails to start.  If I reinstall the package of 1.33-4
 currently in the archive, vavoom starts OK, and seems to work - I played
 a whole level to check (purely in the interests of debugging).

thank you very much for that bug report. I have to admit, I have already
seen this before in the course of preparing an NMU for vavoom but forgot
to file a bug report. The severity is IMHO appropriate, because the game
simply fails to start. My attempts to debug the issue were also without
success.

This and the fact that Vavoom upstream is actually dead and has its
homepage removed lead me to the conclusion that it is maybe better to
entirely remove vavoom from Debian before the next stable release.

Any objections?

- Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#740988: vavoom fails to run if rebuilt against unstable

[Fabian Greffrath]

Am Freitag, den 07.03.2014, 09:50 + schrieb Olly Betts: 
 http://www.vavoom-engine.com/ seems to work for me, and while it's
 not as dead as some upstreams I've seen, the last release was over 3
 years ago, and last SVN commit about 2.5 years ago:
 http://sourceforge.net/p/vavoom/code/4431/log/?path=

Indeed, it's back. A few weeks ago it was taken off the web:

http://www.doomworld.com/vb/source-ports/66809-vavoom-down/

 But removal doesn't sound too terrible a plan.  Users should still be
 able to play most of these games, as we have other doom engine ports in
 Debian (I see at least doomsday and prboom-plus), and I noticed at least
 two visual glitches while playing the first level of freedoom with
 vavoom.

We have three other Doom ports in Debian, two of which are
Boom-compatible enough to run Freedoom, two of which are able to run
Heretic and Hexen and one which is able to run Strife. I don't think we
need Vavoom anymore.

- Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#738811: handbrake: crashes after source DVD is selected

[Fabian Greffrath]

severity 738811 important
thanks

Am Montag, den 03.03.2014, 08:16 -0500 schrieb Reinhard Tartler: 
 Thanks for the feedback. I'm reassigning this bug accordingly.

And I agree with Tony Mancill that this does not need to be
release-critical.

- Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#738811: handbrake: crashes after source DVD is selected

[Fabian Greffrath]

Am Dienstag, den 25.02.2014, 09:51 +0100 schrieb Jan Korous: 
 That's funny. I didn't notice this option. As soon as I unchecked the
 box (and started using libdvdread) it works. So the problem was in
 dvdnav actually (or at least according to the checker box label).

Let's hope new new releases currently prepared at VLC bring some
improvement.

- Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#738811: handbrake: crashes after source DVD is selected

[Fabian Greffrath]

Am Donnerstag, den 13.02.2014, 08:37 +0100 schrieb Jan Korous: 
 I have tried 2 different DVDs which I was able to play at the same machine
 without a glitch.

Could you please try again with the libdvdcss2 package installed?

- Fabian


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org