Summer means bye bye gut

[Simon]

Body Wrap at Home to lose 6-20 inches in one hour.

With Bodywrap we guarantee:
 you'll lose 6-8 Inches in one hour 
 100% Satisfaction or your money back

Bodywrap is soothing formula that contours, 
cleanses and rejuvenates your body while
reducing inches.

http://ambiguous.grouploseweight.com










bastard pnv carpet csb jaguar ya moth jbl 
rogers caf grey vb verisimilitude fkd bowen hr downward yhs coronet xq 
http://ambiguous.grouploseweight.com/r


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#102006: follow_ up from this weeke_nd

[simon]

It is on a "ro,ll.

Or'gainazt'ion: Angstrom Microsystm-es
OTCBB: "agms
Pro,pose: Invest now
Lsat co,lse: 0.40
Market volmue:, 331,485

In th-e w-ake "of recen't news, investors are noticing and volume is up.

It is just wraming up, makin.g huge mkarteing strides Angstrom
Microysstems Corp. wlil blow you aawy.

Still a low ivnestment  threshold, mak_e a  purcahse of agms Tuedsay.




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

git server git.debian-maintainers.org

[Simon Kainz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

The source packages

* gadmin-openvpn-client [1]
* gadmin-openvpn-server [2]

Both list git.debian-maintainers.org als Vcs-Git Repo.

But this DNS entry does not exist. Where is the new git repo (if there
is one)?


[1] http://packages.qa.debian.org/g/gadmin-openvpn-client.html
[2] http://packages.qa.debian.org/g/gadmin-openvpn-server.html

Regards,

Simon
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSHEetAAoJEBy08PeN7K/pbY0P/jB98uBEhmuGhk32h/QQh1n8
+H1j/EjI2HyTjnJXwDpIC2hgSuyoGoMdO/FVyo2+7+RR8RVRDCaS8DpQJMEJxaPO
dvg1AV+QctgGpV6F7zdhaskADWVhdexGTAy/c2tPROvoGbDmTKic5bMsPHqbhOBA
cf4VnzKyt09VAqMYyXyAWk4kzCBODoATDYJJgrzQd7qg0O0gJ1H9UwiluTzYJD3+
WGNKyMJLbnrAmSOJaqQ3l8ly5eTkPX5ecyhts8Sskb6WS1w7arE9oKhYXkstNOsz
tNrCRPrYugMFgXdRgFzPWALJeYFnIEXvLfm0vNbD7XuQRRkB9IrkokIo6jaWZPKU
BtPgAZxLi5ROWRTDbjuaUdsWUUt0APSphSx1zkC3yY1hfla3h5iMNBXTcM9Kl18X
5IyZHBocZT2SadHivFIZ3rkRuXYANJRC9M6n2Qyts1YQ+ZLlM1y9Scjx5Iuu+pf6
61UecysXKXYZs5JtfzyZSV0+WSi5GNEyAzPTHRZmtlegpFKaSziaPKbOcQTRISD0
r83lni+W81D/VnoCwylWHhQFG8yxCBJFSzrIwXvmaK4SOmFWpc8F0+ceidTKTTRQ
Iln1BXb9DRK5DSy0esnTEdgkUtfK9c1IUfHx/vVjdhfBADBB/VsomGhzHYc3l5hk
hjrp/kyX5KAWuwYxDPd2
=tngh
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/521c47b9.2070...@familiekainz.at

Bug#756032: libdnet: should be multiarch because apparently roaraudio wants it for some unfathomable reason

[Simon McVittie]

Package: libdnet
Version: 2.63
Severity: wishlist

libmuroar0, libmuroard3 and libroar2 depend on libdnet. They cannot be
installed for both :amd64 and :i386 (or whatever) unless libdnet is.

I have no idea why something that appears to be a sound server analogous
to PulseAudio/ESD would depend on what appears to be a library to
communicate with Ultrix and VMS machines over an obsolete non-IP protocol,
but perhaps I'm not understanding the problem space.

In any case, in the unlikely event that someone still cares about DECnet,
they should probably fix this or something.

The dependency chain of interest at the moment is

wine:i386 -> libopenal1 -> libroar-compat2 -> libroar2 -> libdnet
other stuff:amd64 -> libopenal1 -> libroar-compat2 -> libroar2 -> libdnet

in which the non-multiarch nature of libroar-compat and libroar2 (#755846)
and libdnet (this bug) is preventing wine from being installed on
fairly typical systems.

S

-- System Information:
Debian Release: jessie/sid
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libdnet depends on:
ii  libc6   2.19-7
ii  libgcc1 1:4.9.1-1
ii  libstdc++6  4.9.1-1

libdnet recommends no packages.

Versions of packages libdnet suggests:
pn  dnet-common  

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140725143252.ga13...@reptile.pseudorandom.co.uk

Bug#1051010: Bug #1051010: lwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

I've changed the subject line back to the one from the bug - I get a
*lot* of bugmail, which I usually see out-of-context, so "Investigating"
doesn't really work as a reminder of what bug and what package you're
talking about. I hope that's compatible with your workflow.

On Fri, 02 Feb 2024 at 12:11:13 +, Nicholas Bamber wrote:
> So far in order to investigate I have:
> 
> 1. installed discord on a lwm desktop via flatpak. This works but is pretty
> ugly and the whole filesystem is exposed.

Large proprietary apps containing an entire web browser engine tend not to
be feasible to sandbox meaningfully, unfortunately, especially if their
packagers want them to have full functionality for users who are unaware of
the existence of sandboxing and want everything to "just work".

My usual go-to test apps are GNOME Recipes
https://flathub.org/apps/org.gnome.Recipes, ASHPD demo
https://flathub.org/apps/com.belmoussaoui.ashpd.demo, or the portal tests
built by src:libportal (install libportal-tests-gtk3 and
libportal-tests-gtk4 and run with "GTK_USE_PORTAL=1 GDK_DEBUG=portals" in
the environment, or you can build them into Flatpak apps from the source
package). Those are a lot more meaningfully sandboxed.

> 2. Looking into ways to get the XDG_CURRENT_DESKTOP into the systemd user
> environment.

In the original bug report, part of the solution I suggested was this:

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/lwm.desktop, most likely just "Lwm":

DesktopNames=Lwm;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

Most display managers take this into account and will convert it into
setting the XDG_CURRENT_DESKTOP setting (for example, I know that gdm3,
lightdm and sddm do this).

This won't work for xdm, but at some point I think we have to start
treating that sort of thing as an xdm limitation, rather than something
that individual desktop environments are expected to address?

> Putting a script into the 55 priority in /etc/X11/Xsession.d. This works
> (and does not pollute other desktop environments since we can check at that
> point). However it depends on the the package dbus-x11 and I have concerns
> about the long term support for this package.

Doesn't the combination of these two files

dbus-user-session: /etc/X11/Xsession.d/20dbus_xdg-runtime
dbus-x11: /etc/X11/Xsession.d/95dbus_update-activation-env

already do what's needed here? Those two packages represent the only two
implementations of the dbus-session-bus virtual package that currently
exist in Debian.

xdg-desktop-portal already depends on
default-dbus-session-bus | dbus-session-bus, so whenever xdg-desktop-portal
is installed, so is at least one of those two packages; and they both pull
in dbus-bin, which provides /usr/bin/dbus-update-activation-environment.

If someone adds a third implementation of dbus-session-bus, I think it
would be entirely reasonable for us to expect it to have similar handling
of at least the most basic variables like DBUS_SESSION_BUS_ADDRESS,
DISPLAY, XAUTHORITY and XDG_CURRENT_DESKTOP.

The other possible way to do this, which *would* work even for xdm, is to
do like gnome-session does, and upload at least those few basic environment
variables to the D-Bus activation environment during GUI session startup,
either from the main executable (using libdbus or a similar library) or
from a shell script wrapper (using dbus-update-activation-environment or
equivalent). This wouldn't necessarily have to imply a hard dependency
on d-u-a-e, it could be done conditionally. I realise that this is
unappealing for a specifically lightweight desktop environment, so I'd
be fine with the answer to this particular part being "wontfix, use a
better display manager if you want this functionality".

smcv

Re: Bug#1065816: weston: Dependency neatvnc found: NO found 0.8.0 but need: '< 0.8.0' ; matched: '>= 0.7.0'

[Simon McVittie]

Control: block 1036884 by -1

On Sun, 10 Mar 2024 at 10:37:51 +0100, Aurelien Jarno wrote:
> weston fails to build in unstable since the upload of neatvnc in version
> 8.0. From my build log on amd64:
...
> | Dependency neatvnc found: NO found 0.8.0 but need: '< 0.8.0' ; matched: '>= 
> 0.7.0'

This is important for the 64-bit time_t transition, because weston is
part of that transition, and also because packages like gtk4 use weston in
headless mode to test their Wayland backends. This could be mitigated by
temporarily making gtk4 skip its Wayland tests on 32-bit architectures,
but with gtk4 hat on, I would not be comfortable with doing that in
the long term, because in practice it seems to be inevitable that
functionality that isn't tested doesn't actually work.

Looking at the recent neatvnc upload, I was surprised to see that its
former maintainer updated it to a new upstream release in the same upload
as orphaning it (#1065738), and also updated the closely-related wayvnc
package to a new upstream release that matches neatvnc.

I also noticed that neatvnc 0.8.0 has an ABI break without bumping the
SONAME (#1065824), although that might be ignorable since nothing in
Debian seems to use the affected symbol.

I think the options here in the short term are:

1. adapt weston to support neatvnc 0.8.0, if it's straightforward to do so;
2. revert neatvnc to 0.8.0+really0.7.1+dfsg and wayvnc to 0.8.0+really0.7.2,
   and revisit this later, when we are *not* in the middle of a transition
   that touches thousands of packages;
3. temporarily disable the VNC backend in weston, and revisit this later

I would personally be very tempted by (2.) since it seems like the option
with least risk of regressions when compared with what's currently in
trixie, but I have no particular knowledge of these packages, so it
would be better if the maintainers of weston and/or wayvnc could adopt
neatvnc and handle this in whatever way they prefer. If this situation
is not resolved then I might do the revert (2.), by QA-uploading neatvnc
and NMU'ing wayvnc.

Thanks,
smcv

Bug#1065713: directfb: FTBFS on arm{el,hf}: error: ‘const struct input_event’ has no member named ‘time’

[Simon McVittie]

On Sat, 09 Mar 2024 at 12:29:26 +0100, Sebastian Ramacher wrote:
> linux_input.c: In function ‘translate_event’:
> linux_input.c:761:28: error: ‘const struct input_event’ has no member named 
> ‘time’
>   761 |  devt->timestamp = levt->time;
>   |^~

This seems to be essentially the same bug that was fixed in SDL by:
https://github.com/libsdl-org/SDL/commit/10fc3b3db715f0e2050e49f39d7d6e932813723c
so hopefully that's a useful reference.

smcv

Bug#1067171: bleachbit: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Package: bleachbit
Version: 4.6.0-2
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

bleachbit is an Architecture: all package, but has a direct dependency on
libgtk-3-0, as well as an indirect dependency on libgtk-3-0t64 via
gir1.2-gtk-3.0.

On the architectures affected by the 64-bit time_t transition (notably
armel and armhf), this is an impossible dependency, because libgtk-3-0 and
libgtk-3-0t64 conflict.

Please remove the explicit dependency on libgtk-3-0. For Python code
that uses GTK via GObject-Introspection, it is sufficient to depend
on gir1.2-gtk-3.0.

More information about this transition is available on
.

Thanks,
smcv

Bug#1067965: git-phab: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: git-phab
Version: 2.9.0~git20170531+6877964-2
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1067979: python3-pantalaimon: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-pantalaimon
Version: 0.10.5-1
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1074175: netkit-rwho: remove for trixie?

[Simon Josefsson]

Hi.

Most tools from netkit are candidates for migration to GNU InetUtils,
and rwho(d) may be another one -- see email and bug report below.
Cc'ing debian-devel to have broader discussion.

First, I think we need to understand the rationale for doing anything
about 'netkit-rwho': do we want to do something because 1) it is not
maintained upstream? or 2) because it is an insecure design?, or 3)
something else?

I believe that like telnet and ftp the second argument is not convincing
enough: sometimes you need these implementations for various strange
things, and it is poor style to dictate what people must do with their
software.  The position I've taken in GNU InetUtils is that it is better
for users to offer maintained tools and include a notice that they are
insecure, rather to offer un-maintained tools and refuse to work further
on them because they are insecure, putting users into a worse situation
than before.  Some people may disagree, and instead believe it is better
to actively kill old things rather than continue support them.  This is
a subjective decision, and if people are willing to do the work to keep
things alive, I think it is better to let them than to refuse this
contribution.

So, are our reason for doing anything about netkit-rwho really because
netkit upstream is not maintained?

If so, then one option is to add a rwho(d) implementation to GNU
InetUtils and let that replace the netkit implementation in Debian.
Historically, netkit tools have often had unclear or weird license
situation, so my preference is to import rwho(d) from some of the BSD
and to make that build for a wide variety of architectures and platforms
like we do with other tools in GNU InetUtils.  The BSD implementations
are usually not intended to be portable, and often have some minor flaw
that makes them troublesome to build on Debian -- we fix those issues in
GNU InetUtils.

That said, introducing yet another fork into the ecosystem shouldn't be
done lightly, so we should explore some way to pool resources (like I've
tried to establish with tnftp(d) maintainers when we have joint bugs).
I haven't analyzed what rwho(d) implementations are out there.  I see
NetBSD/FreeBSD has one still in -current, but OpenBSD removed it during
5.x.  Are people aware of any other implementations worth considering?

What do you think?

/Simon

Gürkan Myczko  writes:

> rwho(d) is a design from a different time, when networks were
> trusted, and so on. It seems to me, we should and could stop
> shipping it for trixie.
>
> I'm raising this bug now, to:
> 1) establish awareness
>
> I was long aware of this, as I was using rwhod/ruptime when networks
> were not split into thousand networks...
>
> 2) auto-rm it from trixie
>
> I'd rather have a migration path, not binary compatible, but
> functionality compatible
>
> 3) give people time to chime in / secure replacements to show up
>
> Please have a look at https://github.com/alexmyczko/rutpime (there's
> an ITP for it, and it has
> been in new queue several times:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013361
>
> After a while I intend to clone this bug to ftp.debian.org for
> removal from unstable.
>
> Please do not remove it if possible. I really wish to have a migration
> path for this, but well
> we're waiting for ftp team.
>
> Best,
> Alex
>
> Chris
>
>


