Bug#1007724: no locking at all

[Tormod Volden]

VA, please provide a tested patch against our VCS
https://salsa.debian.org/debian/xscreensaver
thanks

Bug#991900: prism2-usb-firmware-installer: missing Depends: ca-certificates

[Tormod Volden]

Hi Andreas,

Thanks for the report. The package already depends on wget, which
recommends ca-certificates, so this only affects users that have
decided (against the recommendation) to not install this.

In any case, the expected retrieved file has a known checksum (the
whole downloading dance is to avoid redistribution legal issues) so
I'll change it to use wget --no-check-certificate and subsequently
checksum the retrieved file. As long as the file is the same, we don't
care so much who actually delivered it :) This solution should work
for everyone, and in your case you will get a warning instead of an
error.

Regards,
Tormod

Bug#987149: xscreensaver: allows starting external programs with cap_net_raw

[Tormod Volden]

This issue is marked as affecting 5.42+dfsg1-1 in buster (and even
stretch) in our CVE tracker, however the set_cap action was first
added in 5.44+dfsg1-1.

https://security-tracker.debian.org/tracker/CVE-2021-31523

Tormod

Bug#989508: xscreensaver: Disconnecting a video output can cause XScreenSaver to crash and unlock

[Tormod Volden]

This issue is marked as affecting 5.42+dfsg1-1 in buster (and even
stretch) in our CVE tracker, however the openwall report says:

"The issue affects only XScreenSaver version 5.45. Versions 5.44 and
older, as well as 6.00, are not affected."

Tormod

Bug#987149: xscreensaver: diff for NMU version 5.45+dfsg1-1.1

[Tormod Volden]

On Sun, Jun 6, 2021 at 11:57 AM Salvatore Bonaccorso wrote:
>
> I've prepared an NMU for xscreensaver (versioned as 5.45+dfsg1-1.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
>

I saw this now. I would of course prefer to have my 5.45+dfsg1-2
uploaded instead. I'll also look at including a fix for #989508 at the
same time.

BTW, WRT to your comment in your patch, please note that the real
issue is in mesa and xscreensaver 6 simply reverts back to use setuid
instead of using capabilities. So if the libcap removal should be seen
as something temporary, it must be until it gets fixed in mesa, and
not until xscreensaver 6 (in case it would be a permanent removal).

Regards,
Tormod

Bug#987149: xscreensaver: allows starting external programs with cap_net_raw

[Tormod Volden]

Hi Salvatore and Andrew,

I have prepared a xscreensaver 5.45+dfsg1-2 (which removes the setcap)
in git. Andrew is my regular sponsor. Andrew, can you please upload
this version? Or if you have no time, can Salvatore do it?

Best regards,
Tormod

On Sat, Jun 5, 2021 at 3:08 PM Salvatore Bonaccorso  wrote:
>
> Hi Tormod,
>
> On Thu, May 06, 2021 at 07:38:34PM +0200, Moritz Mühlenhoff wrote:
> > Am Mon, Apr 19, 2021 at 11:42:54AM +0200 schrieb Moritz Muehlenhoff:
> > > On Sun, Apr 18, 2021 at 07:21:31PM +0200, Tormod Volden wrote:
> > > > Yes, I think dropping the set_cap is the easy way out of here. sonar
> > > > will still be visually pleasing, just not so interesting.
> > >
> > > Let's do that for buster/bullseye? And when xscreensaver gets updated to 
> > > 6.00
> > > after the release, it can be re-enabled?
> >
> > *ping* :-)
>
> Time is starting to get very close to the bullseye release now. Did
> you got a chance to look into preparing the above changes?
>
> Regards,
> Salvatore

Bug#987149: xscreensaver: allows starting external programs with cap_net_raw

[Tormod Volden]

On Sun, Apr 18, 2021 at 7:04 PM Salvatore Bonaccorso wrote:
> Sure I did as I'm on the team alias as well. Given it looks unlikely
> that mesa will fix it (at the moment?) I though/think we should
> probably do something on xscreensaver's side in Debian as well.
>
> Is the sonar screensaver frequently used? How about dropping it
> instead? Thinking about it in the last hour this raised to be a
> possible option to not expose the bug.

Yes, I think dropping the set_cap is the easy way out of here. sonar
will still be visually pleasing, just not so interesting.

I don't think we should wait for upstream mesa to fix this, but can't
we just patch Debian mesa with getauxval() checks? Since mesa
currently does the geteuid check, it seems logical to fix it there
also for other situations than sonar.

On Sun, Apr 18, 2021 at 7:15 PM Salvatore Bonaccorso wrote:
> Another option would be to extract the needed changes from 6.00
> upstream accordingly if the thread in
> https://www.openwall.com/lists/oss-security/2021/04/17/1 gives us no
> other solutions.

Sure, if that is easily backportable we should do it. I haven't looked
at it though so I cannot tell.

Tormod

Bug#987149: xscreensaver: allows starting external programs with cap_net_raw

[Tormod Volden]

Indeed, as Jamie points out, the problem is in Mesa.

Salvatore, why did you file this against xscreensaver? I thought you
had followed the e-mail discussion we had with Tavis?

Tormod

Bug#979562: lightdm session termination does not stop xscreensaver

[Tormod Volden]

OK, so I guess removing the global user enablement will avoid having
xscreensaver running in lightdm. However, I still wonder if this
lingering service that was observed will also be the case if a user
logs out and another (or same) logs in within 15 seconds? Is there
still an underlying issue here, that can affect security? Is it just
nornal that the systemd user "session" runs for a while after the user
logs out, which would mean the systemd user service is not suited for
this?

Also, Michael asked "Is xscreensaver really usable as a per user
service or should it be per session?". How can it be run per session?
Would it mean getting graphical-session.target to work for non-Gnome
sessions? Are there other systemd mechanisms, or does per-session mean
not using systemd?

Tormod

Bug#979562: lightdm session termination does not stop xscreensaver

[Tormod Volden]

On Sun, Jan 10, 2021 at 5:46 PM Michael Biebl wrote:
> If you want to clean up this state, I would propose to use the following
>
> deb-systemd-helper --user purge xscreensaver.service >/dev/null || true
> deb-systemd-helper --user unmask xscreensaver.service >/dev/null || true
>
> Guarded by a version check.
> This will remove the (global) enablement symlink and purge the
> init-system-helpers state.

Thanks, I'll add
if [ "$1" = "configure" ] && [ "$2" = "5.44+dfsg1-2" -o "$2" =
"5.45+dfsg1-1" ]; then ... fi
around it.

Tormod

Bug#979562: lightdm session termination does not stop xscreensaver

[Tormod Volden]

I should add that although we added the
debian/xscreensaver.user.service file in 5.44+dfsg1-2, we are using
"dh_installsystemduser --no-enable" since 5.45+dfsg1-1, so it won't be
enabled for the lightdm user in new installs or upgrades skipping
5.44+dfsg1-2. It will now only be enabled for those individual users
who themselves enable it as described in README.Debian. So adding the
ConditionUser=!@system to the unit now won't help us much - only if
someone got it globally enabled by 5.44+dfsg1-2. I guess we instead
should explicitly disable it globally in xscreensaver.postinst to
clean this up for those who had 5.44+dfsg1-2 installed.

I will add a warning in README.Debian (and debian/changelog) that the
systemd unit is not recommended for now.

Tormod

Bug#979562: lightdm session termination does not stop xscreensaver

[Tormod Volden]

On Sun, Jan 10, 2021 at 12:44 PM Michael Biebl  wrote:

> Negating @system might work.
> Something like ConditionUser=!@system, but untested.

Thanks! I was just about to suggest this myself after searching around for this.
(https://www.freedesktop.org/software/systemd/man/systemd.unit.html)

I also wonder if PartOf=graphical-session.target would make sure the
service is stopped when the X sessions stops.
(https://www.freedesktop.org/software/systemd/man/systemd.special.html#)

And maybe we should replace WantedBy=default.target by more specific
DEs, like WantedBy=xfce-session.target. I'd expect e.g. Gnome to start
its own screensaver by default.

I also see that the systemd user task is per-user, not per-session.
Wonder what happens if a user log in twice...
"Problematic" according to https://systemd.io/DESKTOP_ENVIRONMENTS/

Tormod

Bug#979562: lightdm session termination does not stop xscreensaver

[Tormod Volden]

On Fri, Jan 8, 2021 at 10:00 PM Jamie Zawinski wrote:
>
> > In xscreensaver (or maybe lightdm).
> > Why is xscreensaver started in the lightdm session anyway?
> > Is xscreensaver really usable as a per user service or should it be per 
> > session?
> > Why is the lightdm xscreensaver instance interfering with the xscreensaver 
> > instance of the logged in user?
> > Questions that only the xscreensaver maintainer can answer.
> >
> > If he thinks there is a genuine systemd issue, then I'd appreciate if it 
> > was reassigned back with more details.
>
> XScreenSaver author here. I know nothing about lightdm, and didn't write the 
> code attempting to integrate the two. However:
>
> 1) XScreenSaver should be running as the logged-in user, and terminate when 
> they log out. Typically this happens when the X server dies and the $DISPLAY 
> socket is closed, but SIGTERM works just as well.
>
> 2) It is also reasonable to configure things so that XScreenSaver is running 
> when no one is logged in (so that there is a screensaver atop the login 
> screen). If it is launched as root, it will setuid to "nobody" at startup, 
> etc. But in this case, when a user logs in, it must be killed and re-started 
> as that user.