signature.asc
Description: PGP signature

Bug#1079258: gnome-shell-mailnag: needs update for GNOME Shell 47

[Simon McVittie]

Package: gnome-shell-mailnag
Version: 40.0-7
Severity: wishlist
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-47

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 47, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-47.html
It might be as simple as adding 47 to the list of supported versions in
metadata.json, or it might require more involved code changes.
I couldn't see an upstream issue for this.

GNOME 47 is expected to be the version that is shipped in the
Debian 13 'trixie' stable release.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 47 transition in late 2024. This bug will be raised to
serious severity when the transition is ready to go ahead.

smcv

Bug#1079411: giggle: please migrate from deprecated gtksourceview3 to gtksourceview4 (or 5)

[Simon McVittie]

Source: giggle
Version: 0.7-6
Tags: trixie sid upstream
Control: block 996689 by -1
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs

gtksourceview3 was superseded in 2018 by gtksourceview4 (a new major
upstream release, but still using GTK 3). There's a porting guide here,
which is mostly "stop using deprecated APIs" plus a few function renames:
https://gnome.pages.gitlab.gnome.org/gtksourceview/gtksourceview5/porting-guide-3-to-4.html

gtksourceview3 is unmaintained and hasn't had an upstream release for more
than 5 years, so it would be great if the remaining gtksourceview3
applications can move to gtksourceview4 before trixie.

gtksourceview4 has itself been superseded by gtksourceview5, which is
for GTK 4 applications. Ideally GTK 3 applications should move to GTK 4,
but that's a larger and more intrusive change. Porting guide:
https://docs.gtk.org/gtk4/migrating-3to4.html,
https://gnome.pages.gitlab.gnome.org/gtksourceview/gtksourceview5/porting-guide-4-to-5.html

Thanks,
smcv

Bug#1018126: gthumb: depends on unmaintained clutter-1.0 and related libraries

[Simon McVittie]

Source: gthumb
Version: 3:3.12.2-1
Severity: important
Tags: bookworm sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs clutter
Control: block 996690 by -1

This package depends on clutter-1.0, which is no longer maintained
upstream (and has been effectively unmaintained for a while).

https://gitlab.gnome.org/GNOME/Initiatives/-/issues/31 has some porting
notes for projects that are part of GNOME, which might be useful
inspiration for porting this package.

smcv

Bug#1018133: pinpoint: depends on unmaintained clutter-1.0 and related libraries

[Simon McVittie]

Source: pinpoint
Version: 1:0.1.8-5
Severity: important
Tags: bookworm sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs clutter
Control: block 996690 by -1

This package depends on clutter-1.0, which is no longer maintained
upstream (and has been effectively unmaintained for a while).

https://gitlab.gnome.org/GNOME/Initiatives/-/issues/31 has some porting
notes for projects that are part of GNOME, which might be useful
inspiration for porting this package.

smcv

Bug#1021815: docbook-xsl: some title lengths result in incorrect escaping of TH line

[Simon McVittie]

Package: docbook-xsl
Version: 1.79.2+dfsg-2
Severity: normal

The ostree package has man pages written in Docbook XML and processed into
man pages via docbook.xsl. The one that has this bug is
man/ostree-admin-config-diff.xml, which contains:


ostree admin config-diff
1


I would expect this to be truncated into something like

.TH "OSTREE ADMIN CONFIG\-" "1" "" "OSTree" "ostree admin config-diff"

or

.TH "OSTREE ADMIN CONFIG" "1" "" "OSTree" "ostree admin config-diff"

which would render in man(1) like this:

> OSTREE ADMIN CONFIG(1)  ostree admin config-diffOSTREE ADMIN CONFIG(1)
> ... [content of man page here] ...
> OSTree  OSTREE ADMIN CONFIG(1)

However, it actually it comes out as

.TH "OSTREE ADMIN CONFIG\" "1" "" "OSTree" "ostree admin config-diff"

which has the effect of escaping the second double quote in the line,
resulting in parts of the header having an unintended interpretation:

> OSTREE ADMIN CONFIG()OSTREE ADMIN CONFIG()
> ... [content of man page here] ...
>  OSTREE ADMIN CONFIG()

I suspect that what has happened here is that the U+002D HYPHEN/MINUS in
the refentrytitle was escaped as \- before the title was truncated to fit
man page conventions, whereas it should have been truncated first and then
escaped second.