It was not intentional from my side to have it run in the login window
by default. We used to just ship a systemd unit file that a user could
install if he wanted. Recently, in 5.44+dfsg1-2, we added the
debian/*.user.service file, it was part of a debhlper clean-up from my
package upload sponsor and I didn't foresee the implications.
"lightdm" is a system user (UID < 1000), is possible to have systemd
have it start only for "normal" users?

Many users will expect xscreensaver to start automatically in all
their sessions after installing the xscreensaver package. For a
multi-user host the administrator expectations are different, since
there might be various login managers and user desktop environments,
and xscreensaver should only run in some of them. Not sure how to find
the one-size-fits-all.

Tormod

Bug#967232: xscreensaver: Unversioned Python removal in sid/bullseye

[Tormod Volden]

I think this is solely through the build dependency on libglade2-dev
so this will be solved by xscreensaver getting rid of this dependency
(bug #967892) or by libglade2 getting rid of its python dependency
(bug #895517):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895517#14

Bug#953098: xscreensaver: Crashes with XIO: fatal IO error

[Tormod Volden]

I was running xscreensaver continuously for a couple of months but
could not reproduce. If nobody else can reproduce and you cannot
provide more information I must at least lower the severity of this
bug report.

Regards,
Tormod


On Thu, Mar 26, 2020 at 10:29 PM Tormod Volden wrote:
>
> Jens, the log indicates the machine has an Intel(R) HD Graphics 530
> (Skylake GT2) GPU. Is this the same for the other machines? I have
> been trying to reproduce for several days, also running on Intel
> drivers, but with a 5500 series GPU and also I am on "testing" so I
> have newer Xorg and kernel.
>
> Tormod

Bug#953098: xscreensaver: Crashes with XIO: fatal IO error

[Tormod Volden]

Jens, the log indicates the machine has an Intel(R) HD Graphics 530
(Skylake GT2) GPU. Is this the same for the other machines? I have
been trying to reproduce for several days, also running on Intel
drivers, but with a 5500 series GPU and also I am on "testing" so I
have newer Xorg and kernel.

Tormod

Bug#953098: xscreensaver: Crashes with XIO: fatal IO error

[Tormod Volden]

Jens, can you please also attach an Xorg log from the crash? If I
understand the original report right, the X session continued
otherwise as normal, so I guess the X server didn't crash. It could
have run out of memory temporarily, or xscreensaver requested
something out of reach, like loads of memory.

Does the timestamp on your log indicate that xscreensaver died just
after killing molecule?

xscreensaver also has a -sync option to help debug X troubles,
although I don't know if it can help here, can you try with that?

Tormod

On Sat, Mar 14, 2020 at 9:51 PM Jamie Zawinski  wrote:
>
> As far as I know, an XIO error means the X server dropped the connection to 
> the xscreensaver client. So either the X server itself crashed, or it decided 
> to disconnect xscreensaver for some unknown reason.
>
> If the client had done something wrong, X11-protocol-wise, this would have 
> been a more verbose "X" error, not an "XIO" error.
>
> Maybe this is the kernel OOM-killer shooting down random long-running 
> processes, as it sometimes likes to do?
>
> "Resource temporarily unavailable" sure sounds like it could be the X11 
> server trying to say that it ran out of memory.

Bug#876087: xscreensaver: source-less and unlicensed code at hacks/images/m6502/dmsc.asm

[Tormod Volden]

On Sun, Sep 24, 2017 at 9:02 PM, Daniel Serpell wrote:
> Attached is the source to the demo, in 6502 assembly, with a GPL
> license.

Daniel and Daniel,
Thanks a lot for sorting this out. Sometimes someone just has to ask
and it is as easy as that.

Regards,
Tormod

Bug#873108: xscreensaver does not trap errors from intltool-update

[Tormod Volden]

On Thu, Aug 24, 2017 at 6:00 PM, Helmut Grohne  wrote:
> Source: xscreensaver
> Version: 5.36-1
> Severity: serious
> Justification: policy 4.6
> User: helm...@debian.org
> Usertags: rebootstrap
>
> The debian policy section 4.6 requires that when build commands fail,
> the build should abort. In case xscreensaver's intltool-update aborts,
> the error is ignored and the build attempts to continue potentially
> resulting in a broken package. Adding "set -e; " (as suggested by the
> policy) or chaining the commands with "&&" fixes this issue.

Hi Helmut,
In which cases can the inttool-update fail on Debian? In any case, I
have nothing against adding set -e if that can help.

Regards,
Tormod

Bug#822049: linux-wlan-ng: Build arch:all+arch:any but is missing build-{arch,indep} targets

[Tormod Volden]

tags 822049 pending
thanks

Hi Santiago,

On Fri, Jul 29, 2016 at 2:19 AM, Santiago Vila wrote:
>
> I also recommend switching to dh, but in the meantime, the attached
> patch should work.

Thanks! I have actually prepared a new release of linux-wlan-ng which
fixes this among other things, but it is waiting for my sponsor. It
would be nice if you can verify the relevant changes:

https://anonscm.debian.org/cgit/collab-maint/linux-wlan-ng.git/

Comparing with your patch, I see that I can add the new targets to .PHONY.

Best regards,
Tormod

Bug#820105: xscreensaver: please consider removal from sid

[Tormod Volden]

severity 820105 wishlist
thanks

I don't know if the reason for suggesting "grave" severity here was to
make it an RC bug, but otherwise grave means:

"makes the package in question unusable or mostly so, or causes data
loss, or introduces a security hole allowing access to the accounts of
users who use the package."

which definitely doesn't apply at all. Actually looking at the
technical criteria, there is no "violation", "usability" or
"usefulness" issues. Setting severity accordingly.

Bug#820105: xscreensaver: please consider removal from sid

[Tormod Volden]

On Tue, Apr 5, 2016 at 3:48 PM, Steven Chamberlain wrote:
> The upstream maintainer of xscreensaver has explicitly asked Debian
> to stop shipping it, which is a shame of course:
> https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/

Hi Steven,

The above post was a response to a heated discussion in bug #819703
which was dominated and poisoned by trolls not representative of the
Debian community and definitely not by the package maintainer. It is
understandable that the upstream author got upset. On our side we must
not consider emotional outbursts in our decisions, but let things cool
down and look at the facts.

Of course, he dislikes the ways some things are done in Debian, but
that is nothing new, and is shared by many within the Debian community
for that sake.

>
> It *is* still a free software project, based on freely-licensed works of
> many authors.  Debian obviously may choose to ship it in any case, and
> I'm sure it will continue to do so in wheezy-lts and jessie.

Most definitely. We cannot rip out an important part of the desktop in
a stable distribution.

>
> Removal from sid did sound extreme to me at first, but going forward,
> software projects do need an upstream maintainer, and currently he
> chooses to be hostile:
>
> Bug #819703 was a deliberate annoyance / anti-feature that impacted many

It was of very low impact and simply a small annoyance. The emotional
response to this was way over board.

> of our users, and will create work for the package maintainer and stable
> release managers to resolve.  Even if it is only minor, it would not

Minor indeed.

> stand if Debian allowed that sort of thing to proliferate in all
> software in its stable releases.

If you fear that other upstreams would like to follow up and do the
same, we have a general problem, not particularly with XScreenSaver.

>
> CVEs are not filed for security bugs and code commits don't seem to be
> split out individually in any public repository, making security support
> in stable releases problematic.  (similar to the Oracle-MySQL situation)

The upstream author has been sending us (the package maintainers)
notices of security bugs in private e-mail. Take the example of the
famous incident last year, thanks to Jamie we had patched Debian
almost as soon as he discovered the issue.

The security fixes can normally be extracted and backported to stable,
as long as we know about them, of course. Which happened for stable
without further complication in this example.

>
> Newer upstream versions add advertising for the upstream maintainer's
> commercial ventures.  The logos of DNA Lounge, DNA Pizza and Codeword

The pizza logo was added to the code in 5.18, some 8 years ago? It is
referenced by the dnalogo hack, which is not even built. If you see
any DFSG non-free stuff in our packages, please refer to bug reports.

> seem likely to be non-free by the DFSG.  Their removal could further
> incense the upstream maintainer, more-so than removing the package.

This is pure speculation, not to base decisions on. Actually I don't
think we have ever shipped the DNA logo hack. I don't even think it is
built by default. We do remove it from the X11 app-default file,
because there is no corresponding binary. This has never been a topic
between us and upstream.

Generally, talking for the maintainers over the last years (I have
been involved since 2007), we have an excellent relation with
upstream. He doesn't approve of all decisions and compromises that we
end up having to do in the packaging, however we share a common goal
of giving a large audience access to an excellent piece of software.

>
> Thanks for your consideration.

I think I have considered the request carefully, and I don't see it
worth to take this further at the moment. If the factual situation
changes, I will review it. For now I don't think we should be carried
away by emotions and escalate it to a larger problem than it has to
be.

Regards,
Tormod

Bug#767019: xscreensaver: postinst overwrites /etc/X11/app-defaults/XScreenSaver without asking

[Tormod Volden]

tags 767019 pending
thanks

On Mon, Jan 26, 2015 at 7:45 PM, Alex Goebel wrote:
 On Sat, Dec 20, 2014 at 9:02 AM, Michael Gilbert wrote:

if [ -L /etc/X11/app-defaults/XScreenSaver ]; then
   if [ $(readlink /etc/X11/app-defaults/XScreenSaver) =
 XScreenSaver-nogl -o \
 $(readlink /etc/X11/app-defaults/XScreenSaver) =
 XScreenSaver-gl]; then
rm /etc/X11/app-defaults/XScreenSaver
 fi


 This doesn't handle the case where the user intentionally had both
 xscreensaver-gl and xscreensaver installed, and manually set the
 symlink to XscreenSaver-nogl.

Yes, it leaves this corner case unresolved, but it is still a huge
improvement from the current situation. If anyone cares, please file a
new bug for the corner case.


 Mhm, couldn't we apply this part of the patch and at least make this bug
 less RC that way?

I have applied this and some other parts from Bastien's patch. Thanks
a lot Bastien!

http://anonscm.debian.org/cgit/collab-maint/xscreensaver.git/commit/?id=0eea212ec5deae3f3b10e57d8436e039c6d486b1

Best regards,
Tormod


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

Bug#767019: xscreensaver: postinst overwrites /etc/X11/app-defaults/XScreenSaver without asking

[Tormod Volden]

On Sat, Dec 20, 2014 at 9:02 AM, Michael Gilbert wrote:

if [ -L /etc/X11/app-defaults/XScreenSaver ]; then
   if [ $(readlink /etc/X11/app-defaults/XScreenSaver) = 
 XScreenSaver-nogl -o \
 $(readlink /etc/X11/app-defaults/XScreenSaver) = 
 XScreenSaver-gl]; then
rm /etc/X11/app-defaults/XScreenSaver
 fi

 This doesn't handle the case where the user intentionally had both
 xscreensaver-gl and xscreensaver installed, and manually set the
 symlink to XscreenSaver-nogl.


I suppose it would be best to treat XscreenSaver-nogl and
XscreenSaver-gl as conffiles. But I am not sure about the symlink. It
could fit something like update-alternatives, but that is not meant
for configuration files, right?

Best regards,
Tormod


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

Bug#767019: xscreensaver: postinst overwrites /etc/X11/app-defaults/XScreenSaver without asking

[Tormod Volden]

On Mon, Oct 27, 2014 at 6:42 PM, Bjørn Mork wrote:
 Package: xscreensaver
 Version: 5.30-1+b1
 Severity: serious
 Justification: Policy 10.7.3

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 This part of xscreensaver.postinst overwrites any locally modified
 /etc/X11/app-defaults/XScreenSaver configuration:

 # Use the correct app defaults
 cd /etc/X11/app-defaults
 if [ -f XScreenSaver-gl ]; then
 ln -sf XScreenSaver-gl  XScreenSaver
 else
 ln -sf XScreenSaver-nogl XScreenSaver
 fi


 You should not do the above if an XScreenSaver file or symlink exists
 prior to installation

Thanks for the report. Looking at that file, there's also lots of old
cruft that probably can be deleted now.

Ideally it should overwrite an existing configuration file if it
hasn't been modified by the user. There are some standard recipes for
this IIRC.

Hmm, did you forget to attach the patch? :)

Regards,
Tormod


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

Bug#757448: Trademark status

[Tormod Volden]

tags 757448 +moreinfo
severity 757448 important
thanks

On Wed, Aug 13, 2014 at 7:03 PM, Wouter Verhelst wrote:
 On Sat, Aug 09, 2014 at 10:46:28AM +0900, mejiko wrote:
 Pong:

 http://tsdr.uspto.gov/#caseNumber=76148525caseType=SERIAL_NOsearchType=statusSearch


 Matrix:

 http://tsdr.uspto.gov/#caseNumber=85243232caseType=SERIAL_NOsearchType=statusSearch

 http://tsdr.uspto.gov/#caseNumber=78135234caseType=SERIAL_NOsearchType=statusSearch


 Pacman:

 http://tsdr.uspto.gov/#caseNumber=76638049caseType=SERIAL_NOsearchType=statusSearch

 Jamie did not contest that these are trademarks. He claimed that it's fair 
 use.

 http://en.wikipedia.org/wiki/Fair_use_(US_trademark_law)

 If you believe otherwise, you should point out why the use of these
 trademarks is not fair use in this content, not that they are trademarks
 (which nobody is contesting).


As far as I can see this is all fair use and no trademark
infringement. Unless there is new information to to the contrary, I
will close this bug report after a while.

Tormod


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

Bug#715278:

[Tormod Volden]

On Tue, Sep 3, 2013 at 4:24 AM, Brandon Simmons wrote:
 Is anyone maintaining this package? What can I do to help?


Hi Brandon,

The Debian intel-gpu-tools packaging is maintained at
http://git.debian.org/?p=pkg-xorg/app/intel-gpu-tools.git
If you can provide patches against this tree it would be very welcome.

Tormod


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

Bug#671907: elmerfem: FTBFS, outdated GL usage?

[Tormod Volden]

 In file included from src/mainwindow.h:52:0,
 from src/bodypropertyeditor.cpp:43:
 src/glwidget.h:198:3: error: 'GLUquadricObj' does not name a type

This identifier is defined in glu.h, and adding #include GL/glu.h to
ElmerGUI/Application/src/glwidget.h made it compile. Then it failed on
unknown symbols during linking, and it turned out libGLU was not
linked. Adding LIBS += -lGLU to ElmerGUI/Application/Application.pro
made everything work.

I wonder if these were included in some other build component before,
i.e. QT headers. Not sure what the proper fix is, I am new to qmake.
Anyway, I'll attach my debian/patches/ElmerGUI-fix-ftbfs.patch in hope
it can be of help to anyone trying to build it.

Regards,
Tormod


ElmerGUI-fix-ftbfs.patch
Description: Binary data

Bug#651792: Fails to build against Linux 3.1

[Tormod Volden]

 Package: linux-wlan-ng-source
 Version: 0.2.9+dfsg-4
 Severity: grave

 These modules fail to build against Linux 3.1:

 make[5]: Entering directory `/usr/src/linux-headers-3.1.0-1-amd64'
 /usr/src/linux-headers-3.1.0-1-common/arch/x86/Makefile:81: stack protector 
 enabled but no compiler support
  CC [M]  /usr/src/modules/linux-wlan-ng/src/p80211/p80211mod.o
 In file included from 
 /usr/src/modules/linux-wlan-ng/src/p80211/p80211mod.c:74:0:
 /usr/src/modules/linux-wlan-ng/src//include/wlan/wlan_compat.h:94:26: fatal 
 error: linux/config.h: No such file or directory
 compilation terminated.
 make[8]: *** [/usr/src/modules/linux-wlan-ng/src/p80211/p80211mod.o] Error 1
 make[7]: *** [_module_/usr/src/modules/linux-wlan-ng/src/p80211] Error 2
 make[6]: *** [sub-make] Error 2
 make[5]: *** [all] Error 2

 This error is due to checking for a macro which has not been defined
 since Linux 2.6.38.

 Based on the discussion in bug #501486, it appears that this binary
 package should simply be removed.

 Ben.

Thanks for the notice. I will give the linux-wlan-ng package some love soon.

Not sure why this bug is grave though, as long as the package
description clearly explains that you do not need it if your kernel is
newer than 2.6.31. No users are affected by this bug.

Tormod



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

Bug#643464: radeontool: FTBFS: radeontool.c:42:5: error: format not a string literal and no format arguments [-Werror=format-security]

[Tormod Volden]

On Wed, Sep 28, 2011 at 1:52 PM, Jonathan Nieder wrote:
 Didier Raboud wrote:

 radeontool.c: In function 'fatal':
 radeontool.c:42:5: error: format not a string literal and no format 
 arguments [-Werror=format-security]

 Yep, known.  The patch below (excluding the hunk patching radeonreg
 since radeonreg is not in sid yet) should fix it.  I'd like to send a
 batch of patches upstream soon addressing warnings including this one,
 but maybe it's worth an upload to fix the build before then.

Hi, I sent a bunch of patches to Dave Airlied many weeks ago, which
also fixed this. I will have to ping him again. I should also push it
to a branch of my own so that you can see what I have done already.

Cheers,
Tormod



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

Bug#643464: radeontool: FTBFS: radeontool.c:42:5: error: format not a string literal and no format arguments [-Werror=format-security]

[Tormod Volden]

On Mon, Oct 3, 2011 at 4:13 PM, Tormod Volden wrote:
 also fixed this. I will have to ping him again. I should also push it
 to a branch of my own so that you can see what I have done already.

http://cgit.freedesktop.org/~tormod/radeontool/



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

Bug#618165: xscreensaver: FTBFS: Nonexistent build-dependency: 'gdm'

[Tormod Volden]

Yes, it has been on the todo list for some years to get rid of the gdm
build dependency. I guess it is time to do something about it.

(Jose, for your reference, our old conversation on this has subject
build dep on gdm)



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

Bug#597932: openocd FTBFS on armel and hurd

[Tormod Volden]

On Sun, Sep 26, 2010 at 6:38 PM, Luca Bruno wrote:

 Moreover, the patch for armel should really be sent upstream.
 Would you take care of this (if you are in touch with authors) or should
 I do it?

Hi Luca,

I can not talk for the maintainer, but I will encourage you to submit
the patch on the upstream ML
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=summary
but refreshed against their latest git (your register-command.diff
does not apply cleanly). Having the upstream ack will also make it
easier to push your patch through Debian.

Cheers,
Tormod



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

Bug#528029: [PATCH] Do not use local libssl either.

[Tormod Volden]

Move the local libssl away the same way we do for libcrypto.
The standard libssl0.9.8 Debian package should work fine.
(Closes: 528029, 537837)

Signed-off-by: Tormod Volden debian.tor...@gmail.com
---
 make-googleearth-package |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/make-googleearth-package b/make-googleearth-package
index 34fc5e5..0629b2d 100755
--- a/make-googleearth-package
+++ b/make-googleearth-package
@@ -379,6 +379,7 @@ function build_package() {
 
   # Workaround symbol problem in libcrypto
   mv libcrypto.so.0.9.8 libcrypto.so.0.9.8.moved.for.workaround
+  mv libssl.so.0.9.8 libssl.so.0.9.8.moved.for.workaround
 
   # debian menu entry
   cd $instdir
-- 
1.6.3.3




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

Bug#534165: googleearth-package: video driver issue?

[Tormod Volden]

severity 534165 normal
thanks

This sounds more like a graphic drivers issue. I can not reproduce it
here. What kind of video card and drivers do you use? Please attach
your Xorg.0.log.



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

Bug#483989: xserver-xorg-video-savage: system freeze while starting X

[Tormod Volden]

You listed 5 reverted commits above. Did you try to narrow down which
ones you need to revert? Or are they all broken by the
02_temporary_revert_pciaccess.diff?

You can also try to start the server with sudo strace Xorg from
another machine, or sudo gdb Xorg. Sometimes the debugging makes the
execution slow enough that you will get something in the log. If you
try gdb, setting breakpoints around/inside SavageMapMem might be an
idea as well, to find where it blows up.

And does the standard tricks of Option BusType PCI and Option
DRI off make any change?

Cheers,
Tormod



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

Bug#484112: [xscreensaver-gl] flurry hack causes the whole system to freeze

[Tormod Volden]

Thanks for your report. The problem has also been reported in
https://bugs.launchpad.net/bugs/224065

For now, we'll demote flurry to the -extra package so that it is not
installed by default.



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

Bug#469099: xscreensaver: Package split leaves non-working screensavers in KDE configuration

[Tormod Volden]

On Mon, Mar 3, 2008 at 3:12 AM, Frans Pop [EMAIL PROTECTED] wrote:

  After upgrading to this version of xscreensaver I noticed that the KDE
  controlcenter module used to configure the screensaver now lists a
  number of screensavers that no longer work.

  Apparently the list of available screensavers does not get updated.

  The reason seems to be that the following file is still installed:
/usr/share/applnk/System/ScreenSavers/phosphor.desktop
  This file is installed by the package kscreensaver-xsavers.


Thanks for your report. Several hacks have been moved to the
xscreensaver-data-extra (and xscreensaver-gl-extra) package. Just
install that package and the broken kscreensaver will work fine again.


  Evidently the package split should have been coordinated with packages
  depending on xscreensaver.


We don't expect any major problems. All the files are practically the
same, just in two packages. We could choose to drag in both packages
during the upgrade, but chose to do user education instead, to make
the future better. Sorry, personally I know nothing about
kscreensaver-xsavers. I will be pleased to work together with you to
make it work properly.

Believe me, the reason for the package split is exactly to make things
easier for third-party screensaver infrastructures (like
gnome-screensaver and kscreensaver), so that they can use xscreensaver
hacks without the user having xscreensaver installed. The split in
-extra is currently the only way to split between safe, recommended
hacks and those who often can cause problems.


  From this point of view the package split can be said to break existing
  installations, which is a release critical issue. This BR is necessary
  to prevent the new xscreensaver to migrate to testing until the required
  coordination has taken place and depending packages have been updated.


Apparantly, the package split exposes a weakness in the kscreensaver
package. Does it have a list of screensaver hacks hardcoded? Your
mentioning of its
/usr/share/applnk/System/ScreenSavers/phosphor.desktop file sounds a
bit like this. It should be made to dynamically deal with the
available screensavers in /usr/share/applications/screensavers. Also
other packages might drop .desktop files in there if they have
something suitable as a screensaver.

IMO, only the package shipping a hack should also ship a .desktop for
it, whether in /usr/share/applnk/System/ScreenSavers or
/usr/share/applications/screensavers. Anyway, the .desktop files
should have a TryExec entry to check for the existence of the hack
binary. Maybe you just need to update the relevant .desktop files.

Without knowing kscreensaver much, I think the best solution would be
to stop kscreensaver from shipping .desktop files and rather let it
look for the desktop files installed by other packages.

On the short term, just let kscreensaver depend on
xscreensaver-data-extra, but remove the dependency later once
kscreensaver is fixed properly.

Cheers,
Tormod



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

Bug#469099: xscreensaver: Package split leaves non-working screensavers in KDE configuration

[Tormod Volden]

On Mon, Mar 3, 2008 at 3:53 PM, Frans Pop [EMAIL PROTECTED] wrote:
  Yes, I understand that, but it is not the point of my report.

For a moment I thought you were the misgruntled kscreensaver
maintainer, that's why I explained everything so carefully :)

  Which is _exactly_ why you should have coordinated with the maintainers of
  packages depending on your package before making a major change such as
  this split.

Yeah, I missed the reverse dependency on kscreensaver-savers.

  It's not a weakness in kscreensaver. It's something that has been a fact
  for probably a long time. A fact that the split did not take into account
  and thus is causing breakage.


It's poor design in kscreensaver, but we'll fix it instead of arguing...

  I really don't care about any of that. The fact remains that you implemented
  a change which is causing breakage in another package. That is a release
  critical bug.

I didn't say that it shouldn't be fixed. I'll keep the bug open here
until it's fixed in kscreensaver-xsavers.

  Great. I suggest that you contact the maintainers of kscreensaver ASAP and
  discuss the details with them. It _is_ your responsibility as maintainer of
  a package to coordinate with maintainers of packages that have reverse
  dependencies on your package when making changes that could affect them.

Sure! I think I got that point now ;)


  Cheers,
  FJP


Thanks,
Tormod



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

Bug#469099: xscreensaver: Package split leaves non-working screensavers in KDE configuration

[Tormod Volden]

On Mon, Mar 3, 2008 at 8:55 PM, Jamie Zawinski [EMAIL PROTECTED] wrote:
  I don't understand why you're wasting your time on this.  The
  xscreensaver executable is only 200kb.

  A good principle is don't fix what ain't broke.


Jamie,
I like to see it as progress :) I understand your feelings on this,
but I have another perspective. It's not to save 200kB, but to avoid
any conflicts between different backends and setups. I see upstream
xscreensaver as a provider of 1) a nice screensaver backend that some
people need or prefer to use 2) a wonderful collection of hacks that
can be shared by other backends and what not.

Of course, we are now making (2) easier and cleaner, but we also try
to satisfy (1) better. For instance, people can install the
xscreensaver package in their GNOME and it will work in all its glory
without any crippling that would have been introduced for (2). It can
seem unfair to the xscreensaver heritage, but we now have something
like xscreensaver, gnome-screensaver and kscreensaver being equal,
independent choices for backend, all three sharing the goodness of
xscreensaver-data.

Thanks for all your great work,
Tormod



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

Bug#468899: xscreensaver: Contains files from another package xscreenserver-data

[Tormod Volden]

Raphael, thanks for the analysis. I will try to fix this ASAP.

Peter, please hold on until a new version is out.



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

Bug#468899: xscreensaver: Contains files from another package xscreenserver-data

[Tormod Volden]

On Sun, Mar 2, 2008 at 12:55 PM, Raphael Hertzog [EMAIL PROTECTED] wrote:
   The changelog was wrong! It should be of course:
 * (From Ubuntu) Split xscreensaver-gl package into:
   - xscreensaver-gl (standard GL hacks)
   - xscreensaver-gl-extra (GL hacks not installed by default)
   Then xscreensaver-data does not need Replaces: xscreensaver-gl, right?

  Right, then xscreensaver-gl-extra needs a Replaces: xscreensaver-gl (
  5.04-3).

   I have sprinkled on Conflicts and Replaces. Do you think it looks OK
   in the attached control file? I am currently doing upgrade tests, but
   there might be some use cases that I don't catch.

  Why did you add a Replaces: xscreensaver-data ( 5.04-3) to
  xscreensaver-gl? xscreensaver-gl doesn't take over files from
  xscreensaver-data since xscreensaver-data is a new package.

  Same for xscreensaver-gl-extra.

Ok, makes sense now.
-data and -data-extra both replaces files in old xscreensaver
-gl-extra replaces files in old -gl

   Does that mean that my Conflicts: xscreensaver ( 5.04-3) are not good?

  No, it's precisely what we wanted. We want to install xscreensaver-data
  only after xscreensaver has been upgraded to the version without the
  conflicting files.

  That said, you don't need the conflict *if* the installation of
  xscreensaver-data doesn't break previous versions of xscreensaver package
  (the scenario is: you run an old version of xscreensaver and you only
  install xscreensaver-data (with apt-get install or dpkg -i)... does
  xscreensaver still work ?)

I think the new xscreensaver-data maybe can coexist with an old
xscreensaver, but I don't want anyone to do it, it doesn't make any
sense. So I'll keep the Conflicts everywhere.

Thanks!
Tormod


control
Description: Binary data

Bug#427972: udev: confirmed, my root partition was detected as vfat

[Tormod Volden]

Package: udev
Version: 0.105-4
Followup-For: Bug #427972


I had the same trouble now that I did an upgrade. My root partition was 
originally a large vfat partition that I 
cut in two, using gparted IIRC.

This also results in corrupted label names used to identify drives on the 
desktop for 
instance. I have commented on a similar issue in 
https://bugs.launchpad.net/bugs/36846

As I see it, it's a problem that the system has so many near-duplicate ways of 
detecting file systems. udev uses 
vol_id, fstype is another, for what I know mount (or the kernel) uses a third 
one. I don't remember what hal and 
gnome-vfs is using. This is not as consistent as it ought to be.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.21-1-486
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages udev depends on:
ii  debconf [debconf-2.0] 1.5.13 Debian configuration management sy
ii  libc6 2.5-10 GNU C Library: Shared libraries
ii  libselinux1   2.0.15-2   SELinux shared libraries
ii  libvolume-id0 0.105-4libvolume_id shared library
ii  lsb-base  3.1-23.1   Linux Standard Base 3.1 init scrip

udev recommends no packages.

-- debconf information excluded


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

Bug#386037: linux-wlan-ng-source: fails to build modules with module-assistent

[Tormod Volden]

Package: linux-wlan-ng-source
Version: 0.2.4+svn20060808-2
Severity: serious


I just installed the newest weekly cd, and then installed 
linux-wlan-ng-source. Using module-assistant I am not able to build 
the modules.

One thing is that it complains about not finding gcc-4.0 (gcc-4.1 is 
installed). There is gcc-4.0 appearing in config.mk. If I try manually 
to run ./Configure and make in the sources tree, this goes away from 
config.mk, but make (or CC=gcc-4.1 make) still fails with a bunch of 
errors and missing 4.0 complaints.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-486
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages linux-wlan-ng-source depends on:
ii  debhelper 5.0.37.3   helper programs for debian/rules
ii  module-assistant  0.10.6 tool to make module package creati

linux-wlan-ng-source recommends no packages.

-- no debconf information


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

Bug#386037: linux-wlan-ng-source: needs to install gcc-4.0

[Tormod Volden]

Package: linux-wlan-ng-source
Followup-For: Bug #386037

Hmm, I realized the kernel had been compiled with gcc-4.0... So I 
installed gcc-4.0 as well, and now it successfully built the modules.

I guess this bug should be something make sure the kernel compiler 
version is installed before building kernel modules. Shouldn't 
module-assistant have been a little more helpful?

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-486
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages linux-wlan-ng-source depends on:
ii  debhelper 5.0.37.3   helper programs for debian/rules
ii  module-assistant  0.10.6 tool to make module package creati

linux-wlan-ng-source recommends no packages.

-- no debconf information


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