This is similar to #821235, in which single quotes are replaced by
\*(Aq before upper-casing, whereas the correct processing would have
probably been to upper-case first and then replace single quotes with
mixed-case \*(Aq afterwards.

smcv

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 
'oldstable-debug'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages docbook-xsl depends on:
ii  xml-core  0.18+nmu1

Versions of packages docbook-xsl recommends:
ii  docbook-xml  4.5-12

Versions of packages docbook-xsl suggests:
pn  dbtoepub
ii  docbook-xsl-doc-html [docbook-xsl-doc]  1.79.1-1
pn  docbook-xsl-saxon   
pn  fop 
pn  libsaxon-java   
ii  libxalan2-java  2.7.2-4
pn  libxslthl-java  
pn  xalan   

-- no debconf information

Bug#1037045: blobandconquer: fails to start with Xwayland: Couldn't set 800x600 video mode: Couldn't find matching GLX visual

[Simon McVittie]

Package: blobandconquer
Version: 1.11-dfsg+20-2
Severity: important

To reproduce:

* GNOME 43 in its default Wayland mode, with Xwayland available
* either of:
* "classic" SDL 1.2 (libsdl1.2debian version 1.2.15+dfsg2-8 tested)
* sdl12-compat (libsdl1.2-compat-shim version 1.2.64 tested)
* run blobAndConquer

Expected result: gameplay

Actual result:

[DEBUG (0)] Pak : Filename set to 
/usr/share/games/blobAndConquer/blobAndConquer.pak
[DEBUG (0)] initSystem()
[DEBUG (0)] unpack() : /home/smcv/.parallelrealities/blobAndConquer/savedata 
does not exist
[DEBUG (118)] Query stencil support: has stencils: 1
[DEBUG (118)] unpack() : /home/smcv/.parallelrealities/blobAndConquer/config 
does not exist
[DEBUG (118)] User Home = /home/smcv/.parallelrealities/blobAndConquer
[DEBUG (118)] Graphics::setResolution() - 0: 800 x 600
Couldn't set 800x600 video mode: Couldn't find matching GLX visual
[DEBUG (119)] Cleaning Up...
[DEBUG (119)] Deleting Tracer...
[DEBUG (119)] Freeing Audio...
[DEBUG (119)] Removing Temp File...
[DEBUG (119)] Saving Config...
[DEBUG (119)] Removing PAK File Data...
[DEBUG (119)] Closing Audio...
[DEBUG (119)] Freeing Game Data...
[DEBUG (119)] Freeing Remaining Entities...
[DEBUG (119)] Freeing Widgets...
[DEBUG (119)] Freeing Sprites and Fonts
[DEBUG (119)] Freeing Textures...
[DEBUG (119)] Freeing Models...
[DEBUG (119)] Closing TTF...
[DEBUG (119)] Quitting SDL...
[DEBUG (0)] All Done.

Workaround (1): log out, and log in to "GNOME on Xorg" instead.

Workaround (2): install libsdl1.2-compat-shim *and* run with
SDL_VIDEODRIVER=wayland,x11 in the environment (which is not the default,
even with SDL 2, because it can cause regressions in other games)

-- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-security'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages blobandconquer depends on:
ii  blobandconquer-data 1.11-dfsg+20-2
ii  libc6   2.36-9
ii  libgcc-s1   12.2.0-14
ii  libgl1  1.6.0-1
ii  libglu1-mesa [libglu1]  9.0.2-1.1
ii  libsdl-image1.2 1.2.12-13+b2
ii  libsdl-mixer1.2 1.2.12-17+b3
ii  libsdl-ttf2.0-0 2.0.11-6
ii  libsdl1.2debian [local build using sdl12-compat 1.2.64]
ii  libstdc++6  12.2.0-14
ii  libx11-62:1.8.4-2
ii  zlib1g  1:1.2.13.dfsg-1

blobandconquer recommends no packages.

Versions of packages blobandconquer suggests:
pn  blobwars  

-- no debconf information

Bug#1037374: giggle: build-depends on transitional package libgdk-pixbuf2.0-dev

[Simon McVittie]

Source: giggle
Version: 0.7-5
Severity: important
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: split-gdk-pixbuf

This package Build-Depends on libgdk-pixbuf2.0-dev.

In Debian 11, libgdk-pixbuf2.0-dev was split into two packages:

- libgdk-pixbuf-2.0-dev contains the supported gdk-pixbuf-2.0 library

- libgdk-pixbuf-xlib-2.0-dev contains the deprecated, unmaintained
  Xlib integration layer, gdk-pixbuf-xlib-2.0

If this package only requires functionality from gdk-pixbuf-2.0.pc
and , please update the build-dependency to
libgdk-pixbuf-2.0-dev.

If it also requires the Xlib integration gdk-pixbuf-xlib-2.0.pc and
 (unlikely), then you can also build-depend on
libgdk-pixbuf-xlib-2.0-dev until the package can be updated to remove
that requirement.

libgdk-pixbuf-2.0-dev was present in both Debian 11 and Debian 12, so
it is not necessary to have a "| libgdk-pixbuf2.0-dev" alternative
dependency, even for packages that are expected to be backported.

We should remove the libgdk-pixbuf2.0-dev transitional package during
the Debian 13 'trixie' cycle, so this bug is likely to become RC later.

Thanks,
smcv

Bug#1038015: achilles: Depends on SDL 1.2

[Simon McVittie]

Source: achilles
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038016: adlibtracker2: Depends on SDL 1.2

[Simon McVittie]

Source: adlibtracker2
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038017: adplay: Depends on SDL 1.2

[Simon McVittie]

Source: adplay
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038024: antigrav: Depends on SDL 1.2

[Simon McVittie]

Source: antigrav
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

I did some brief testing on this package as part of some upstream work on
libsdl1.2-compat-shim and it seemed to work well, but I was not able to
test it thoroughly.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038051: blobandconquer: Depends on SDL 1.2

[Simon McVittie]

Source: blobandconquer
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

I did some brief testing on this package as part of some upstream work on
libsdl1.2-compat-shim and it seemed to work well, but I was not able to
test it thoroughly.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038073: magicmaze: Indirectly depends on SDL 1.2

[Simon McVittie]

Source: magicmaze
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package depends on ruby-sdl, which is a language binding for SDL 1.2.
SDL 1.2 has been superseded by SDL 2 and is unmaintained upstream.

If possible, please port this package to SDL 2.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038099: libdv-bin: Depends on SDL 1.2

[Simon McVittie]

Package: libdv-bin
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038102: lv-tool-0.4: Depends on SDL 1.2

[Simon McVittie]

Package: lv-tool-0.4
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038180: csmash: Depends on SDL 1.2

[Simon McVittie]

Source: csmash
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038188: devil: Depends on SDL 1.2

[Simon McVittie]

Source: devil
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038345: fische: Depends on SDL 1.2

[Simon McVittie]

Source: fische
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038363: glhack: Depends on SDL 1.2

[Simon McVittie]

Source: glhack
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038362: gl-117: Depends on SDL 1.2

[Simon McVittie]

Source: gl-117
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038364: glob2: Depends on SDL 1.2

[Simon McVittie]

Source: glob2
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038484: zatacka: Depends on SDL 1.2

[Simon McVittie]

Source: zatacka
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038491: xmms2: Depends on SDL 1.2

[Simon McVittie]

Source: xmms2
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038494: wizznic: Depends on SDL 1.2

[Simon McVittie]

Source: wizznic
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038499: mazeofgalious: Depends on SDL 1.2

[Simon McVittie]

Source: mazeofgalious
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038508: moon-lander: Depends on SDL 1.2

[Simon McVittie]

Source: moon-lander
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038511: mp3blaster: Depends on SDL 1.2

[Simon McVittie]

Source: mp3blaster
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038563: starvoyager: Depends on SDL 1.2

[Simon McVittie]

Source: starvoyager
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038566: tdfsb: Depends on SDL 1.2

[Simon McVittie]

Source: tdfsb
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038805: gnubiff: Depends on unmaintained gamin

[Simon McVittie]

Source: gnubiff
Severity: important
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs
Control: block 1008205 by -1

This package has a Depends or Build-Depends on gamin, which is unmaintained
upstream (see #1008205).

For software that already depends on GLib, GFileMonitor
(g_file_monitor_file(), g_file_monitor_directory(), g_file_monitor())
is a good replacement.

We shouldn't really be shipping gamin in Debian 13, so this is likely to
become release-critical in future.

Thanks,
smcv

Bug#1039072: achilles: Missing build-dependency on libglu1-mesa-dev

[Simon McVittie]

Source: achilles
Version: 2-12
Severity: important
Tags: trixie sid ftbfs

achilles includes  but does not have the corresponding
build-dependency on libglu1-mesa-dev.

At the moment it compiles successfully anyway, because libsdl1.2-dev
pulls in libglu1-mesa-dev; but it fails to build when libsdl1.2-compat-dev
is installed, because libsdl1.2-compat-dev does not have that dependency.

I'm going to add a dependency on libsdl2-dev to libsdl1.2-compat-dev as a
workaround, but please give achilles explicit build-dependencies on all
the libraries that it requires.

Thanks,
smcv

Bug#1039074: adplay: FTBFS with libsdl1.2-compat-dev: missing build-dependency on pkgconf

[Simon McVittie]

Source: adplay
Version: 1.8.1-3
Severity: important
Tags: ftbfs trixie sid

I tried compiling adplay on a porterbox with libsdl1.2-compat-dev
instead of libsdl1.2-dev, in preparation for having a future version of
sdl12-compat take over the libsdl1.2-dev name.

I found that adplay FTBFS with:

> configure.ac:19: error: possibly undefined macro: AC_CHECK_LIB
>   If this token and others are legitimate, please use m4_pattern_allow.
>   See the Autoconf documentation.
> configure.ac:19: error: possibly undefined macro: AC_MSG_ERROR
> configure.ac:21: error: possibly undefined macro: AC_MSG_WARN
> autoreconf: error: /usr/bin/autoconf failed with exit status: 1
> dh_autoreconf: error: autoreconf -f -i returned exit code 1

This appears to be fixable by installing pkgconf, which this package
requires for the pkg.m4 macros.

With the old libsdl1.2-dev, pkgconf was pulled in by this dependency chain:

libsdl1.2-dev -> libpulse-dev -> libglib2.0-dev -> pkg-config -> pkgconf

As a pragmatic workaround for legacy software I'm going to make
libsdl1.2-dev depend on pkgconf, but please fix this properly by adding
Build-Depends on all the components that this package explicitly uses.

Thanks,
smcv

Bug#1038015: achilles: Depends on SDL 1.2

[Simon McVittie]

On Thu, 15 Jun 2023 at 12:28:35 +0100, Simon McVittie wrote:
> 4. Install libsdl1.2-compat-dev and recompile the package.

I tried this on a porterbox and it seems to build fine, other than
the missing build-dependency on libglu1-mesa-dev reported as #1039072
(which I'm going to work around by making libsdl1.2-compat-dev depend
on libsdl2-dev). I didn't test the resulting binaries.

smcv

Bug#1038016: adlibtracker2: Depends on SDL 1.2

[Simon McVittie]

On Thu, 15 Jun 2023 at 12:28:56 +0100, Simon McVittie wrote:
> 4. Install libsdl1.2-compat-dev and recompile the package.

I tried this on a porterbox and it seems to build fine. I didn't test
the resulting binaries.

smcv

Bug#1038017: adplay: Depends on SDL 1.2

[Simon McVittie]

On Thu, 15 Jun 2023 at 12:29:14 +0100, Simon McVittie wrote:
> 4. Install libsdl1.2-compat-dev and recompile the package.

I tried this on a porterbox and it seems to build fine, other than the
missing build-dependency on pkgconf that I reported as #1039074 (which
I intend to work around by making libsdl1.2-compat-dev depend on pkgconf).
I didn't test the resulting binaries.

smcv

Bug#1039080: antigrav: FTBFS with libsdl1.2-compat-dev: missing build-dependencies

[Simon McVittie]

Source: antigrav
Version: 0.0.3-10
Severity: important
Tags: ftbfs trixie sid

I tried recompiling antigrav with libsdl1.2-compat-dev instead of
libsdl1.2-dev, in preparation for having src:sdl12-compat take over the
libsdl1.2-dev package name.

I found that antigrav failed to build from source due to several missing
build-dependencies: it requires pkg.m4 macros,  and ,
leading to errors such as:

> ./configure: line 5844: syntax error near unexpected token `SDL,'
> ./configure: line 5844: `PKG_CHECK_MODULES(SDL, sdl >= $min_sdl_version,'

or after installing pkgconf:

> checking for sdl >= 1.1.5... yes
> checking for GL/gl.h... no
> configure: error: *** OpenGL not found ***

I'm going to work around this by adding dependencies to
libsdl1.2-compat-dev, but please add explicit build-dependencies on
any packages that antigrav explicitly checks for.

Thanks,
smcv

Bug#1041790: dbus-c++: depends on unmaintained gtkmm2.4, and indirectly on GTK 2

[Simon McVittie]

Source: dbus-c++
Version: 0.9.0-11
Severity: normal
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 967733 by -1
Control: block 967497 by -1

dbus-c++ Build-Depends on packages from src:gtkmm2.4, a C++ binding for
GTK 2.

GTK 2 was superseded by GTK 3 in 2011 (see
). It has been discontinued by its upstream
developer and no longer receives any upstream maintenance.

If dbus-c++ can be either updated to GTK 3, updated to drop the GTK
dependency or removed, then that would reduce the amount of technical
debt in the archive.

>From a quick look at the binary package dependencies and source code,
it looks as though simply dropping the build-dependency should work: this
will result in the dbus-browser example not being compiled any more, but
no changes to the installed files.

Thanks,
smcv

Bug#1041796: hexxagon: depends on unmaintained gtkmm2.4, and indirectly on GTK 2

[Simon McVittie]

Source: hexxagon
Version: 1.0pl1-4
Severity: normal
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 947713 by -1
Control: block 967497 by -1

hexxagon Build-Depends on packages from src:gtkmm2.4, a C++ binding for
GTK 2. GTK 2 was superseded by GTK 3 in 2011 (see
). It has been discontinued by its upstream
developer and no longer receives any upstream maintenance at all.

The direct replacement for gtkmm2.4 is gtkmm3.0, a C++ API for GTK 3.
Please see  for
information about porting from gtkmm2.4 to gtkmm3.0, and
 for general information
about porting from GTK 2 to GTK 3.

Thanks,
smcv

Bug#1050964: blackbox: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: blackbox
Version: 0.70.1-39
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

As well as being available as a window manager to integrate into some
larger environment, Blackbox behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/blackbox.desktop
which can be selected on entry to a display manager such as lightdm.

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/blackbox-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, Blackbox doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow Blackbox to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg blackbox
* reboot
* Log in as the user account, selecting "Blackbox" from the menu of
  possible X11 sessions
* Open a terminal and run:
  env | grep XDG_CURRENT_DESKTOP
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. Blackbox seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=Blackbox

would seem appropriate.

This would allow the Blackbox session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/blackbox-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of Blackbox who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/blackbox.desktop, most likely just "Blackbox":

DesktopNames=Blackbox;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

And then create a /usr/share/xdg-desktop-portal/blackbox-portals.conf
with whatever portal backends are desired for a Blackbox session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1051000: ctwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: ctwm
Version: 4.0.3-2
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

As well as being available as a window manager to integrate into some
larger environment, CTWM behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/ctwm.desktop
which can be selected on entry to a display manager such as lightdm.
If it's going to register as a desktop environment, then it should behave
like a desktop environment in other ways, such as choosing an
XDG_CURRENT_DESKTOP identifier.

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/ctwm-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, CTWM doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow CTWM to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg ctwm
* reboot
* Log in as the user account, selecting "CTWM" from the menu of
  possible X11 sessions
* Open an xterm and run:
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. CTWM seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=CTWM

would seem appropriate.

This would allow the CTWM session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/ctwm-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of CTWM who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/ctwm.desktop, most likely just "CTWM":

DesktopNames=CTWM;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

And then create a /usr/share/xdg-desktop-portal/ctwm-portals.conf
with whatever portal backends are desired for an CTWM session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1051010: lwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: lwm
Version: 1.2.4-1
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

As well as being available as a window manager to integrate into some
larger environment, Lwm behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/lwm.desktop
which can be selected on entry to a display manager such as lightdm.
If it's going to register as a desktop environment, then it should behave
like a desktop environment in other ways, such as choosing an
XDG_CURRENT_DESKTOP identifier.

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/lwm-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, Lwm doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow Lwm to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg lwm
* reboot
* Log in as the user account, selecting "Lwm" from the menu of
  possible X11 sessions
* Open an xterm and run:
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. Lwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=Lwm

would seem appropriate.

This would allow the Lwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/lwm-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of Lwm who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/lwm.desktop, most likely just "Lwm":

DesktopNames=Lwm;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

And then create a /usr/share/xdg-desktop-portal/lwm-portals.conf
with whatever portal backends are desired for an Lwm session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1051012: miwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: miwm
Version: 1.1-8
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

As well as being available as a window manager to integrate into some
larger environment, Miwm behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/miwm.desktop
which can be selected on entry to a display manager such as lightdm.
If it's going to register as a desktop environment, then it should behave
like a desktop environment in other ways, such as choosing an
XDG_CURRENT_DESKTOP identifier.

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/miwm-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, Miwm doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow Miwm to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg miwm
* reboot
* Log in as the user account, selecting "Miwm" from the menu of
  possible X11 sessions
* Open an xterm and run:
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. Miwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=Miwm

would seem appropriate.

This would allow the Miwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/miwm-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of Miwm who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/miwm.desktop, most likely just "Miwm":

DesktopNames=Miwm;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

And then create a /usr/share/xdg-desktop-portal/miwm-portals.conf
with whatever portal backends are desired for an Miwm session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1051015: pekwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: pekwm
Version: 0.1.18-1
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

As well as being available as a window manager to integrate into some
larger environment, Pekwm behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/pekwm.desktop
which can be selected on entry to a display manager such as lightdm.
If it's going to register as a desktop environment, then it should behave
like a desktop environment in other ways, such as choosing an
XDG_CURRENT_DESKTOP identifier.

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/pekwm-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, Pekwm doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow Pekwm to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg pekwm
* reboot
* Log in as the user account, selecting "Pekwm" from the menu of
  possible X11 sessions
* Open an xterm and run:
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. Pekwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=Pekwm

would seem appropriate.

This would allow the Pekwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/pekwm-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of Pekwm who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/pekwm.desktop, most likely just "Pekwm":

DesktopNames=Pekwm;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

And then create a /usr/share/xdg-desktop-portal/pekwm-portals.conf
with whatever portal backends are desired for an Pekwm session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1052113: gnome-shell-mailnag: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-mailnag
Version: 40.0-4
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1056130: gthumb: (unused?) build-dependency on deprecated libsoup-gnome2.4-dev

[Simon McVittie]

Source: gthumb
Version:  3:3.12.4-1
Severity: normal
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libsoup2.4 libsoup-gnome

While checking how many packages are still using the deprecated
libsoup2.4, I noticed that gthumb is one of only two packages in Debian
that still depend on libsoup-gnome2.4-dev.

libsoup-gnome was originally a sub-library for parts of libsoup that
depended on GNOME infrastructure, like GNOME's gconf settings for proxies.
My understanding is that all of that functionality has now been superseded
by components at the cross-desktop layer, like GIO extension points and
the glib-networking package.

gthumb has a build-dependency, but the actual binary has no dependency
on libsoup-gnome2.4-1, and from a quick look at codesearch I can't
see any sign that it is actually using this sub-library. Can the
build-dependency be removed?

This would also be a step closer to being able to port
gthumb from the deprecated libsoup2.4/libwebkit2-gtk-4.0-dev to
libsoup3/libwebkit2-gtk-4.1-dev (a mass bug filing for that will follow
at some point). libsoup3 does not have libsoup-gnome any more.

Thanks,
smcv

Bug#597927: auto-apt: Modernize debuild -> dpkg-buildpackage

[Simon Richter]

Package: auto-apt
Version: 0.3.22
Severity: normal

Hi,

having a build dependency recommendation is an useful feature, however
I'd rather not use debuild to drive the build process, but
dpkg-buildpackage. Would it make sense to switch here?

   Simon

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages auto-apt depends on:
ii  libc6 2.11.2-6   Embedded GNU C Library: Shared lib

Versions of packages auto-apt recommends:
ii  apt   0.8.5  Advanced front-end for dpkg
ii  devscripts2.10.68scripts to make the life of a Debi
ii  dpkg-dev  1.15.8.5   Debian package development tools
ii  perl  5.10.1-14  Larry Wall's Practical Extraction 
ii  sudo  1.7.4p4-3  Provide limited super user privile
ii  wget  1.12-2.1   retrieves files from the web

Versions of packages auto-apt suggests:
ii  build-essential   11.5   Informational list of build-essent
pn  libgtk-perl(no description available)
ii  xterm [x-terminal-emulator]   261-1  X terminal emulator

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100924102801.19912.11518.report...@richter

Re: News about unixcw?

[Simon Baldwin]

Hi Kamil,

Thanks for the email, and your interest in Unixcw.

I haven't updated the package for a while now, and don't really expect to do 
anything to it in the way of improvement in the foreseeable future.  I know 
that Kamal has created a few patches for it to help to keep it up to date with 
current Linux releases, and I'm very grateful to him for doing this.  I guess 
the program is sort-of looking for a new owner at present, and if somebody 
wanted to take it over I'd be fine with that.

Best regards,

--S





From: Kamil Ignacak 
To: simon_bald...@yahoo.com
Cc: ka...@whence.com; packa...@qa.debian.org
Sent: Tuesday, 30 August 2011, 19:05
Subject: News about unixcw?

Hi Simon,

Recently I've started using cwcp program from unixcw package to learn Morse 
code. I find it very useful, but I have also noticed that the program has some 
problems. Some of them have been addressed by patches created by Kamal Mostafa 
(https://launchpad.net/~kamalmostafa/+archive/unixcw-fixes). I have implemented 
some changes in my local copy of cwlib myself as well.

I would like to ask you whether you still actively maintain this package, and 
if you accept any patches or other kind of help with the package.

I'm adding in CC some people who may be interested in any news about the 
package.

Have a nice day!

Best regards,
Kamil Ignacak

Bug#663618: libmusicbrainz-2.1: CPPFLAGS hardening flags missing

[Simon Ruderich]

Package: libmusicbrainz-2.1
Version: 2.1.5-6.2
Severity: important
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

The CPPFLAGS hardening flags are missing because they are not set
in debian/rules.

The following patch fixes the issue.

diff -Nru libmusicbrainz-2.1-2.1.5/debian/rules 
libmusicbrainz-2.1-2.1.5/debian/rules
--- libmusicbrainz-2.1-2.1.5/debian/rules   2011-12-17 
13:40:15.0 +0100
+++ libmusicbrainz-2.1-2.1.5/debian/rules   2012-03-12 
18:34:07.0 +0100
@@ -35,7 +35,7 @@
dh_testdir
ln -sf /usr/share/misc/config.sub   config.sub
ln -sf /usr/share/misc/config.guess config.guess
-   ./configure $(confflags) LDFLAGS="$(LDFLAGS)" CFLAGS="$(CFLAGS)" 
CXXFLAGS="$(CFLAGS)" \
+   ./configure $(confflags) LDFLAGS="$(LDFLAGS)" CFLAGS="$(CFLAGS)" 
CXXFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" \
  --prefix=/usr
touch $@

To check if all flags were correctly enabled you can use
`hardening-check` from the hardening-includes package and check
the build log (hardening-check doesn't catch everything):

$ hardening-check /usr/lib/libmusicbrainz.so.4.0.3
/usr/lib/libmusicbrainz.so.4.0.3:
 Position Independent Executable: no, regular shared library (ignored)
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: no not found!

(Position Independent Executable and Immediate binding is not
enabled by default.)

Use find -type f \( -executable -o -name \*.so\* \) -exec
hardening-check {} + on the build result to check all files.

Regards,
Simon

[1]: https://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags
[2]: https://wiki.debian.org/HardeningWalkthrough
[3]: https://wiki.debian.org/Hardening

- -- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJPXjVIAAoJEJL+/bfkTDL5jsIQAJXGM/DbOm7ceQ8aLIs6UxnZ
1tXBeLYIk/Bw5Aiz2wBU5Rjzgw0Ci6X7jqJU4Rg8tJFVp1bpgCoJddeOe8f+FlrG
YcKts5tylmlyP2dGbx359zrOI/wGHHjyE/1jchPjRp+huaYmpwmQSGw4ciLGtUyZ
sGx382zw3Tgv34FR1pcYQWZDKhICSYruw8ge+aAMsUaHzXjCOiSuGNyqibopa9TY
8NQ7NFMGgXrk3iOxVNjJT2BgnTvI/Xs6nGvHIKbZwzBYkUDXi8xVLpsk3FArMKKO
D4SnAR0hg6x6p+6PGfEoSB8cHAYqG9htdM85SsAn2hZ0L/CHaNSgaK1skWDxJIfg
7PeU1RotfI0nmHuliwkf+ZqgZbjKv3qEbEKb3/IgXwmzeOHGPAYIJqyI/qFAN2Wm
Jn+8lHLfel5VeyehwjMOdDJvC0FuCQ6lsPyyuWFYOFbYezdBq8rbsK9qXfRf9//x
+Uea22EQcNnjdvxFVfxOtTNrbBcVqAIF7qIh7upTsh2vQse1fS0EyOT7saQ+fkkz
RqsFc2BXosvh+yF3xXOUFmCAl2XRQCtR1LQUXIEsTPAsPw9mVM+m5teklkQF+JnU
6X8zJNyBIhtnzyx+2CZrfexrzb2nekzMyHvBlMsVZCA7iBjB1O0R0SC7T3rFrUyb
SLuZ/hw8fpsGcBfE29t3
=tJTQ
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120312174133.21718.20663.reportbug@nocreeps

Bug#663625: zgv: Hardening flags missing

[Simon Ruderich]

Package: zgv
Version: 5.9-4
Severity: important
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

The hardening flags are missing because the build system ignores
them. For more hardening information please have a look at [1],
[2] and [3].

The attached patch fixes the issue. If possible it should be sent
upstream.

To check if all flags were correctly enabled you can use
`hardening-check` from the hardening-includes package and check
the build log (hardening-check doesn't catch everything):

$ hardening-check /usr/bin/zgv
/usr/bin/zgv:
 Position Independent Executable: no, normal executable!
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: no not found!

(Position Independent Executable and Immediate binding is not
enabled by default.)

Use find -type f \( -executable -o -name \*.so\* \) -exec
hardening-check {} + on the build result to check all files.

Regards,
Simon

[1]: https://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags
[2]: https://wiki.debian.org/HardeningWalkthrough
[3]: https://wiki.debian.org/Hardening

- -- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJPXk5CAAoJEJL+/bfkTDL5+bgP/0wOW+QJElAOLjZT3M7h0Pls
Cj9GDwmgmXQxP9WHIE4khVftha2ZqqGgFAawRHmmgdtseK8e1M0VcIjGzL24TtJO
rHRlRImDQ+zfJTTq/pM2h0VS2HKbqIev8RdCTdDYDojm/yOMzrxythxbOKYlHR4J
OotYFMOQHgtV6tImFusgJhUVkfSYBcf1f73ju+X/1FiJ6bPjvVY/IeUUiNsVmMfi
iUm63Mu1nFaLrswFxe6JZbV3yeOxnaaDiGV8y2riWEJ4LPvoq3ljmbb6mTqeSqT3
y+o7mz+9ZhK4mDZPosmvbBvfUB/qBOo7bUV9fcvwl51H3gj2E9nh29kruE+qZqYj
RjBsNLIFbHgXzMyk6x2jPF9QoAJfPHzynmpVLyr41ZsEQ/Nn04JnQjvJcuKlLIpR
eWi0xH3u2JlXUzGKjV2Ce2W+v37Bggh5JFA6qo0YPkiyf3ar0jGCZpV34Leaxz/O
vgduNkEVMu4zBhR6XhGA5/mzK/E/lur8tjatFqK+t4qQNHCSdaay7m8YzVgqg/mp
Jtigx2MsUxpF3o8oZI7kRoyMNiL7NT3c+Tr/x1uKr80EHWOtyLE+5NvT5lwsbzCY
4mOi8mgUVjaT80uxlELMCGJAH/IYbnoiMaC9g9Yoz8MAmJTDN3wvjhTBDc0wsfAY
6fjt0NcrGbUgMHmraCFD
=Ods2
-END PGP SIGNATURE-
diff -u zgv-5.9/config.mk zgv-5.9/config.mk
--- zgv-5.9/config.mk
+++ zgv-5.9/config.mk
@@ -8,7 +8,7 @@
 # This is likely to be what you'll want for most systems:
 #
 CC=gcc
-CFLAGS=$(shell dpkg-buildflags --get CFLAGS) -O2 -Wall -fomit-frame-pointer -finline-functions
+CFLAGS+=-O2 -Wall -fomit-frame-pointer -finline-functions
 #
 # If you're brave enough to try compiling zgv on a non-x86 system :-),
 # this might be a better bet:
diff -u zgv-5.9/src/Makefile zgv-5.9/src/Makefile
--- zgv-5.9/src/Makefile
+++ zgv-5.9/src/Makefile
@@ -47,13 +47,13 @@
 	modesel.o readpcd.o readtiff.o readprf.o zgv_io.o
 
 zgv: $(ZGV_OBJS)
-	$(CC) $(CFLAGS) -o zgv $(ZGV_OBJS) $(ZGV_LIBS)
+	$(CC) $(LDFLAGS) -o zgv $(ZGV_OBJS) $(ZGV_LIBS)
 
 bdf2h: bdf2h.o
-	$(CC) $(CFLAGS) -o bdf2h bdf2h.o
+	$(CC) $(LDFLAGS) -o bdf2h bdf2h.o
 
 install-info: install-info.c
-	$(CC) $(INFODIRDEF) -o install-info install-info.c
+	$(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(INFODIRDEF) -o install-info install-info.c
 
 # explicitly removes /usr/bin/{zgv,zgv-sdl} in case of old
 # installation. Not nice to put this in the install target,
diff -u zgv-5.9/debian/rules zgv-5.9/debian/rules
--- zgv-5.9/debian/rules
+++ zgv-5.9/debian/rules
@@ -7,7 +7,10 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+CFLAGS  := $(shell dpkg-buildflags --get CFLAGS)
+CPPFLAGS:= $(shell dpkg-buildflags --get CPPFLAGS)
 LDFLAGS := $(shell dpkg-buildflags --get LDFLAGS)
+export CFLAGS CPPFLAGS LDFLAGS
 
 build: build-stamp
 build-stamp:

Bug#653511: Please enable hardened build flags

[Simon Ruderich]

Package: bochs
Version: 2.4.6-5
Followup-For: Bug #653511

reopen 653511
thanks

Dear Maintainer,

The hardening flags are partially missing because the build
system ignores them; CPPFLAGS are not used at all.

The attached patch fixes the issue.

To check if all flags were correctly enabled you can use
`hardening-check` from the hardening-includes package and check
the build log (hardening-check doesn't catch everything):

$ hardening-check /usr/bin/bxcommit /usr/bin/bximage /usr/bin/bochs-bin ...
/usr/bin/bxcommit:
 Position Independent Executable: no, normal executable!
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: no not found!
/usr/bin/bximage:
 Position Independent Executable: no, normal executable!
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: no not found!
/usr/bin/bochs-bin:
 Position Independent Executable: no, normal executable!
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: no not found!
...

(Position Independent Executable and Immediate binding is not
enabled by default.)

Use find -type f \( -executable -o -name \*.so\* \) -exec
hardening-check {} + on the build result to check all files.

Regards,
Simon

[1]: https://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags
[2]: https://wiki.debian.org/HardeningWalkthrough
[3]: https://wiki.debian.org/Hardening
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
Description: Use flags from environment (dpkg-buildflags).
 Necessary for hardening flags.
Author: Simon Ruderich 
Last-Update: 2012-03-15

Index: bochs-2.4.6/host/linux/pcidev/Makefile.in
===
--- bochs-2.4.6.orig/host/linux/pcidev/Makefile.in	2012-03-15 01:09:22.0 +0100
+++ bochs-2.4.6/host/linux/pcidev/Makefile.in	2012-03-15 01:22:10.284732558 +0100
@@ -17,7 +17,7 @@
 
 PCIDEV_MODULE_MAKE_ALL = @PCIDEV_MODULE_MAKE_ALL@
 
-CFLAGS = -Wstrict-prototypes -Wno-trigraphs -g -fno-strict-aliasing -fno-common -D__KERNEL__ -DMODULE -I$(KERNELDIR)/include -O -Wall
+CFLAGS = @CFLAGS@ -Wstrict-prototypes -Wno-trigraphs -g -fno-strict-aliasing -fno-common -D__KERNEL__ -DMODULE -I$(KERNELDIR)/include -O -Wall
 
 
 .PHONY : all
Index: bochs-2.4.6/gui/Makefile.in
===
--- bochs-2.4.6.orig/gui/Makefile.in	2012-03-15 01:09:22.0 +0100
+++ bochs-2.4.6/gui/Makefile.in	2012-03-15 01:09:22.0 +0100
@@ -109,44 +109,44 @@
 	$(LIBTOOL) --mode=compile --tag CXX $(CXX) -c $(CXXFLAGS) $(LOCAL_CXXFLAGS) $< -o $@
 
 libbx_%.la: %.lo
-	$(LIBTOOL) --mode=link --tag CXX $(CXX) -module $< -o $@ -rpath $(PLUGIN_PATH)
+	$(LIBTOOL) --mode=link --tag CXX $(CXX) $(LDFLAGS) -module $< -o $@ -rpath $(PLUGIN_PATH)
 
 libbx_x.la: x.lo
-	$(LIBTOOL) --mode=link --tag CXX $(CXX) -module $< -o $@ -rpath $(PLUGIN_PATH) $(GUI_LINK_OPTS_X)
+	$(LIBTOOL) --mode=link --tag CXX $(CXX) $(LDFLAGS) -module $< -o $@ -rpath $(PLUGIN_PATH) $(GUI_LINK_OPTS_X)
 
 libbx_sdl.la: sdl.lo
-	$(LIBTOOL) --mode=link --tag CXX $(CXX) -module $< -o $@ -rpath $(PLUGIN_PATH) $(GUI_LINK_OPTS_SDL)
+	$(LIBTOOL) --mode=link --tag CXX $(CXX) $(LDFLAGS) -module $< -o $@ -rpath $(PLUGIN_PATH) $(GUI_LINK_OPTS_SDL)
 
 libbx_svga.la: svga.lo
-	$(LIBTOOL) --mode=link --tag CXX $(CXX) -module $< -o $@ -rpath $(PLUGIN_PATH) $(GUI_LINK_OPTS_SVGA)
+	$(LIBTOOL) --mode=link --tag CXX $(CXX) $(LDFLAGS) -module $< -o $@ -rpath $(PLUGIN_PATH) $(GUI_LINK_OPTS_SVGA)
 
 libbx_beos.la: beos.lo
-	$(LIBTOOL) --mode=link --tag CXX $(CXX) -module $< -o $@ -rpath $(PLUGIN_PATH) $(GUI_LINK_OPTS_BEOS)
+	$(LIBTOOL) --mode=link --tag CXX $(CXX) $(LDFLAGS) -module $< -o $@ -rpath $(PLUGIN_PATH) $(GUI_LINK_OPTS_BEOS)
 
 libbx_rfb.la: rfb.lo
-	$(LIBTOOL) --mode=link --tag CXX $(CXX) -module $< -o $@ -rpath $(PLUGIN_PATH) $(GUI_LINK_OPTS_RFB)
+	$(LIBTOOL) --mode=link --tag CXX $(CXX) $(LDFLAGS) -module $< -o $@ -rpath $(PLUGIN_PATH) $(GUI_LINK_OPTS_RFB)
 
 libbx_amigaos.la: amigaos.lo
-	$(LIBTOOL) --mode=link --tag CXX $(CXX) -module $< -o $@ -rpath $(PLUGIN_PATH) $(GUI_LINK_OPTS_AMIGAOS)
+	$(LIBTOOL) --mode=link --tag CXX $(CXX) $(LDFLAGS) -module $< -o $@ -rpath $(PLUGIN_PATH) $(GUI_LINK_OPTS_AMIGAOS)
 
 libbx_win32.la: win32.lo
-	$(LIBTOOL) --mode=link --tag CXX $(CXX) -module $< -o $@ -rpath $(PLUGIN_PATH) $(GUI_LINK_OPTS_WIN32)
+	$(LIBTOOL) --mode=link --tag CXX $(CXX) $(LDFLAGS) -module $< -o $@ -rpath $(PLUGIN_PATH) $(GUI_LINK_OPTS_WIN32)
 
 libbx_macos.la: macos.lo
-	$(LIBTOOL) --mode=link --tag CXX $(CXX) -module $< -o $@ -rpath $(PLUGIN_PATH) $(GUI_LINK_OPTS_MACOS)
+	$(LIBTOOL) --mode=link --tag 

Bug#657537: Please enable hardened build flags

[Simon Ruderich]

reopen #657537
thanks

Dear Maintainer,

The hardening flags are missing in a few places because the build
system ignores them.

The attached patch fixes the issue, if possible it should be sent
upstream.

To check if all flags were correctly enabled you can use
`hardening-check` from the hardening-includes package and check
the build log (hardening-check doesn't catch everything):

$ hardening-check /usr/sbin/ircd-hybrid 
/usr/lib/ircd-hybrid/modules/autoload/m_accept.so 
/usr/lib/ircd-hybrid/modules/autoload/m_admin.so 
/usr/lib/ircd-hybrid/modules/autoload/m_away.so ...
/usr/sbin/ircd-hybrid:
 Position Independent Executable: no, normal executable!
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: no not found!
/usr/lib/ircd-hybrid/modules/autoload/m_accept.so:
 Position Independent Executable: no, regular shared library (ignored)
 Stack protected: yes
 Fortify Source functions: unknown, no protectable libc functions used
 Read-only relocations: yes
 Immediate binding: no not found!
/usr/lib/ircd-hybrid/modules/autoload/m_admin.so:
 Position Independent Executable: no, regular shared library (ignored)
 Stack protected: no, not found!
 Fortify Source functions: unknown, no protectable libc functions used
 Read-only relocations: yes
 Immediate binding: no not found!
/usr/lib/ircd-hybrid/modules/autoload/m_away.so:
 Position Independent Executable: no, regular shared library (ignored)
 Stack protected: no, not found!
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: no not found!
...

(Position Independent Executable and Immediate binding is not
enabled by default.)

Use find -type f \( -executable -o -name \*.so\* \) -exec
hardening-check {} + on the build result to check all files.

Regards,
Simon

[1]: https://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags
[2]: https://wiki.debian.org/HardeningWalkthrough
[3]: https://wiki.debian.org/Hardening
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
#! /bin/sh /usr/share/dpatch/dpatch-run
## Use build flags from environment (dpkg-buildflags).
## Necessary for hardening flags.
##
## All lines beginning with `## DP:' are a description of the patch.

@DPATCH@
Index: ircd-hybrid-7.2.2.dfsg.2/tools/Makefile.in
===
--- ircd-hybrid-7.2.2.dfsg.2.orig/tools/Makefile.in 2012-04-08 
17:15:14.509825884 +0200
+++ ircd-hybrid-7.2.2.dfsg.2/tools/Makefile.in  2012-04-08 17:16:40.729826262 
+0200
@@ -31,10 +31,10 @@
 
 # We must link these two against special libs
 encspeed: ../include/setup.h encspeed.c
-   $(CC) $(CFLAGS) $(INCLUDES) $(LDFLAGS) encspeed.c -o encspeed 
$(SSL_LIBS)
+   $(CC) $(CPPFLAGS) $(CFLAGS) $(INCLUDES) $(LDFLAGS) encspeed.c -o 
encspeed $(SSL_LIBS)
 
 mkpasswd: ../include/setup.h mkpasswd.c
-   $(CC) $(CFLAGS) $(INCLUDES) $(LDFLAGS) mkpasswd.c -o mkpasswd 
$(CRYPT_LIB)
+   $(CC) $(CPPFLAGS) $(CFLAGS) $(INCLUDES) $(LDFLAGS) mkpasswd.c -o 
mkpasswd $(CRYPT_LIB)
 
 # Default rule for everything
 
Index: ircd-hybrid-7.2.2.dfsg.2/contrib/Makefile.in
===
--- ircd-hybrid-7.2.2.dfsg.2.orig/contrib/Makefile.in   2012-04-08 
17:16:40.673826262 +0200
+++ ircd-hybrid-7.2.2.dfsg.2/contrib/Makefile.in2012-04-08 
17:16:58.965826342 +0200
@@ -13,6 +13,7 @@
 LD = @LD@
 LN = @LN@
 PICFLAGS   = @PICFLAGS@
+LDFLAGS= @LDFLAGS@
 MKDEP  = @MKDEP@
 INSTALL= @INSTALL@
 INSTALL_DATA   = @INSTALL_DATA@
@@ -115,7 +116,7 @@
 .SUFFIXES: .so .sl .o
 
 .c.so:
-   ${CC} ${PICFLAGS} ${CPPFLAGS} ${CFLAGS} $< -o $@
+   ${CC} ${PICFLAGS} ${CPPFLAGS} ${CFLAGS} ${LDFLAGS} $< -o $@
 
 .c.o:
${CC} ${CPPFLAGS} ${CFLAGS} -c $< -o $@
Index: ircd-hybrid-7.2.2.dfsg.2/modules/Makefile.in
===
--- ircd-hybrid-7.2.2.dfsg.2.orig/modules/Makefile.in   2012-04-08 
17:16:40.673826262 +0200
+++ ircd-hybrid-7.2.2.dfsg.2/modules/Makefile.in2012-04-08 
17:16:40.729826262 +0200
@@ -10,6 +10,7 @@
 SEDOBJ = @SEDOBJ@
 STDOUT = @STDOUT@
 CFLAGS = @IRC_CFLAGS@
+LDFLAGS= @LDFLAGS@
 PICFLAGS   = @PICFLAGS@
 MKDEP  = @MKDEP@
 INSTALL= @INSTALL@
@@ -178,7 +179,7 @@
${CC} ${CPPFLAGS} ${CFLAGS} -c $< -o $@
 
 .c.so:
-   ${CC} ${PICFLAGS} ${CPPFLAGS} ${CFLAGS} $< -o $@
+   ${CC} ${PICFLAGS} ${LDFLAGS} ${CPPFLAGS} ${CFLAGS} $< -o $@
 
 .so.sl:
$(LD) -b $< -o $@
Index: ircd-hybrid-7.2.2.dfsg.2/tools/rsa_respond/Makefile.in
===
--- ircd

Bug#670819: xloadimage: Hardening flags missing

[Simon Ruderich]

Package: xloadimage
Version: 4.1-18
Severity: important
Tags: Patch

Dear Maintainer,

The hardening flags are missing because the build system ignores
them. For more hardening information please have a look at [1],
[2] and [3].

The attached patch fixes the issue.

To check if all flags were correctly enabled you can use
`hardening-check` from the hardening-includes package and check
the build log (for example with blhc [4]) (hardening-check
doesn't catch everything):

$ hardening-check /usr/bin/uufilter /usr/bin/xloadimage
/usr/bin/uufilter:
 Position Independent Executable: yes
 Stack protected: no, not found!
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes
/usr/bin/xloadimage:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes

(Position Independent Executable and Immediate binding is not
enabled by default.)

Use find -type f \( -executable -o -name \*.so\* \) -exec
hardening-check {} + on the build result to check all files.

Regards,
Simon

[1]: https://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags
[2]: https://wiki.debian.org/HardeningWalkthrough
[3]: https://wiki.debian.org/Hardening
[4]: http://ruderich.org/simon/blhc/
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
Description: Use build flags from environment (dpkg-buildflags).
 Necessary for hardening flags.
Author: Simon Ruderich 
Last-Update: 2012-04-29

Index: xloadimage-4.1/Makefile.in
===
--- xloadimage-4.1.orig/Makefile.in	2012-04-29 12:13:45.456985928 +0200
+++ xloadimage-4.1/Makefile.in	2012-04-29 12:13:45.640985927 +0200
@@ -27,7 +27,7 @@
 	$(CC) -o $@ $(OBJS) build.o $(LDFLAGS) $(XLIB) $(LIBS)
 
 uufilter: uufilter.c
-	$(CC) $(CFLAGS) $(DEFS) uufilter.c -o $@
+	$(CC) $(CFLAGS) $(LDFLAGS) $(DEFS) uufilter.c -o $@
 
 .c.o: config.h image.h
 	$(CC) $(CFLAGS) -c $(DEFS) $<
Index: xloadimage-4.1/Makefile.std
===
--- xloadimage-4.1.orig/Makefile.std	2012-04-29 12:13:41.916985912 +0200
+++ xloadimage-4.1/Makefile.std	2012-04-29 12:13:45.640985927 +0200
@@ -23,7 +23,7 @@
 # the Make.conf file and recursively calls make.
 
 autoconfig: autoconfig.c
-	$(CC) -g -o autoconfig autoconfig.c
+	$(CC) $(CFLAGS) $(LDFLAGS) -g -o autoconfig autoconfig.c
 
 # manual configuration target
 configure:: autoconfig
Index: xloadimage-4.1/Makefile
===
--- xloadimage-4.1.orig/Makefile	2012-04-29 12:13:41.916985912 +0200
+++ xloadimage-4.1/Makefile	2012-04-29 12:13:45.640985927 +0200
@@ -8,7 +8,7 @@
 # Include system configuration parameters
 include Make.conf
 
-CFLAGS=$(OPT_FLAGS) $(CC_FLAGS) $(CC_CONFIG_FLAGS) $(X11_INC_DIR) \
+CFLAGS+=$(OPT_FLAGS) $(CC_FLAGS) $(CC_CONFIG_FLAGS) $(X11_INC_DIR) \
   -DSYSPATHFILE=\"$(SYSPATHFILE)\"
 LIBS=$(X11_LIB_DIR) $(X11_LIB_NAME) $(SYS_LIBS) -lm
 
@@ -23,7 +23,7 @@
 # the Make.conf file and recursively calls make.
 
 autoconfig: autoconfig.c
-	$(CC) -g -o autoconfig autoconfig.c
+	$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -g -o autoconfig autoconfig.c
 
 # manual configuration target
 configure:: autoconfig


signature.asc
Description: Digital signature

Bug#692929: Reopen request: ncpmount must be installed suid root_

[Simon L]

Is there going to be a fix for this at some point?  The alternatives to 
it are significantly worse in terms of perfomance (SSHFS etc).


Many thanks,

Simon


--
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5118c425.3050...@lavabit.com

Bug#561400: postman: should this package be removed?

[Simon McVittie]

Package: postman
Version: 2.1-7
Severity: serious
Justification: RC-buggy, low popcon, orphaned since 2007
User: debian...@lists.debian.org
Usertags: proposed-removal

postman seems like a possible candidate for removal from Debian. Cc'ing
KiBi since he touched it last :-)

* RC-buggy (FTBFS)
* low popcon (5 votes)
* orphaned since 2007
* last upstream release appears to have been 2005
* alternatives exist (it's webmail)
* potentially security-sensitive (it's webmail)

If you want to keep this package around in Debian, please just close this bug,
and do an upload to fix the issues in it.

If you don't think it's worth keeping, please send the following commands
to cont...@bugs.debian.org, replacing nn with this bug's number:

severity nn normal
reassign nn ftp.debian.org
retitle nn RM:  -- RoQA; RC-buggy, old, orphaned, low popcon
thanks 

For more information, see
http://wiki.debian.org/ftpmaster_Removals
http://ftp-master.debian.org/removals.txt

Regards,
smcv


signature.asc
Description: Digital signature

Bug#561402: ude: should this package be removed?

[Simon McVittie]

Source: ude
Version: 0.2.9b-5
Severity: normal
Justification: low popcon, last upstream in 2004, orphaned since 2007
User: debian...@lists.debian.org
Usertags: proposed-removal

ude/uwm seem like a possible candidate for removal from Debian:

* low popcon (17 votes each for ude and uwm)
* no upstream releases since 2004 (although there seems to be some activity
  on Sourceforge this year)
* orphaned since April 2007
* alternatives exist (it's yet another minimal window manager)

If you want to keep this package around in Debian, please just close this bug,
and do an upload to fix the issues in it.

If you don't think it's worth keeping, please send the following commands
to cont...@bugs.debian.org, replacing nn with this bug's number:

severity nn normal
reassign nn ftp.debian.org
retitle nn RM:  -- RoQA; orphaned, low popcon, alternatives
thanks 

For more information, see
http://wiki.debian.org/ftpmaster_Removals
http://ftp-master.debian.org/removals.txt

Regards,
smcv


signature.asc
Description: Digital signature

Bug#560044: Quite a bad bug indeed

[Simon Pepping]

Quite a bad bug indeed. It breaks applications. On the RSSOwl list
several confused Debian testing users reported that their favourite RSS
reader was suddenly no longer able to update feeds.

Regards, Simon

-- 
Simon Pepping
email: spepp...@leverkruid.eu
home page: http://www.leverkruid.eu



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

Bug#564930: aap: should this package be removed?

[Simon McVittie]

Source: aap
Severity: wishlist
Justification: low-popcon build tool with no rdepends
User: debian...@lists.debian.org
Usertags: proposed-removal

aap seems like a candidate for removal from Debian:

* orphaned
* low popcon (12 votes)
* many alternatives exist (it's a make-like tool)
* nothing in Debian depends on it

If you want to keep this package around in Debian, please adopt it.

If you don't think it's worth keeping, please send the following commands
to cont...@bugs.debian.org, replacing nn with this bug's number:

severity nn normal
reassign nn ftp.debian.org
retitle nn RM: aap -- RoQA; orphaned, low popcon, no rdepends, alternatives
thanks 

For more information, see
http://wiki.debian.org/ftpmaster_Removals
http://ftp-master.debian.org/removals.txt

Regards,
smcv


signature.asc
Description: Digital signature

Bug#564933: aub: should this package be removed?

[Simon McVittie]

Source: aub
Severity: serious
Justification: orphaned, orphaned upstream, low popcon, alternatives exist
User: debian...@lists.debian.org
Usertags: proposed-removal

aub seems like a candidate for removal from Debian:

* orphaned
* the previous Debian maintainer was also the upstream
* low popcon (6 votes)
* alternatives exist (e.g. brag, lottanzb, nzb)

If you want to keep this package around in Debian, please adopt it.

If you don't think it's worth keeping, please send the following commands
to cont...@bugs.debian.org, replacing nn with this bug's number:

severity nn normal
reassign nn ftp.debian.org
retitle nn RM: aub -- RoQA; orphaned, no upstream, low popcon, alternatives
thanks 

For more information, see
http://wiki.debian.org/ftpmaster_Removals
http://ftp-master.debian.org/removals.txt

Regards,
smcv


signature.asc
Description: Digital signature

Bug#564934: libcgi: should this package be removed?

[Simon McVittie]

Source: libcgi
Severity: serious
Justification: orphaned, inactive upstream, low popcon, no rdepends
User: debian...@lists.debian.org
Usertags: proposed-removal

libcgi seems like a candidate for removal from Debian:

* orphaned
* inactive upstream (no releases since 2003)
* low popcon (6 votes)
* library with no rdepends
* security-sensitive (CGI) packages shouldn't be unmaintained :-)

If you want to keep this package around in Debian, please adopt it.

If you don't think it's worth keeping, please send the following commands
to cont...@bugs.debian.org, replacing nn with this bug's number:

severity nn normal
reassign nn ftp.debian.org
retitle nn RM: libcgi -- RoQA; orphaned, inactive upstream, library with no 
rdepends
thanks 

For more information, see
http://wiki.debian.org/ftpmaster_Removals
http://ftp-master.debian.org/removals.txt

Regards,
smcv


signature.asc
Description: Digital signature

Bug#564938: wip: should this package be removed?

[Simon McVittie]

Source: wip
Severity: wishlist
User: debian...@lists.debian.org
Usertags: proposed-removal

wip seems like a candidate for removal from non-free:

* orphaned
* non-free
* low popcon (20 votes)
* no upstream releases in 10 years
* alternatives exist (presumably... it's described as plotting software)

If you want to keep this package around in Debian, please just close this bug.

If you don't think it's worth keeping, please send the following commands
to cont...@bugs.debian.org, replacing nn with this bug's number:

severity nn normal
reassign nn ftp.debian.org
retitle nn RM: wip -- RoQA; 
thanks 

For more information, see
http://wiki.debian.org/ftpmaster_Removals
http://ftp-master.debian.org/removals.txt

Regards,
smcv


signature.asc
Description: Digital signature

Bug#564940: wip: should this package be removed?

[Simon McVittie]

Source: sfind
Severity: serious
Justification: orphaned, low popcon, an alternative is Essential: yes
User: debian...@lists.debian.org
Usertags: proposed-removal

sfind seems like a candidate for removal from Debian:

* orphaned
* low popcon (7 votes)
* doesn't seem any better than modern findutils, which is Essential: yes

GNU findutils seems to have the advantages cited in sfind's Description now,
so sfind no longer seems to be necessary?

If you want to keep this package around in Debian, please adopt it and close
this bug.

If you don't think it's worth keeping, please send the following commands
to cont...@bugs.debian.org, replacing nn with this bug's number:

severity nn normal
reassign nn ftp.debian.org
retitle nn RM: sfind -- RoQA; orphaned, low popcon, alternative is Essential
thanks 

For more information, see
http://wiki.debian.org/ftpmaster_Removals
http://ftp-master.debian.org/removals.txt

Regards,
smcv


signature.asc
Description: Digital signature

Bug#537906: Workaround available

[Simon Guest]

Hi,

I hit the same problem, which is that synfig is passing options to
ffmpeg which ffmpeg doesn't understand, namely -loop -hq -title blah.

Probably a previous version of ffmpeg understood these options, but
the latest one appears not to.  The proper fix is therefore to update
synfig to use the correct options for ffmpeg.

In the meantime, I wrote a python script called ffmpeg which you could
keep somewhere on your path ahead of /usr/bin.  It simply strips out
the bogus options and invokes the real ffmpeg.

Yes I know it's a bit of a dodgy solution, but needs must ...

cheers,
Simon
#!/usr/bin/python

# ffmpeg - a work-around for synfig to filter out the bogus arguments that
# get passed in when rendering

import os
import sys

original_args = sys.argv
new_args = []

#print original_args

while len(original_args) > 0:
arg = original_args.pop(0)
if arg == "-loop" or arg == "-hq":
pass
elif arg == "-title":
original_args.pop(0)
else:
new_args.append(arg)

#print new_args

os.execv("/usr/bin/ffmpeg", new_args)

Bug#588072: giftui: should this package be removed?

[Simon McVittie]

Source: giftui
Severity: serious
Justification: orphaned, low popcon, inactive upstream
User: debian...@lists.debian.org
Usertags: proposed-removal

giftui seems like a candidate for removal from Debian:

* orphaned
* low and declining popcon
* inactive upstream (last activity was a comment on a bug in 2006)

In addition, since GiFTui is a GUI for file-sharing networks, it's
network-facing (so, potentially security-sensitive), and is not useful if the
networks/protocols it uses are no longer popular (I don't know whether they
are).

If you want to keep this package around in Debian, please adopt it and close
this bug.

If you don't think it's worth keeping, please send the following commands
to cont...@bugs.debian.org, replacing nn with this bug's number:

severity nn normal
reassign nn ftp.debian.org
retitle nn RM: giftui -- RoM; orphaned, low popcon, inactive upstream
thanks 

For more information, see
http://wiki.debian.org/ftpmaster_Removals
http://ftp-master.debian.org/removals.txt

Regards,
smcv


signature.asc
Description: Digital signature

Bug#588488: herrie: pulse alsa backend doesn't work on Lenovo X200s

[Simon McVittie]

Package: herrie
Version: 2.2-2
Severity: normal

I noticed this while doing a QA upload, but uploaded it anyway, since there's
a workaround and the QA upload does fix an RC bug.

On my laptop, I have this in ~/.asoundrc:

pcm.pulse {
type pulse
}
ctl.pulse {
type pulse
}
pcm.!default {
   type pulse
}
pcm.default {
   type pulse
}

herrie fails to play a perfectly normal Ogg Vorbis file (2 channels, 44.1 kHz)
with "Sample rate or amount of channels not supported". When I delete the
third and fourth stanzas from .asoundrc it works fine.

I suspect that my hardware only supports 48 kHz output, and ALSA hardware
output performs some sort of automatic conversion, while the pulse backend
does not. This is on a Lenovo X200s laptop with a
"Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)".

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages herrie depends on:
ii  libasound21.0.23-1   shared library for ALSA applicatio
ii  libc6 2.11.2-2   Embedded GNU C Library: Shared lib
ii  libcurl3-gnutls   7.21.0-1   Multi-protocol file transfer libra
ii  libglib2.0-0  2.24.1-1   The GLib library of C routines
ii  libid3tag00.15.1b-10 ID3 tag reading library from the M
ii  libmad0   0.15.1b-5  MPEG audio decoder library
ii  libmodplug0c2 1:0.8.8-2  shared libraries for mod music bas
ii  libncursesw5  5.7+20100313-2 shared libraries for terminal hand
ii  libsndfile1   1.0.21-2   Library for reading/writing audio 
ii  libspiff4 1.0.0-3library to read/write XSPF, the XM
ii  libvorbisfile31.3.1-1The Vorbis General Audio Compressi

herrie recommends no packages.

herrie suggests no packages.

-- no debconf information


signature.asc
Description: Digital signature

Bug#294308: xfce4-battery-plugin: does not display -- error on startup

[Simon Huggins]

Salut Paul!

On Tue, Feb 08, 2005 at 11:10:20PM -0500, Paul Galbraith wrote:
> After adding the battery plugin to the panel, a space for it is
> displayed but nothing shows in the space.

You should see a rectangle which is thinner than it is tall.  Can you
right click on the space and see the context menu for the plugin?

Do you have ACPI/APM working in your kernel?

> Looking in .xsession-errors, the following error is logged when the
> battery monitor tries to startup:

> (xfce4-session:2911): Gtk-CRITICAL **: file gtkwidget.c: line 1911
> (gtk_widget_destroy): assertion `GTK_IS_WIDGET (widget)' failed

Hmm, I'm not sure this is relevant.  Does it only happen when you add
it?

Simon

-- 
... I've seen code where people play clever ioctl tricks to deduce a device
type and it ends up looking like one of those chemistry identification
charts (hopefully minus do you see smoke ?) -- Alan Cox


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#301745: null pointer dereference in plugin.c:318

[Simon Morgan]

Package: libflash-mozplugin
Version: 0.4.11-2

When viewing http://www.wildgardenseed.com/apkg/flash-demo-install.html
I get the following:

(gdb) r
Starting program: /usr/lib/mozilla-firefox/firefox-bin
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 182943243584 (LWP 14618)]
(no debugging symbols found)
[New Thread 1124071792 (LWP 14626)]
NP_Initialize
New
SetWindow

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182943243584 (LWP 14618)]
NPP_SetWindow (instance=0x143be88, window=0x149e918) at plugin.c:318
318 This->dpy = ws->display;
(gdb) bt full
#0  NPP_SetWindow (instance=0x143be88, window=0x149e918) at plugin.c:318
This = (PluginInstance *) 0x13b3c30
ws = (NPSetWindowCallbackStruct *) 0x0
xwa = {x = -1073764256, y = 127, width = -1789524228, height = 42,
  border_width = 0, depth = 0, visual = 0x1447160, root = 548682049664,
  class = -1789524228, bit_gravity = 42, win_gravity = -1663918256,
  backing_store = 42, backing_planes = 21621016, backing_pixel = 20925248,
  save_under = -1789523630, colormap = 10, map_installed = 0, map_state = 0,
  all_event_masks = 548682048368, your_event_mask = 21621016,
  do_not_propagate_mask = 21216904, override_redirect = 1, screen = 0x0}
#1  0x002a9cd2c16e in Private_SetWindow (instance=0x143be88,
window=0x149e918) at npunix.c:194
err = 0
#2  0x002a9cc03fcb in ?? ()
   from /usr/lib/mozilla-firefox/components/libgkplugin.so
No symbol table info available.


ws gets set from window->ws_info which is NULL. There's a check that
window isn't NULL, but not window->ws_info.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#141825: kyahoo: Receiving the basic smilie :) doesn't show the picture, and there is some text appended to each received line

[Simon Burnet]

Package: kyahoo
Version: 0.7.0-7
Severity: normal

There are two bugs in this report. Both are minor inconveniences.

1) The smilie :) doesn't appear on incoming messages.

2) Some junk is appended after the end of each incoming message. Please
interpret [] as a square box, which I can't include, but it looks something
like:
[];0,0[]0

- Simon.


-- System Information
Debian Release: 3.0
Kernel Version: Linux Nuxtes 2.2.11 #1 Thu Sep 2 01:04:16 BST 1999 i686 unknown

Versions of the packages kyahoo depends on:
ii  kdelibs3   2.2.2-13   KDE core libraries (runtime files)
ii  libc6  2.2.5-3GNU C Library: Shared libraries and Timezone
ii  libjpeg62  6b-5   The Independent JPEG Group's JPEG runtime li
ii  libpng21.0.12-3   PNG library - runtime
ii  libqt2 2.3.1-19   Qt GUI Library (runtime version).
ii  libstdc++2.10- 2.95.4-5   The GNU stdc++ library
ii  xlibs  4.1.0-14   X Window System client libraries
ii  zlib1g 1.1.4-1compression library - runtime


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#160133: svgalib-bin: svgalib seg faults in __svgalib_InitializeAcceleratorInterface()

[Simon Wood]

Package: svgalib-bin
Version: 1:1.4.3-7
Severity: important

svgalib-bin seg faults failing to run all the applications I have tried
on two different machines (Compaq Deskpro XE 560 and Toshiba Satellite
11CS), but correctly works on another (which has an accelerated GFX
card).

GDB session looks like:

hutch:/mnt/microwin-cvs/src# gdb bin/mine
GNU gdb 2002-04-01-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-linux"...(no debugging symbols
found)...
(gdb) run
Starting program: /mnt/microwin-cvs/src/bin/mine
(no debugging symbols found)...(no debugging symbols found)...
[svgalib: allocated virtual console #8]
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x4002a855 in __svgalib_InitializeAcceleratorInterface ()
   from /usr/lib/libvga.so.1
 (gdb)



-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux hutch 2.4.19 #10 Sat Sep 7 17:26:59 BST 2002 i586
Locale: LANG=C, LC_CTYPE=C

Versions of packages svgalib-bin depends on:
ii  libc6 2.2.5-11.1 GNU C Library: Shared libraries an
ii  svgalibg1 1:1.4.3-7  Console SVGA display utilities

Eine Empfehlung von Simon Ziller

[Simon Ziller]

Hallo Alexander!

Ich habe eine super Seite entdeckt, wo man ganz einfach einen Seitensprung
Partner finden kann. Ich habe mir gerade mein Passwort angefordert und kann
die Seite nur weiterempfehlen.
Echt eine super Sache!

Schau einfach auch mal vorbei:
http://www.onlineseitensprung3.tk/


Viele Grüße


Simon Ziller



Diese ePost wurde versendet von: Simon Ziller ([EMAIL PROTECTED])






-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#480318: Description could be better formatted

[Simon Huggins]

Package: bitcollider
Version: 0.6.0-1
Severity: minor

Hi,

Back in February there was a discussion on debian-devel about descriptions
of some packages that include lists which shouldn't be reformatted.
It's at:
http://lists.debian.org/debian-devel/2008/02/msg00695.html

If you look at your package description on:
http://packages.debian.org/unstable/bitcollider
then you can see the problem.

The list in the description gets preformatted in part.

You can prevent this by starting a line in the Description field with two
spaces as per:
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description

The lines in your package that could be fixed are:
 * It examines the file, calculating a distinctive digital fingerprint,
   or bitprint, and taking note of some other identifying information that
   can be extracted from the file, like file length and the local filename.
 * It launches your web browser to do a lookup at our website, submitting
   this identifying information as the search terms.



Thanks
-- 
--("The claw is our master." )--
--(      )--
Simon (  ) Nomis
 Htag.pl 0.0.22



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#480351: Description could be better formatted

[Simon Huggins]

Package: uwm
Version: 0.2.9b-3
Severity: minor

Hi,

Back in February there was a discussion on debian-devel about descriptions
of some packages that include lists which shouldn't be reformatted.
It's at:
http://lists.debian.org/debian-devel/2008/02/msg00695.html

If you look at your package description on:
http://packages.debian.org/unstable/uwm
then you can see the problem.

The list in the description gets reformatted.

You can prevent this by starting a line in the Description field with two
spaces as per:
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Description

The lines in your package that could be fixed are:
 * No title bars with icons etc.
 * High performance, since it just uses standard libraries
Alternatively you can just use one space but separate each item with a
blank line.

Thanks
Simon.

-- 
* "Didn't God give you eyes?" - Mrs Richards "Yes, but I don't use  *
| them 'cos it wears the batteries out." - Polly, Fawlty Towers |
*   *
   Brought to you by the letter A and the number 15



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#496302: d4x: broken Homepage link, shoud use the appropriate control field

[Simon Paillard]

Package: d4x
Version: 2.5.7.1-5
Severity: minor

Hello Klaus,

On Tue, Aug 12, 2008 at 03:47:52PM +0200, Klaus Kehl wrote:
> On http://packages.debian.org/etch/d4x
> and related, the link to
>
> Homepage: http://www.krasu.ru/soft/chuchelo/
> seems to be outdated.

As this info is directly coming from the package itself, I forward your report
to the package maintainer.

By the way, this package should use the field "Homapage:" of debian/control,
see http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Homepage 

Best regards,

-- 
Simon Paillard



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#408135: f-prot-installer: ftp.f-prot.com no longer available -- installation fails

[Simon Walter]

Package: f-prot-installer
Severity: important

Downloading f-prot from ftp.f-prot.org is no longer possible.
See ftp://ftp.f-prot.com/pub/README.TXT

http://www.fprot.org/pub/ would be an alternative but they don't
provide a md5 file.

--
Regards
Simon

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages f-prot-installer depends on:
ii  debconf [debconf-2.0] 1.5.11 Debian configuration management sy
ii  debianutils   2.17.5 Miscellaneous utilities specific t
ii  libwww-perl   5.805-1WWW client/server library for Perl
ii  unzip 5.52-9 De-archiver for .zip files
ii  wget  1.10.2-2   retrieves files from the web

f-prot-installer recommends no packages.

-- debconf information:
* f-prot-installer/reinstall: true
* f-prot-installer/update_defs: true
  f-prot-installer/install_later:
* f-prot-installer/action: Download and install
* f-prot-installer/configured: false
  f-prot-installer/note_cron:
  f-prot-installer/where_are_files: /tmp
  f-prot-installer/failed:


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#412782: could it be that it depends on kdebase-bin

[Simon Effenberg]

Hi there,

I tried this scenario an it also crashes..

But on the console there was also this line:


Could not find 'drkonqi' executable.


So 'rekall' depends on kdebase-bin in which drkonqi is placed.. this
should be corrected.

So do you have 'kdebase-bin' installed and if not, is this a
sollution of you problem?

For me it was not. After installing kdebase-bin and selecting a
storage database type it crashes not immediately but by clicking on
"next" i got an SigSev.

This is the End of the Backtrace:

--- BEGIN ---
[KCrash handler]
#9  0xb7c13a63 in _el_newvar () from /usr/lib/libel_compile.so.0
#10 0xb7c1892e in el_yyparse () from /usr/lib/libel_compile.so.0
#11 0xb7c136b2 in el_compile () from /usr/lib/libel_compile.so.0
#12 0xb7e55f79 in KBWizardPage::compile () from /usr/lib/libkbase.so.0
#13 0xb7e56085 in KBWizardPage::nextPage () from /usr/lib/libkbase.so.0
#14 0xb7e63f42 in KBWizard::clickNext () from /usr/lib/libkbase.so.0
#15 0xb7e53cbd in KBWizard::qt_invoke () from /usr/lib/libkbase.so.0
#16 0xb6c23d4f in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#17 0xb6c247e0 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#18 0xb6fb5de7 in QButton::clicked () from /usr/lib/libqt-mt.so.3
#19 0xb6cc0cf6 in QButton::mouseReleaseEvent () from /usr/lib/libqt-mt.so.3
#20 0xb6c5a6f0 in QWidget::event () from /usr/lib/libqt-mt.so.3
#21 0xb6bbbc26 in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3
#22 0xb6bbddc9 in QApplication::notify () from /usr/lib/libqt-mt.so.3
#23 0xb737fe0e in KApplication::notify () from /usr/lib/libkdecore.so.4
#24 0xb6b4f495 in QApplication::sendSpontaneousEvent ()
   from /usr/lib/libqt-mt.so.3
#25 0xb6b4e12f in QETWidget::translateMouseEvent () from /usr/lib/libqt-mt.so.3
#26 0xb6b4c6b0 in QApplication::x11ProcessEvent () from /usr/lib/libqt-mt.so.3
#27 0xb6b62d02 in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3
#28 0xb6bd6179 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3
#29 0xb6bbd73d in QApplication::enter_loop () from /usr/lib/libqt-mt.so.3
#30 0xb6dd7181 in QDialog::exec () from /usr/lib/libqt-mt.so.3
#31 0xb7e63e95 in KBWizard::exec () from /usr/lib/libkbase.so.0
#32 0xb7f59f4b in KBWizardConnect::exec () from /usr/lib/librekall.so.0
#33 0xb7f2e369 in KBaseApp::newDatabase () from /usr/lib/librekall.so.0
#34 0xb7f30239 in KBDirector::newDatabase () from /usr/lib/librekall.so.0
#35 0xb7f309af in KBDirector::qt_invoke () from /usr/lib/librekall.so.0
#36 0xb6c23d4f in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#37 0xb6c24656 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#38 0xb7b68fb0 in TKAction::activated () from /usr/lib/libkbase_kde.so.0
#39 0xb7b68fe4 in TKAction::slotActivated () from /usr/lib/libkbase_kde.so.0
#40 0xb7b68f12 in TKAction::qt_invoke () from /usr/lib/libkbase_kde.so.0
#41 0xb6c23d4f in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#42 0xb6c247e0 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#43 0xb7559259 in KAction::activated () from /usr/lib/libkdeui.so.4
#44 0xb758e971 in KAction::slotActivated () from /usr/lib/libkdeui.so.4
#45 0xb766ecfd in KAction::slotPopupActivated () from /usr/lib/libkdeui.so.4
#46 0xb766efc1 in KAction::qt_invoke () from /usr/lib/libkdeui.so.4
#47 0xb6c23d4f in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#48 0xb6facd97 in QSignal::signal () from /usr/lib/libqt-mt.so.3
#49 0xb6c438d2 in QSignal::activate () from /usr/lib/libqt-mt.so.3
#50 0xb6d48d59 in QPopupMenu::mouseReleaseEvent () from /usr/lib/libqt-mt.so.3
#51 0xb75620ee in KPopupMenu::mouseReleaseEvent () from /usr/lib/libkdeui.so.4
#52 0xb6c5a6f0 in QWidget::event () from /usr/lib/libqt-mt.so.3
#53 0xb6bbbc26 in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3
#54 0xb6bbddc9 in QApplication::notify () from /usr/lib/libqt-mt.so.3
#55 0xb737fe0e in KApplication::notify () from /usr/lib/libkdecore.so.4
#56 0xb6b4f495 in QApplication::sendSpontaneousEvent ()
   from /usr/lib/libqt-mt.so.3
#57 0xb6b4de88 in QETWidget::translateMouseEvent () from /usr/lib/libqt-mt.so.3
#58 0xb6b4c6b0 in QApplication::x11ProcessEvent () from /usr/lib/libqt-mt.so.3
#59 0xb6b62d02 in QEventLoop::processEvents () from /usr/lib/libqt-mt.so.3
#60 0xb6bd6179 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3
#61 0xb6bd5f9a in QEventLoop::exec () from /usr/lib/libqt-mt.so.3
#62 0xb6bbd7bf in QApplication::exec () from /usr/lib/libqt-mt.so.3
#63 0xb7f28898 in rekallMain () from /usr/lib/librekall.so.0
#64 0x08048718 in ?? ()
#65 0x0001 in ?? ()
#66 0xbfec18e4 in ?? ()
#67 0x in ?? ()
 END --

Don't know if it helps.

Best Regards
Simon


--
GnuPG: 5755FB64

Per aspera ad astra.


pgpzb0kiI66YG.pgp
Description: PGP signature

Bug#417078: FTBFS with GCC 4.3: missing #includes

[Simon Peter]

> Your package fails to build with GCC 4.3.  Version 4.3 has not been

Thanks for spotting this! The exit() call is superfluous and can
simply be removed (ad_initial() needs to be called though). I fixed
this in upstream CVS.

I hope this gets propagated into Debian somehow, since the package is
orphaned AFAIK. I'd really love to have it in Debian though.

Simon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#348983: New version 0.9.12 available

[Simon Schmitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: re2c
Version: 0.9.10
Severity: minor

There is a new version 0.9.12 available since 2005-12-28.
E.g. building PDO_MYSQL needs it.


Simon
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (MingW32)

iD8DBQFD0KJ+pviYlW58Ck8RAjXDAKDGaRdIPKftHph2NuficT7zQd9pOACgmGv4
9cFzLclf3WgJz7z2kTpd/Os=
=vhGY
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#356097: laptop-netconf: French debconf templates translation update

[Simon Paillard]

Package: laptop-netconf
Severity: wishlist
Tags: patch l10n

Please find attached the french debconf templates update, proofread by the
debian-l10n-french mailing list contributors.

Best regards,

-- 
Simon Paillard
#
#Translators, if you are not familiar with the PO format, gettext
#documentation is worth reading, especially sections dedicated to
#this format, e.g. by running:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
#Some information specific to po-debconf are available at
#/usr/share/doc/po-debconf/README-trans
# or http://www.debian.org/intl/l10n/po-debconf/README-trans
#
#Developers do not need to manually edit POT or PO files.
#
msgid ""
msgstr ""
"Project-Id-Version: laptop-netconf 0.9.6.4\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2004-05-20 23:26+0200\n"
"PO-Revision-Date: 2006-02-24 21:07+0100\n"
"Last-Translator: Simon Paillard <[EMAIL PROTECTED]>\n"
"Language-Team: French \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=ISO-8859-15\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../templates:4
msgid "Proceed and activate laptop-netconf?"
msgstr "Voulez-vous continuer et activer laptop-netconf ?"

#. Type: boolean
#. Description
#: ../templates:4
msgid ""
"laptop-netconf does not yet appear to be active.  Activating it will bring "
"the following network configuration files under its control:"
msgstr ""
"Laptop-netconf ne semble pas encore activé. En l'activant, les fichiers "
"de configuration du réseau suivants passeront sous son contrôle :"

#. Type: boolean
#. Description
#: ../templates:4
msgid ""
"  /etc/resolv.conf\n"
"  /etc/network/interfaces"
msgstr ""
" - /etc/resolv.conf\n"
" - /etc/network/interfaces"

#. Type: boolean
#. Description
#: ../templates:4
msgid ""
"If you do choose to activate laptop-netconf, then your existing files will "
"be backed up automatically.  However, you are well advised to make your own "
"copy of these files."
msgstr ""
"Si vous choisissez d'activer laptop-netconf, les fichiers existants "
"seront automatiquement sauvegardés. Cependant, vous devriez faire "
"vous-même une sauvegarde de ces fichiers."

#. Type: boolean
#. Description
#: ../templates:4
msgid "DO NOT PROCEED UNLESS YOU HAVE ALREADY CONFIGURED LAPTOP-NETCONF"
msgstr "Ne continuez pas à moins d'avoir déjà configuré laptop-netconf."

Bug#363227: Spelling mistake in package description

[Simon Waters]

Package: dcgui
Severity: minor



*** diff/dcgui
20c20
<  administators to require clients to share specified amount of data. The
---
>  administrators to require clients to share specified amount of data. The


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15.2
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#363588: Spelling mistake in package description

[Simon Waters]

Package: gandalf1
Severity: minor



*** diff/gandalf1
21c21
<   objects (sizes 2,3,4) and general size vetors & matrices. The
---
>   objects (sizes 2,3,4) and general size vectors & matrices. The
30c30
<   Some useful vision utitily modules, including edge/line/corner
---
>   Some useful vision utility modules, including edge/line/corner


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15.2
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#363596: Spelling mistake in package description

[Simon Waters]

Package: gandalf-dev
Severity: minor



*** diff/gandalf-dev
21c21
<   objects (sizes 2,3,4) and general size vetors & matrices. The
---
>   objects (sizes 2,3,4) and general size vectors & matrices. The
30c30
<   Some useful vision utitily modules, including edge/line/corner
---
>   Some useful vision utility modules, including edge/line/corner


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15.2
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#363977: Spelling mistake in package description

[Simon Waters]

Package: iroffer
Severity: minor



*** diff/iroffer
18c18
<  speed and effeciency in mind. iroffer has been known to reach
---
>  speed and efficiency in mind. iroffer has been known to reach
20c20
<  occuring at the same time.
---
>  occurring at the same time.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15.2
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#381543: multi-gnome-terminal: Fails to work with pam_tmpdir enanbled

[Simon Brandmair]

Package: multi-gnome-terminal
Version: 1.6.2-12
Severity: important

When pam_tmpdir is enabled, mgt fails to start:
Failed to open CORBA cookie file `/tmp/orbit-simi/cookie': No such file or 
directory
Failed to obtain CORBA authentication cookie, exiting

It seems like it is looking in the wrong place, since the tmp files are now 
under /tmp/user/.

To reproduce:
1. Install libpam-tmpdir
2. Add "session optional pam_tmpdir.so" to /etc/pam.d/common-session

Workaround:
Don't enable pam_tmpdir


Cheers,
Simon



-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.16-20060805
Locale: LANG=en_CA, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)

Versions of packages multi-gnome-terminal depends on:
ii  debconf1.4.30.13 Debian configuration management sy
ii  gdk-imlib111.9.14-30 imaging library for use with gtk
ii  libart21.4.2-19  The GNOME canvas widget - runtime 
ii  libaudiofile0  0.2.6-6   Open-source version of SGI's audio
ii  libc6  2.3.6-15  GNU C Library: Shared libraries
ii  libdb3 3.2.9-25  Berkeley v3 Database Libraries [ru
ii  libesd00.2.36-3  Enlightened Sound Daemon - Shared 
ii  libglade-gnome01:0.17-5  Library to load .glade files at ru
ii  libglade0  1:0.17-5  Library to load .glade files at ru
ii  libglib1.2 1.2.10-9  The GLib library of C routines
ii  libgnome32 1.4.2-32  The GNOME libraries
ii  libgnomesupport0   1.4.2-32  The GNOME libraries (Support libra
ii  libgnomeui32   1.4.2-32  The GNOME libraries (User Interfac
ii  libgnorba271.4.2-32  GNOME CORBA services
ii  libgtk1.2  1.2.10-18 The GIMP Toolkit set of widgets fo
ii  libice61:1.0.0-3 X11 Inter-Client Exchange library
ii  liborbit0  0.5.17-11.1   Libraries for ORBit - a CORBA ORB
ii  libpopt0   1.10-2lib for parsing cmdline parameters
ii  libsm6 1:1.0.0-4 X11 Session Management library
ii  libwrap0   7.6.dbs-8 Wietse Venema's TCP wrappers libra
ii  libx11-6   2:1.0.0-7 X11 client-side library
ii  libxext6   1:1.0.0-4 X11 miscellaneous extension librar
ii  libxi6 1:1.0.0-5 X11 Input extension library
ii  libxml11:1.8.17-10   GNOME XML library
ii  zlib1g 1:1.2.2-4.sarge.2 compression library - runtime

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#381543: multi-gnome-terminal: Fails to work with pam_tmpdir enanbled

[Simon Brandmair]

On 05.08.2006 13:07 (Saturday), Matej Vela wrote:

Simon Brandmair <[EMAIL PROTECTED]> writes:
> When pam_tmpdir is enabled, mgt fails to start:
> Failed to open CORBA cookie file `/tmp/orbit-simi/cookie': No such file or
directory
> Failed to obtain CORBA authentication cookie, exiting

Does the same error appear when you run goad-browser?


Yes, exactly the same error message.

Cheers,
Simon

Bug#390054: Spelling mistake in package description

[Simon Waters]

Package: malaga-doc
Severity: minor



*** diff/malaga-doc
27c27
<  viewers.  The malaga-bin package contains documentian in
---
>  viewers.  The malaga-bin package contains documentation in


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15.2
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#390055: Spelling mistake in package description

[Simon Waters]

Package: mambo
Severity: minor



*** diff/mambo
16c16
<  Aimed for builing pretty cool websites, Mambo Server Open Source is a CMS
---
>  Aimed for building pretty cool websites, Mambo Server Open Source is a CMS


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15.2
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: relative to lists.debian.org right now

[Ronnie Simon]

How are you,

100% safe herbal solution

http://geocities.com/Jeanette28_b335/

Build your semen by 400%

Thank you,
Ronnie Simon



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#382784: Missing LDFLAGS for wallpaper-tray package

[Simon Waters]

>> if wallpaper-tray was started from a shell:
>> ...
>> (wp_tray:9752): libglade-WARNING **: could not find signal handler
'on_button_close_pressed'.

A little searching suggests that this bug is due to a missing linker option.

In particular in the src/Makefile the loader needs flags
"-Wl,-export-dynamic", as explained here;

http://mail.gnome.org/archives/gtk-app-devel-list/2005-November/msg00087.html

I have rebuilt wallpaper-tray with the 0.5.1 tarball, and apart from the
"tarball" being named "wp_tray" rather than "wallpaper_tray", it is
possible to recreate the debian package using the regular commands, but
the same bug is still present.

If I then hack the src/Makefile ldflags to read:

wp_tray_LDFLAGS = -Wl,-export-dynamic

"cd src"
"make clean"
"make"
./wp_tray

Then the application works as expected.

I assume that something should be placed in configure.in, or one of the
 GNOME m4 macros, so that applications using Glade export the signal
handlers correctly, or possibly the whole approach has been superseded
in some way?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#346212: Still not fixed

[Simon Walter]

this bug is still not fixed in 4.57.6
suggested patch is present but commented out

see Exim.pm L442:
#BROKEN # strips new "special" content >= 4.10
#BROKEN $line =~ s/ (\d+),\d+#01$//;
#BROKEN if (defined $1) {
#BROKEN   $line = substr($line, 0, length($line)-$1-1);
#BROKEN }



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#401329: Mailscanner logrotate and crondaily scripts

[Simon Walter]

I don't think mailscanners cron.daily or logrotate should do anything
MTA specific. A better solution would be to change the exim
installation manual, so exim handles /var/spool/exim like it should and another
cron.daily script handles the manual created /var/spool/exim_x
directory.

I have appended a tar.gz file with a new README.exim4 and the
necessary files.

--
Regards
Simon



mailscanner_exim.tar.gz
Description: Binary data