Bug#772415: aspell expects en.dat in /usr/share/aspell but it is in /usr/lib/aspell

[Brian Nelson]

Agustin Martin  writes:

[...]
> I see two approaches to this problem.
>
> 1) Make sure data files are also searched for under dict-dir. This requires
>a number of changes in aspell code to handle 3 search dirs instead of 2.
>I have been doing some changes for this, but this is probably more for
>upstream.
>
> 2) Partially revert the changes, keep independent multiarch lib-dir, but
>join data-dir and dict-dir into /usr/lib/aspell. This is a far simpler
>change, but will also need testing.
>
>This has another advantage. Noticed that aspell dicts building directly
>from aspell dict sources will install dat files under data-dir and dicts
>stuff under dict-dir, currently different locations. 
>
>I think is better to keep all (but autogenerated) stuff for a given dict
>together.
>
> Brian, what do you think? 

Either solution is fine with me.  It's probably a bit nicer to not have
to maintain a source code patch, so I'd lean toward #2 as well.

I'll test out the patch tomorrow.

> I think the second option is better for Debian, but needs testing, a lot of
> testing to make sure corner cases work. The problem is that we are in
> freeze, the usual sid-> testing mechanism is disabled and only fixes for RC
> bugs will reach jessie. 
>
> https://release.debian.org/jessie/freeze_policy.html
>
> And we should not upload to unstable, something RC might need care and would
> interfere. Although nasty, I do not think this problem is RC, debian aspell
> dicts build and work and there is the temporary --local-data-dir hack (or
> using symlinks to xx.dat from current dict build dir). I think we should go
> with 2) once jessie is released.

I agree that this not an RC bug and probably isn't worth getting into
jessie.

-- 
Captain Logic is not steering this tugboat.


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

Bug#488234: aspell-en: "signalled" missing in american en_US aspell dict?

[Brian Nelson]

tag 488234 wontfix
thanks

"Signalled" is an unusual spelling to my eyes, so I think it's OK that
it's not accepted as a valid spelling in US English.  I'll reconsider
though if someone wants to argue that it should be consistent with the
ispell dictionaries.



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

Bug#632023: New Upstream Version of Aspell English Dictionaries Available

[Brian Nelson]

Kevin Atkinson  writes:

> Source: aspell-en
> Version: 6.0-0-6
>
> A new upstream version of the Aspell English Dictionary has been
> available for several mouths now, see http://wordlist.sourceforge.net/
> and http://ftp.gnu.org/gnu/aspell/dict/en/.  The new version contain
> numerous correction and the enhancements since the version 6.0 which was
> released over 6 years ago.

Cool, thanks for the tip.  For some reason the watch file in the Debian
packaging isn't noticing the new version.  I'll look into getting it
packaged soon.

-- 
Captain Logic is not steering this tugboat.



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

Bug#612051: aspell: spell-checking in Emacs is broken

[Brian Nelson]

Sven Joachim  writes:

> Package: aspell
> Version: 0.60.6-5
> Severity: important
> X-Debbugs-CC: dictionaries-com...@packages.debian.org
>
> The upgrade of aspell to 0.60.6-5 broke spell-checking in Emacs with
> aspell (I have (setq ispell-program-name "/usr/bin/aspell") in my
> ~/.emacs), ispell-region signals an error now:
>
> ,
> | Debugger entered--Lisp error: (error "Fehler: The filter \"nroff\" does not 
> exist.")
> |   signal(error ("Fehler: The filter \"nroff\" does not exist."))
> |   error("%s" "Fehler: The filter \"nroff\" does not exist.")
> |   ispell-init-process()
> |   ispell-buffer-local-words()
> |   ispell-accept-buffer-local-defs()
> |   ispell-region(1 20)
> |   ispell-buffer()
> |   call-interactively(ispell-buffer t nil)
> |   execute-extended-command(nil)
> |   call-interactively(execute-extended-command nil nil)
> `

It's probably caused by this change:

  * debian/rules: changed pkgdatadir to /usr/share/aspell which is a more
appropriate location for that data than /usr/lib/aspell, and leave the
spell and ispell scripts there so that run-with-aspell works

since that changed the location of the nroff filter (among other
things), but I'm not sure why that change would make aspell fail to find
the filters.

-- 
Captain Logic is not steering this tugboat.



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

Bug#608023: ispell-buffer always gives bogus (0) and (1) choices

[Brian Nelson]

So the actual report is in
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7732 which basically
amounts to:

transfered

   
1) transfer ed 5) transferees
2) transfer-ed 6) transformed
3) transferred 7) transversed
4) transferee  8) transferee's

This looks a lot like bug #401120 (which you also reported, heh).  It
must be due to a suggestion bug that was introduced somewhere in the
0.60 series.

-- 
Captain Logic is not steering this tugboat.



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

Bug#604557: RFS: aspell-id

[Brian Nelson]

Jonathan Nieder  writes:

> Hi,
>
> Mahyuddin Susanto wrote:
>
>> * URL : ftp://ftp.gnu.org/gnu/aspell/dict/id
> [...]
>> - dget
>> http://mentors.debian.net/debian/pool/main/a/aspell-id/aspell-id_0.1-2.dsc
>
> The .orig.tar.gz seems to be a git clone of
> , though the files match
> aspell5-id-1.2-0.tar.bz2.  I would suggest:
>
> - setting the version number in debian/changelog based on the
>   upstream version:
>
>   aspell-id (1.2-0-1) unstable; urgency=low
>
> * Initial package for Debian (Closes: #604557).  * Add simple
> rules file (using cdbs, based on such-and-such
>   documentation), a control file describing the binary package,
>   and an appropriate compat file.
>
>-- Mahyuddin Susanto  ... whenever ...
>
> - putting a copy of aspell5-id-1.2-0.tar.bz2 named
>   aspell-id_1.2-0.orig.tar.bz2 in the parent directory to your build
>   dir when building the package.
>
> Perhaps this package should Provides: aspell-dictionary?  Brian Nelson
> might have more advice; cc-ing him.

Yes, aspell dictionary packages should Provides: aspell-dictionary.  The
dictionary packaging otherwise looks OK with a very quick glance.

-- 
Captain Logic is not steering this tugboat.



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

Bug#599653: /usr/bin/run-with-aspell: run-with-aspell broken due to lack of wrappers in /usr/lib/aspell

[Brian Nelson]

Josh Triplett  writes:

> The run-with-aspell wrapper does:
>
> PATH=/usr/lib/aspell:$PATH
> export PATH
> exec $@
>
> However, aspell 0.60.3-4 moved the wrapper scripts from /usr/lib/aspell
> to /usr/share/doc/aspell/examples, ostensibly to fix bug 273761 (which
> actually requested using them as alternatives for /usr/bin/ispell).
> This broke run-with-aspell.
>
> Please move the scripts back, and just point to them from
> /usr/share/doc/aspell if you want to make them easier to find.

Hmm.  /usr/lib/aspell is a fairly terrible place to put shell
scripts like these which is in part why I moved them.  Maybe I'll move
them to /usr/share/aspell instead and modify the run-with-aspell wrapper
to find them.

-- 
Captain Logic is not steering this tugboat.



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

Bug#592613: mp3splt: Regression in padded filename support

[Brian Nelson]

Package: mp3splt
Version: 2.2.5-1
Severity: normal

The upstream changelog for version 1.8 notes:

  feature improved: output filenames now are automatically zero padded
  for a correct order. 

And true enough, with older versions of mp3splt, you would get filenames
like:

 $ mp3splt -t 5.0 -a *.mp3
 Mp3Splt 2.1 (2004/Sep/28) by Matteo Trotta
 
 THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK!
 wot6_part1.mp3:
 MPEG 1 Layer 3 - 44100 Hz - Stereo - FRAME MODE - Total time: 542m.13s
 Working with SILENCE AUTO-ADJUST (Threshold: -48.0 dB Gap: 30 sec
 Offset: 0.80)
 [...]
 Splitting wot6_part1_090.00_095.00.mp3... OK
 Splitting wot6_part1_095.00_100.00.mp3... OK
 Splitting wot6_part1_100.00_105.00.mp3... OK
 Splitting wot6_part1_105.00_110.00.mp3... OK
 [...]

In other words, since the total length is greater than 100 minutes, it
pads the minutes parts of the filenames with zeros for minutes < 100.

However, with newer versions of mp3splt, this is no longer the case:

 $ mp3splt -t 5.0 -a *.mp3
 mp3splt 2.2.5 (16/05/09) - using libmp3splt 0.5.6
 [...]
  Processing file 'wot6_part1.mp3' ...
  info: frame mode enabled
  info: MPEG 1 Layer 3 - 44100 Hz - Stereo - FRAME MODE - Total time: 542m.13s
  Working with SILENCE AUTO-ADJUST (Threshold: -48.0 dB Gap: 30 sec Offset: 
0.80)
  info: starting time mode split
File "wot6_part1_00m_00s__05m_00s.mp3" created
File "wot6_part1_05m_00s__10m_00s.mp3" created
File "wot6_part1_10m_00s__15m_00s.mp3" created
 [...]
File "wot6_part1_100m_00s__105m_00s.mp3" created
 [...]

The minutes parts of the filenames are no longer padded with zeros, so
the files are no longer sorted in a sane order.  Somewhere between 2.1
and 2.2.5, a regression seems to have occurred and this feature stopped
working.


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

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

Versions of packages mp3splt depends on:
ii  libc6 2.11.2-2   Embedded GNU C Library: Shared lib
ii  libmp3splt-mp3 [libmp3splt-pl 0.5.6-1MP3 plugin for mp3splt
ii  libmp3splt-ogg [libmp3splt-pl 0.5.6-1Ogg Vorbis plugin for mp3splt
ii  libmp3splt0   0.5.6-1library for splitting MP3 and Ogg 

mp3splt recommends no packages.

mp3splt suggests no packages.

-- no debconf information



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

Bug#582748: Wrong "fix"

[Brian Nelson]

reopen 582748
retitle 582748 Remove gratuitous conflicts with ccache
thanks

Conflicting with ccache is absolutely the wrong solution here.  Simply
having ccache installed does not trigger the bug as ccache has to be
configured manually to be used.

Personally, I use ccache on certain projects but not globally (who uses
ccache during package installs as root anyway?), so this change just
makes my life painful for no good reason.

-- 
Captain Logic is not steering this tugboat.



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

Bug#576749: aspell: man page misspells "its"

[Brian Nelson]

Justin B Rye  writes:

> Paragraph two of the DESCRIPTION has:
> # The Aspell library contains an interface allowing other programs
> # direct access to it's functions and therefore reducing the complex
>  ^
> That's the contraction meaning "it is" or "it has".  What you wanted
> was the possessive pronoun "its" (compare "his", "whose").
>
> Misapostrophisation is almost completely incapable of causing real
> ambiguity, so I'm only calling it wishlist.  You might even argue
> that it's a valuable hint to alert readers of the limitations of
> "spellchecking" software...

Good catch.  I'll fix this in the next upload.

Thanks,
Brian

-- 
Captain Logic is not steering this tugboat.



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

Bug#571657: psi: Please build Psi with Enchant support

[Brian Nelson]

Jan Niehusmann  writes:

> Hi Kelly,
>
> (Cc: to the maintainers of aspell and enchant)
>
> On Fri, Feb 26, 2010 at 12:18:24PM -0800, Kelly Clowers wrote:
>> Since 0.14, Psi supports Enchant as well as Aspell. I would like to see
>> the Debian version built with Enchant instead of or in addition to Aspell.
>
> I'm not sure about this. What are the advantages of using enchant?
>
> It seems like the debian package of aspell is more actively maintained
> than the enchant one. In fact, the version of enchant packaged is from
> May 2008, while there is a newer version (1.5.0) available since May
> 2009.
>
> In comparison, the aspell maintainer did an upload only a month ago.
> (Working on the packaging only, it seems, so no real advantages to the
> end user. But still, it shows that the package is actively maintained.)
>
> Of course, these signs may be misleading and enchant may be the better
> spellchecking library to use. And there may just be no reason for the
> enchant maintainer to upgrade the package, perhaps enchant 1.4.2 is more
> stable than 1.5.0. I just don't know. So, if you have good reasony why
> enchant is better, please tell me.

FYI, Aspell isn't really being actively developed upstream any longer.
He's still around and answers questions on the mailing lists but no
longer seems to do any coding on Aspell.

I'm not familiar with Enchant so I can't any offer any comparisons
otherwise.

-- 
Captain Logic is not steering this tugboat.



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

Bug#567142: O: libqwt

[Brian Nelson]

Michael Hanke  writes:

> On Wed, Jan 27, 2010 at 01:03:17PM -0500, Michael Hanke wrote:
>> Hi,
>> 
>> On Wed, Jan 27, 2010 at 08:54:21AM -0800, Brian Nelson wrote:
>> > Package: wnpp
>> > Severity: normal
>> > 
>> > Orphaning libqwt (version 4) as I no longer have an interest in
>> > packaging it.  Version 5 already exists as a separate package in the
>> > archive.
>> > 
>> > The only remaining dependency on this library is fslview.  Ideally
>> > fslview could be updated to use qwt5, in which case this older qwt could
>> > be removed from the archive.
>> 
>> I will check whether fslview would work with qwt5, and report here.
>
> I tried simply rebuilding it, but it doesn't work. I started composing a
> patch, but the changes are numerous, so I postponed that for now.
> Instead, I dropped upstream a note, asking about a possible port to
> qwt5.

In the meantime, you may wish to adopt Qwt4. ;)

-- 
Captain Logic is not steering this tugboat.



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

Bug#567142: O: libqwt

[Brian Nelson]

Package: wnpp
Severity: normal

Orphaning libqwt (version 4) as I no longer have an interest in
packaging it.  Version 5 already exists as a separate package in the
archive.

The only remaining dependency on this library is fslview.  Ideally
fslview could be updated to use qwt5, in which case this older qwt could
be removed from the archive.



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

Bug#542608: aspell: 60 times slower than Ispell in pipe mode

[Brian Nelson]

Jacob Sparre Andersen  writes:

> I've compared the speed of Ispell and Aspell in pipe mode.  Aspell
> appears to be roughly 60 times slower than Ispell.  Although Aspell
> does more work than Ispell, this seems like quite a large difference.
> Can something simple be done to speed up Aspell a bit?

This topic came up on the aspell mailing list recently, and the author
had some tips:

  http://lists.gnu.org/archive/html/aspell-user/2010-01/msg2.html

Maybe it would be useful to document the speeds of the different
suggestion modes in the aspell manpage?

-- 
Captain Logic is not steering this tugboat.



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

Bug#542608: aspell: 60 times slower than Ispell in pipe mode

[Brian Nelson]

Jacob Sparre Andersen  writes:

> I've compared the speed of Ispell and Aspell in pipe mode.  Aspell
> appears to be roughly 60 times slower than Ispell.  Although Aspell
> does more work than Ispell, this seems like quite a large difference.
> Can something simple be done to speed up Aspell a bit?

This topic came up on the aspell mailing list recently, and the author
had some tips:

  http://lists.gnu.org/archive/html/aspell-user/2010-01/msg2.html

Maybe it would be useful to document the speeds of the different
suggestion modes in the aspell manpage?

-- 
Captain Logic is not steering this tugboat.



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

Bug#409421: Is Brian Nelson MIA (Was: Bug #409421 libqwt-dev: Please update to 5.0.2)

[Brian Nelson]

Andreas Tille wrote:

Hi,

the request for uploading a new upstream version is 2,5 years old and
did not deserved a single response from the maintainer.  While this is a
wishlist bug it should be fixed anyway because other packages depend
from newer versions of this library.

Similar situation with #350489 which is tagged patch but no response
from maintainer seems that he has lost interest.  Leaving alone a
library unmaintained might result in security issues.

So I wonder whether it is time for an NMU or even a highjack of the
package.


Well, the newer version *is* in the archive, as another maintainer took 
over packaging the new version (and I had intended for him to take over 
the old one but apparently that never happened).  qwt4 should be removed 
from the archive but it looks like there are still a couple of 
reverse-dependencies on it.




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

Bug#518913: aspell cannot create hash file for "en"

[Brian Nelson]

Joe Thompson  writes:

> On Wed, Mar 11, 2009 at 7:59 PM, Brian Nelson  wrote:
>> Please verify that this command produces a long list of words:
>>
>>  $ zcat /usr/share/aspell/en-common.cwl.gz | precat
>
> It does.
>
>> and if that works, see if this completes successfully:
>>
>>  $ zcat /usr/share/aspell/en-common.cwl.gz | precat | aspell 
>> --per-conf=/dev/null --local-data-dir=/usr/lib/aspell --lang=en create 
>> master /tmp/foo.rws
>
> crowley:~# zcat /usr/share/aspell/en-common.cwl.gz | precat | aspell
> --per-conf=/dev/null --local-data-dir=/usr/lib/aspell --lang=en create
> master /tmp/foo.rws
> Error: The key "affix" is unknown.

This error seems to be the result of trying to build a dictionary using
an 0.50-era version of Aspell.  No such version of Aspell existed in a
stable Debian release, so perhaps you have an old locally built version
of Aspell in /usr/local that is being used?  What do "which aspell"
and "aspell --version" say?

-- 
Captain Logic is not steering this tugboat.



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

Bug#518913: aspell cannot create hash file for "en"

[Brian Nelson]

Joe Thompson  writes:

> On Mon, Mar 9, 2009 at 11:02 AM, Brian Nelson  wrote:
>> Can you please send the output of:
>>
>> # aspell-autobuildhash --force --debug
>
> # aspell-autobuildhash --force --debug
> en => aspell_compat: [0.60_c1]; lang_compat: [0]
> aspell-autobuildhash: processing: en [en-common]
> Error: The key "affix" is unknown.
>  --- /var/lib/aspell/en.compat not updated because of an error
>
> In front of that I get the same ncurses dialog box as before. -- Joe

Please verify that this command produces a long list of words:

  $ zcat /usr/share/aspell/en-common.cwl.gz | precat

and if that works, see if this completes successfully:

  $ zcat /usr/share/aspell/en-common.cwl.gz | precat | aspell 
--per-conf=/dev/null --local-data-dir=/usr/lib/aspell --lang=en create master 
/tmp/foo.rws

The actual error you're getting seems to be the result of passing
"--affix" to the above aspell command, which isn't a valid option.  I'm
not sure why that would happen.

-- 
Captain Logic is not steering this tugboat.



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

Bug#518913: aspell cannot create hash file for "en"

[Brian Nelson]

severity 518913 important
thanks

I'm downgrading this bug since I don't believe it to be a wide-spread
issue.

Joe Thompson  writes:

> After upgrading from debian sarge, through etch, and finally to lenny, I 
> noticed when trying to install AbiWord that aspell failed to create a hash 
> file for locale "en".  In fact the problem I get is exactly as described 
> here: 
>
> http://osdir.com/ml/linux.debian.devel.dictionary/2005-07/msg00010.html
>
> which as you can see is a 3.5-year-old message.  

...written be me. :)  It doesn't seem particularly relevant though.  Are
you sure that's the link you meant to send?

> Nonetheless, that's the behavior I see -- anytime anything triggers
> aspell-autobuildhash, I get an ncurses dialog saying:
>
> -
> Problems rebuilding an aspell hash file (en)
>
> ** Error: Could not build the hash file for en-common
>
> This error was caused by package providing 'en', although it can be made 
> evident during other package postinst. Please complain to the maintainer 
> of package providing 'en'.
>
> Until this problem is fixed you will not be able to use aspell with 'en'.
> -

Can you please send the output of:

# aspell-autobuildhash --force --debug

Thanks,
Brian

-- 
Captain Logic is not steering this tugboat.



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

Bug#510209: acpi-support: No way to disable screen locking in KDE

[Brian Nelson]

Package: acpi-support
Version: 0.109-10
Severity: normal

When I close my laptop lid, my laptop always gets locked, and there's no
way I can find to disable this behavior.  It looks like what's happening
is that the /usr/share/acpi-support/screenblank script is run, which in
turn runs the command "dcop --session "$session" --all-users kdesktop
KScreensaverIface lock" with no consideration of the LOCK_SCREEN
setting.  Note that the script does honor LOCK_SCREEN if xscreensaver is
running.

Please modify the script to honor LOCK_SCREEN, or provide some way of
disabling screen locking when closing the lid when in KDE.

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

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

Versions of packages acpi-support depends on:
ii  acpi-support-base 0.109-10   scripts for handling base ACPI eve
ii  acpid 1.0.8-1Utilities for using ACPI power man
ii  dmidecode 2.9-1  Dump Desktop Management Interface 
ii  finger0.17-12user information lookup program
ii  hdparm8.9-3  tune hard disk parameters for high
ii  laptop-detect 0.13.7 attempt to detect a laptop
ii  libc6 2.7-16 GNU C Library: Shared libraries
ii  lsb-base  3.2-20 Linux Standard Base 3.2 init scrip
ii  powermgmt-base1.30+nmu1  Common utils and configs for power
ii  vbetool   1.0-3  run real-mode video BIOS code to a
ii  x11-xserver-utils 7.3+5  X server utilities

Versions of packages acpi-support recommends:
ii  dbus  1.2.1-4simple interprocess messaging syst
ii  hal   0.5.11-6   Hardware Abstraction Layer
ii  nvclock   0.8b3-1Allows you to overclock your nVidi
ii  pm-utils  1.1.2.4-1  utilities and scripts for power ma
ii  radeontool1.5-5  utility to control ATI Radeon back
ii  toshset   1.73-3 Access much of the Toshiba laptop 

Versions of packages acpi-support suggests:
pn  laptop-mode-tools  (no description available)

-- no debconf information



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

Bug#496443: vux: Incorrect signal handling

[Brian Nelson]

Can you send me the output of:

zsh -x /usr/bin/vux

after skipping a few songs, and then a ps output?

Thanks.

On Sep 13 07:24AM, Hans-Joachim Baader wrote:
> Hi,
> 
> > Are you using vlc to play the files?
> 
> no, I use ogg123 for ogg and flac, and mpg123 for mp3.
> 
> Regards,
> hjb
> -- 
> Pro-Linux - Germany's largest volunteer Linux support site
> http://www.pro-linux.de/  Public Key ID 0x3DDBDDEA





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

Bug#496443: vux: Incorrect signal handling

[Brian Nelson]

Are you using vlc to play the files?

Brian


On Sep 01 09:33PM, Hans-Joachim Baader wrote:
> Hi,
> 
> > Can you give me more information, like what vuxctl commands cause the
> > problem?
> 
> I haven't tested all, but I think all, becaus every command sent causes
> a signal which interrupts the wait.
> 
> Regards,
> hjb
> -- 
> Pro-Linux - Germany's largest volunteer Linux support site
> http://www.pro-linux.de/  Public Key ID 0x3DDBDDEA





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

Bug#496443: vux: Incorrect signal handling

[Brian Nelson]

Hi,

Can you give me more information, like what vuxctl commands cause the
problem?

Thanks,
Brian

On Aug 24 08:55PM, Hans-Joachim Baader wrote:
> Package: vux
> Version: 0.4.9
> Severity: important
> Tags: patch
> 
> 
> Hi,
> 
> when sending a command to vux via vuxctl, vux spawns a new player which
> results in multiple songs playing or waiting to be played simultaneously.
> 
> After a long search I suspected the wait function to be the cause of this.
> When I concentrated on this is didn't take long to find and fix the bug.
> The wait is interrupted by the HUP signal sent by vuxctl, and vux should
> continue to wait after that. Here's the patch:
> 
> --- /usr/bin/vux  2004-11-04 22:54:33.0 +0100
> +++ /home/hans/bin/vux2008-08-24 14:23:36.744544743 +0200
> @@ -764,7 +772,14 @@
>  $player $player_options $current_song &
>  player_pid=$!
>  wait_for_player=0
> -wait
> +
> +while [ 1 ]; do
> +  wait
> +  if ! kill -0 $player_pid > /dev/null 2>&1; then
> +break
> +  fi
> +done
> +
>  unset player_pid
>else
>  $missing_method $current_song >> $missing_log
> 
> It affects both x86 and x86_64.
> 
> Regards,
> hjb
> 
> -- System Information:
> Debian Release: lenny/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 2.6.26.3 (SMP w/4 CPU cores; PREEMPT)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> 
> Versions of packages vux depends on:
> ii  lockfile-progs0.1.11-0.1 Programs for locking and 
> unlocking
> ii  mpg321 [mp3-decoder]  0.2.10.4   mpg123 clone that doesn't use 
> floa
> ii  vlc [mp3-decoder] 0.8.6.h-1  multimedia player and streamer
> ii  vlc-nox [mp3-decoder] 0.8.6.h-1  multimedia player and streamer 
> (wi
> ii  vorbis-tools  1.2.0-5several Ogg Vorbis tools
> ii  zsh   4.3.6-7A shell with lots of features
> 
> vux recommends no packages.
> 
> vux suggests no packages.
> 
> -- no debconf information
> 



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

Bug#469783: libqt4-dev: Please add qtdemo back and provide the examples

[Brian Nelson]

Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:

> PS It would be nice if you could change debian/rules to set
>
>   -demosdir "/usr/share/qt4/demos" \
>   -examplesdir "/usr/share/qt4/examples" \
>
> as the current qmake binary has the rather awkward paths 
>/usr/demos
>/usr/examples
> preset given thet prefix=/usr.

That's a fine change to make, but it also illustrates the problem of
including a usable qtdemo.  All of the demo sources and binaries would
end up in /usr/share/qt4/demos, which is fine for the sources but bad
for the binaries.  The binaries would need to go in /usr/lib/qt4/demos
or something, and qtdemo would need to be hacked to find those
binaries...  and it becomes annoyingly difficult to include useful demos
for qtdemo...

At least that's what I found when I tried to include it a couple years
ago...

-- 
Captain Logic is not steering this tugboat.



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

Bug#437354: libqt4-dev: Put qmake into its own package

[Brian Nelson]

Sune Vuorela <[EMAIL PROTECTED]> writes:

> On Tuesday 12 February 2008, Brian Nelson wrote:
>> Evgeni Golov <[EMAIL PROTECTED]> writes:
>> > Hi,
>> >
>> > are there any updates on this? I maintain pokerth which needs qmake4,
>> > libqt4-core and libqt4-gui, but not -sql, -qt3support etc.
>> > At the moment it build-depends on libqt4-dev which fetches way too much
>> > stuff in during building, what is annoying :)
>>
>> I don't see any compelling reason to split out qmake, and doing so now
>> would probably break some package builds.  I think this should be closed
>> or tagged wontfix.
>
> Some of us are talking about reorganizing how qt4 is packaged. for example, 
> libQtCore is quite nice for all sorts of things locally, but you can't 
> install that on debian without pulling all sorts of other things in.

I think it would be reasonable to put each library in a separate
package.  When I first packaged Qt4, there was nothing out there using
just, e.g. libQtCore, without using other parts of Qt, so it seemed
wasteful to split everything up.  That's probably no longer the case.

> The dev package has not yet been discussed, but it might be possible to do 
> something at the same time.

When it comes to -dev packages, the more things are split up the more
users get confused IMO.  When a user installs libqt4-dev, I think
they'll usually think they're getting the full Qt4 development
environment.  We could have libqt4-dev pull in e.g. qt4-qmake or
whatever, but I think that would be catering to such a tiny niche that
it wouldn't be worth the package bloat.

Plus, qmake is a shitty build tool and I'd rather not encourage its use
by splitting it out of libqt4-dev. :P

-- 
Captain Logic is not steering this tugboat.



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

Bug#437354: libqt4-dev: Put qmake into its own package

[Brian Nelson]

Evgeni Golov <[EMAIL PROTECTED]> writes:

> Hi,
>
> are there any updates on this? I maintain pokerth which needs qmake4,
> libqt4-core and libqt4-gui, but not -sql, -qt3support etc.
> At the moment it build-depends on libqt4-dev which fetches way too much
> stuff in during building, what is annoying :)

I don't see any compelling reason to split out qmake, and doing so now
would probably break some package builds.  I think this should be closed
or tagged wontfix.

-- 
Captain Logic is not steering this tugboat.



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

Bug#461641: libqt4-dev: should the dependency on libqt4-sql be a recommends?

[Brian Nelson]

Michael Gilbert <[EMAIL PROTECTED]> writes:

> Package: libqt4-dev
> Version: 4.3.3-2
> Severity: normal
>
> since there are currently security issues with a couple of the mysql 
> packages in sid, i would like to remove them.  however, doing so would 
> remove libqt4-dev as well since there is a dependency on libqt4-sql
> (which depends on the mysql packages).
>
> if the dependency on libqt4-sql were changed to a recommends, this
> wouldn't be a problem.  i am not familiar with the libqt4-dev package,
> so i don't know what kind of effect that has.  but it seems like the mysql
> and qt4 development stuff are or should be separate/separable things.

If libqt4-sql were not installed, there would be a broken
/usr/lib/libQtSql.so -> libQtSql.so.4.3.3 symlink in libqt4-dev.  While
that won't cause any major problems, broken symlinks generally aren't
tolerated in packages.

The symlink problem could be fixed by splitting out sql stuff into a
separate libqt4-sql-dev package, but I'm not convinced that's worth the
effort.

-- 
Captain Logic is not steering this tugboat.



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

Bug#447845: network-manager-kde and ipw3945 fails to associate

[Brian Nelson]

I can confirm this bug on my system.  If I establish the connection
manually using iwconfig and dhclient, it works fine however.

-- 
Captain Logic is not steering this tugboat.



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

Bug#437354: libqt4-dev: Put qmake into its own package

[Brian Nelson]

Jan Michael Alonzo <[EMAIL PROTECTED]> writes:

> Hi! I'm currently trying to build gnome + webkit without distro-specific
> packages. But for this I need "qmake" which is part of libqt4-dev. The problem
> is libqt4 is built with -glib enabled. Is there a reaason why qt4-dev needs
> glib? And also, if it's really needed can we separate qmake because it's used
> not only by QT4 apps but also third party applications like WebKit.
>
> I'm just not sure how coupled qmake is to the whole QT libs, if not, it would 
> be
> nice if qmake is in its own package.

The reason I originally included qmake in the -dev package was that I
was under the impression that no 3rd party apps used it.  It's certainly
possible to package it separately, though I'd be surprised anything
using it wasn't closely tied to Qt.

I don't understand what you mean about building with "distro-specific
packages" or why glib support would be a problem though.

-- 
Captain Logic is not steering this tugboat.


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

Bug#429817: qt4-dev-tools: assistant-qt4 fails to start due to a missing symbol

[Brian Nelson]

GALLIEN Matthieu <[EMAIL PROTECTED]> writes:

> Package: qt4-dev-tools
> Version: 4.2.3-1+b1
> Severity: normal
>
> If you install qt4.3 and still uses qt4-dev-tools 4.2.3, when you start 
> assistant, you got the following error:
> assistant: symbol lookup error: assistant: undefined symbol: 
> _ZN14QUnicodeTables5lowerEj
>
> The problem is solved by upgrading to qt4-dev-tools 4.3.
> Maybe you can add a conflict to avoid such a situation to arose.
>
> Anyway, thanks for your on packaging qt4.

It looks like QUnicodeTables is internal (i.e. non-public) API stuff, so
I'd say the correct fix would be to tighten qt4-dev-tools's dependency
on libqt4-core.  I suppose adding a libqt4-core (= ${Source-Version})
dependency is the way to go.

-- 
Captain Logic is not steering this tugboat.


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

Bug#413558: iptstate: does not work with 2.6.20

[Brian Nelson]

Hi,

In 2.6.20, you need the following option enabled for iptstate to work:

CONFIG_NF_CONNTRACK_PROC_COMPAT=y

I'll leave the bug open until the new /proc/net/nf_conntrack interface
is supported.

Thanks,
Brian

On Mar 05 09:14PM, Benoît Dejean wrote:
> Package: iptstate
> Version: 2.1-1
> Severity: normal
> Tags: patch
> 
> sudo iptstate
> ERROR: Couldn't open /proc/net/ip_conntrack: No such file or directory
> 
> 
> -- System Information:
> Debian Release: sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: powerpc (ppc)
> Shell:  /bin/sh linked to /bin/bash
> Kernel: Linux 2.6.20.1-ben
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to fr_FR.UTF-8)
> 
> Versions of packages iptstate depends on:
> ii  libc6   2.3.6.ds1-13 GNU C Library: Shared libraries
> ii  libgcc1 1:4.1.1-21   GCC support library
> ii  libncurses5 5.5-5Shared libraries for terminal 
> hand
> ii  libstdc++6  4.1.1-21 The GNU Standard C++ Library v3
> 
> iptstate recommends no packages.
> 
> -- no debconf information
> 

Bug#409937: libqt4-sql: The method QSqlDatabase::removeDatabase() never returns

[Brian Nelson]

Was this fixed by the BinNMU (version 4.2.1-2+b1) made recently?

-- 
Captain Logic is not steering this tugboat.


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

Bug#408639: qt4-doc: error when compiling qt4 demos

[Brian Nelson]

Err, never mind, I spoke too soon.  I do see the same error as you with
4.2.1.  Maybe this is fixed upstream in 4.2.2.

-- 
Captain Logic is not steering this tugboat.


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

Bug#408639: qt4-doc: error when compiling qt4 demos

[Brian Nelson]

Giuseppe D'Angelo <[EMAIL PROTECTED]> writes:

> Hi. When I try to compile the qt4 demos
> (from /usr/share/doc/qt4-doc/qt4-demos.tar.gz) I get:
>
> [...]
> make[1]: Entering directory `/home/peppe/qt4-demos/demos/arthurplugin'
> make -f Makefile.Release
> make[2]: Entering directory `/home/peppe/qt4-demos/demos/arthurplugin'
> mkdir: impossibile creare la directory `/plugins': Permission denied
> make[2]: *** [/plugins/designer/libarthurplugin.so] Error 1
> make[2]: Leaving directory `/home/peppe/qt4-demos/demos/arthurplugin'
> make[1]: *** [release] Error 2
> make[1]: Leaving directory `/home/peppe/qt4-demos/demos/arthurplugin'
> make: *** [sub-arthurplugin-make_default] Error 2
>
> I don't know if that's just a typo, but this is blocking proper
> compilation of the demos. In the .pro file I see:
>
> DESTDIR = $$QT_BUILD_TREE/plugins/designer
>
> and in Makefile.Release:
>
> $(MKDIR) /plugins/designer/
>
> Perhaps $$QT_BUILD_TREE is undefined?

What steps are you using to compile the demos?  Is QTDIR set to
/usr/share/qt4?  The following works fine for me:

cd demos
export QTDIR=/usr/share/qt4
qmake-qt4
make

-- 
Captain Logic is not steering this tugboat.


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

Bug#349899: closed by Brian Nelson <[EMAIL PROTECTED]> (Re: aspell does not recognize correct accented words)

[Brian Nelson]

Nicolas Évrard <[EMAIL PROTECTED]> writes:

> * Debian Bug Tracking System  [2007-02-18 02:27 +0100]: 
>
> Hello,
>
>>No actual bug here, AFAICT, so closing...
>
> Do you have any clue how I can fix this "feature" then. Because this is
> a really annoying one.

Did you see the comments others left to the bug report?  It seems that
you don't have LANG set properly (or maybe locales isn't configured
properly--try 'dpkg-reconfigure locales').

-- 
Captain Logic is not steering this tugboat.

Bug#409953: /usr/bin/moc must not be handled by alternatives

[Brian Nelson]

Matthias Klose <[EMAIL PROTECTED]> writes:

> Having both qt3-dev-tools and libqt4-dev results in moc pointing to
> moc-qt3 by default. Trying to generate files with moc-qt3 when files
> for qt4 are needed results in build errors like:
>
>   ./slotcallbacks.moc.h:13:34: error: private/qucomextra_p.h: No such file or 
> directory
>   ./slotcallbacks.moc.h:15:2: error: #error "This file was generated using 
> the moc from 3.3.7. It"
>   ./slotcallbacks.moc.h:16:2: error: #error "cannot be used with the include 
> files from this version of Qt."
>   ./slotcallbacks.moc.h:17:2: error: #error "(The moc has changed too much.)"
>
> To reliable build, each package generating files with moc during the
> build and build-depending on libqt4-dev must have a build conflict
> against qt3-dev-tools.
>
> Same for packages build-depending on qt3-dev-tools, if you consider
> that the alternative can be manually adjusted as well.
>
> This seems to be a lot of work for many packages; why is moc provided
> as an alternative at all? It causes builds to fail, so it isn't an
> alternative for many cases.

moc-qt3 and moc-qt4 are able to coexist to an extent so it doesn't seem
overly productive to have libqt4-dev and qt3-dev-tools conflict with
each other.  For example, if you use qmake-qt4, it's smart enough to use
moc-qt4.  I do development on both Qt3 and Qt4 and would be pretty
annoyed if I couldn't have both installed at the same time.

However, some other Qt3/Qt4 build systems just rely on the existence of
/usr/bin/moc so that's why it's provided through alternatives.  I'm not
aware of a better solution.  We can't just choose to have it always be a
link to either moc-qt3 or moc-qt4, since that would break a lot of
builds too.

-- 
Captain Logic is not steering this tugboat.


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

Bug#403076: Can't build aspell .deb from source package

[Brian Nelson]

Agustin Martin <[EMAIL PROTECTED]> writes:

> On Thu, Dec 14, 2006 at 02:51:00PM +0100, Ra??l S??nchez Siles wrote:
>> Package: aspell
>> Version: 0.60.4-4
>> Severity: important
>> Justification: fails to build from source
>> 
>> I downloaded the aspell 0.60.4-4 debian source, applied a little
>> patch(attached) and the tried to build. I did dch -a to increase locally
>> the debian version to 0.60.4-5 just to avoid confussion with official
>> packages.
>> 
>> I executed dpkg-buildsource -rfakeroot -uc -us -b and the packages
>> didn't build. Then I used DH_VERBOSE=1 fakerrot debian/rules binary 
>> and this didn't worked as well. I attach the buildlog.
>> 
>> I noticed there was a problem with the html doc, so I entered into the
>> manual dir and make html. It succeed.
>
> Funny, this does not happen the first time the package is built from
> sources, but happens second and further ones, probably a timestamp problem.

It's a problem in the build system.  The clean target is overly
aggressive and removes documentation that isn't normally rebuilt, so
subsequent builds fail.  I submitted a bug upstream about it a long time
ago.

-- 
Captain Logic is not steering this tugboat.


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

Bug#396034: closed by Brian Nelson <[EMAIL PROTECTED]> (Re: Bug#396034: qmake-qt4: CONFIG+=opengl doesn't add QtOpenGL include path or link -lQtOpenGL)

[Brian Nelson]

Tim Day <[EMAIL PROTECTED]> writes:

> On Mon, 2006-10-30 at 19:48 -0800, Debian Bug Tracking System wrote:
>> Brian Nelson wrote:
>> > Use "QT += opengl", not CONFIG.  See the Qt4 qmake documentation for
>> > more info.
>
> Thanks for the tip; QT += opengl (instead of CONFIG += opengl) does
> exactly what I was expecting.
>
> However, the current etch docs may be out of date.  My
>   file:///usr/share/qt4/doc/html/qmake-variable-reference.html
> makes no mention at all of a QT variable, and lists opengl along
> with all the others used via CONFIG.

I think that's been updated in the 4.2 docs.  However, you still have
this:

file:///usr/share/qt4/doc/html/qmake-project-files.html#declaring-qt-libraries

-- 
Captain Logic is not steering this tugboat.


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

Bug#394953: qt4-x11_4.2.1-1(hppa/unstable): FTBFS: missing defines

[Brian Nelson]

[EMAIL PROTECTED] writes:
[...]
> A full build log can be found at:
> http://buildd.debian.org/build.php?arch=hppa&pkg=qt4-x11&ver=4.2.1-1
>
> How about using the system inotify syscall numbers and such instead of
> private ones???

Ehhh, I don't know why they do that.  Maybe so that they can verify that
those arches work first?  Who knows...

-- 
Captain Logic is not steering this tugboat.


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

Bug#392558: libqt4-dev: Missing dependency for libsqlite-dev

[Brian Nelson]

Peter Schwindt <[EMAIL PROTECTED]> writes:

> Package: libqt4-dev
> Version: 4.2.0-1
> Severity: normal
>
> libqt4-dev needs libsqlite-dev in order to compile some software (f.e.
> psi)
>
> Dependency is missing, I had to reinstall by hand.

Err, which libsqlite-dev package (libsqlite0-dev or libsqlite3-dev)?
libsqlite-dev is a virtual package that those two provide.

-- 
Captain Logic is not steering this tugboat.


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

Bug#391902: qt4-x11: [m68k] missing inotify defines

[Brian Nelson]

Roman Zippel <[EMAIL PROTECTED]> writes:

> Hi,
>
> Is there any progress here?
> If there is anything I can do to help, please ask, but please don't ignore 
> this bug...
> Thanks.

Sorry, I was just dealing with RC bugs first...

To what file should those lines be added?  There isn't a buildd log for
m68k on buildd.d.o, so I can't see the actual error.

-- 
Captain Logic is not steering this tugboat.


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

Bug#392902: qmake-qt4 no longer escapes quotes for -Dfoo="value" on gcc command line

[Brian Nelson]

severity 392902 important
thanks

I'm downgrading this since a workaround has been presented, and I don't
think it's affecting the build of many packages.

Perhaps this should be closed since it sounds like a permanent change
from upstream?

-- 
Captain Logic is not steering this tugboat.


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

Bug#392902: qmake-qt4 no longer escapes quotes for -Dfoo="value" on gcc command line

[Brian Nelson]

"Steve M. Robbins" <[EMAIL PROTECTED]> writes:

> Package: libqt4-dev
> Version: 4.2.0-1
> Severity: grave
>
> Hello,
>
> Ipe uses qmake to build, with a "config.pri" file that contains the
> following:
>
>   IPEDOCDIR  = $${IPEPREFIX}/share/doc/ipe/doc
>
> Back in July, the generated Makefile resulted in
>
>   -DIPEDOCDIR=\"/usr/share/doc/ipe/doc\"
>
> passed to the g++ command line -- see the ipe buildd logs.  Now it is
> passing
>
>   -DIPEDOCDIR="/usr/share/doc/ipe/doc"
>
> which, not surprisingly, causes a syntax error and the build fails.

I suppose that's a side-effect of this qmake change:

2.10a -

   support for spaces in filenames.


> Can you put it back the way it was?

Err, well I can file a bug upstream.  I suppose it's possible to just
completely revert qmake to the version shipped in 4.1.4, but I don't
want to do that unless absolutely necessary.

-- 
Captain Logic is not steering this tugboat.


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

Bug#386460: Building a package with libqt4-dev on arm times out

[Brian Nelson]

Tobias Toedter <[EMAIL PROTECTED]> writes:

> On Friday 06 October 2006 04:01, Brian Nelson wrote:
>> Tobias Toedter <[EMAIL PROTECTED]> writes:
>> > Are you aware of this problem? Is anyone trying to compile qt4
>> > with -DQT_QLOCALE_USES_FCVT on arm, to see if the problem can be
>> > solved?
>>
>> Not me...  Did you ask the arm porters to try it?
>
> Hi,
>
> the arm porters did not offer to try this. However, they offered to provide 
> a chroot on an arm machine to me, so that I could recompile libqt with that 
> flag and see if the error persists or not.
>
> On IRC, we concluded that it might be best to first check with you guys 
> whether you know about this issue or not, so that the compilation of libqt 
> might be avoided.
>
> How should we go on from here? Do you have access to an arm machine to 
> recompile libqt? Note that I'm not a DD.

I just have access to whatever arm machines are available to developers,
but building on one of those would require getting all of the build
dependencies installed, and then (presumably) getting the built packages
installed to test the qbrew build.

However, the QT_QLOCALE_USES_FCVT macro still exists in the Qt4 source.
My understanding is that it would still be valid to use, so I can try
adding it in the next Qt4 upload and see what happens.  With a little
luck it'll fix the problem.

-- 
Captain Logic is not steering this tugboat.


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

Bug#386460: Building a package with libqt4-dev on arm times out

[Brian Nelson]

Tobias Toedter <[EMAIL PROTECTED]> writes:

> Package: libqt4-dev
> Version: 4.1.4-1.1
> Severity: normal
>
> Hi,
>
> my package qbrew FTBFS on arm, it links against libqt4. The reason for the 
> build failure is a time out while running this command:
> /usr/bin/uic-qt4 src/calcconfig.ui -o build/ui_calcconfig.h
>
> I've talked to the arm porters on IRC, and they suggested that it might be 
> related to libqt4 not being compiled with -DQT_QLOCALE_USES_FCVT, which was 
> a needed fix for libqt3 on arm. From the changelog:
>
> qt-x11-free (3:3.3.3-4.1) unstable; urgency=high 
>* On arm-linux, configure using -DQT_QLOCALE_USES_FCVT. Seems to be a
>  known issue, mentioned in the 3.3.2 release notes, but nowhere in
>  the 3.3.3 sources. Great! Thanks to Paul Brook and Jan Niehusmann for
>  the investigations. Closes: #270202.
>
> The build log of my package qbrew can be found here:
> 
>
> Are you aware of this problem? Is anyone trying to compile qt4 
> with -DQT_QLOCALE_USES_FCVT on arm, to see if the problem can be solved?

Not me...  Did you ask the arm porters to try it?

-- 
Captain Logic is not steering this tugboat.


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

Bug#346410: tagging 346410, merging 346410 324111

[Brian Nelson]

Loïc Minier <[EMAIL PROTECTED]> writes:

> tags 346410 - wontfix
> tags 346410 + patch
> stop
>
> Hi,
>
> On Thu, Jun 22, 2006, Brian Nelson wrote:
>> tags 346410 wontfix
>  (Would be nice to send a rationale to the submitter when a bug reaches
>  its final state on your side.)
>
>  Please apply the proposed patch; it makes lintian bark, but it's
>  lintian being overzealous, it should probably exclude /var too.
>
>  Please let me know if you want me to upload the proposed changes.

I'll be too busy to upload for a couple more days, so if you're feeling
impatient feel free to do so yourself.

-- 
Captain Logic is not steering this tugboat.

Bug#327618: dependency on libpq-dev for libqt4-dev

[Brian Nelson]

Margarita Manterola <[EMAIL PROTECTED]> writes:

> Hi!
>
> Georg Baum reopened bug 327618, since apparently libqt4-dev 
> stopped having the needed dependency on libpq-dev.
>
> I've been checking the packages on snapshot.debian.org, and found out that
> the dependency was dropped on 4.1.0-2, the relevant changelog entry seems
> to be:
>
>   * debian/control: added explicit dependencies for libqt4-dev on the
> Source-Version packages libqt4-core, libqt4-gui, libqt4-sql, and
> libqt4-qt3support.  These dependencies were accidentally dropped in
> the last version.  Also removed some unneeded dependencies.
>
> Apparently, libpq-dev for libqt4-dev was removed as unneeded dep.
>
> Brian, is this the case?  If so, could please explain it to Georg?

FWIW, I don't remember what I was thinking.  Removing that depending may
have been a mistake.  *shrug*

-- 
Captain Logic is not steering this tugboat.


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

Bug#382238: libqt4-sql not built against sqlite3

[Brian Nelson]

Martin Gruner <[EMAIL PROTECTED]> writes:

> Please make libqt4-sql support sqlite3. Currently it only links against 
> sqlite2. Trying to use the sqlite3 backend does not work. Thanks.
>
> ldd libQtSql.so | grep sqlite
> libsqlite.so.0 => /usr/lib/libsqlite.so.0 (0xa7cd3000)  #sqlite2

sqlite3 support is supposed to be statically linked--upstream actually
ships a copy of the source.  Any idea why it doesn't work?

-- 
Captain Logic is not steering this tugboat.


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

Bug#380253: libqt4-gui conflicts with libqt4-designer

[Brian Nelson]

Michael Bann <[EMAIL PROTECTED]> writes:

> The exact error message is the following:
> Preparing to replace libqt4-gui 4.1.3-3 (using
> .../libqt4-gui_4.1.4-1_i386.deb) ...
> Unpacking replacement libqt4-gui ...
> dpkg: error processing
> /var/cache/apt/archives/libqt4-gui_4.1.4-1_i386.deb (--unpack):
>  trying to overwrite `/usr/lib/libQtDesigner.so.4', which is also in
> package libqt4-designer
> Errors were encountered while processing:
>  /var/cache/apt/archives/libqt4-gui_4.1.4-1_i386.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> This problem happened while trying to update the system using apt-get
> upgrade.
>
> The incorrect behavior is that it didn't upgrade, and is blocking any
> further apt-get upgrades as it won't upgrade without this package
> successfully installed first.

Just purge libqt4-designer.  That package was merged into qt4-designer
back in version 4.0.1-3.

-- 
Captain Logic is not steering this tugboat.


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

Bug#374949: aspell-en: Checksum errors even after fresh install

[Brian Nelson]

tag 374949 wontfix
merge 374949 324111
thanks

Helge Hafting <[EMAIL PROTECTED]> writes:

> Package: aspell-en
> Version: 6.0-0-5
> Severity: normal
>
>
> I run debsums now and then, looking for signs of intrusion or disk
> errors.  When a package have errors, I reinstall it with
> apt-get --reinstall install package
> and retests. Suggested fix: update the wrong checksums.
> This package installs with the following
> checksum errors:   
> debsums: checksum mismatch aspell-en file /var/lib/aspell/en-common.rws
> debsums: checksum mismatch aspell-en file
> /var/lib/aspell/en-variant_0.rws
> debsums: checksum mismatch aspell-en file
> /var/lib/aspell/en-variant_1.rws
> debsums: checksum mismatch aspell-en file
> /var/lib/aspell/en-variant_2.rws
> debsums: checksum mismatch aspell-en file
> /var/lib/aspell/en_CA-w_accents-only.rws
> debsums: checksum mismatch aspell-en file
> /var/lib/aspell/en_CA-wo_accents-only.rws
> debsums: checksum mismatch aspell-en file
> /var/lib/aspell/en_GB-ise-w_accents-only.rws
> debsums: checksum mismatch aspell-en file
> /var/lib/aspell/en_GB-ise-wo_accents-only.rws
> debsums: checksum mismatch aspell-en file
> /var/lib/aspell/en_GB-ize-w_accents-only.rws
> debsums: checksum mismatch aspell-en file
> /var/lib/aspell/en_GB-ize-wo_accents-only.rws
> debsums: checksum mismatch aspell-en file
> /var/lib/aspell/en_US-w_accents-only.rws
> debsums: checksum mismatch aspell-en file
> /var/lib/aspell/en_US-wo_accents-only.rws
> debsums: checksum mismatch aspell-en file /var/lib/aspell/en.compat
>
>
> -- System Information:
> Debian Release: testing/unstable
>   APT prefers testing
>   APT policy: (900, 'testing'), (800, 'unstable'), (800, 'stable'), (700, 
> 'experimental')
> Architecture: i386 (i686)
> Shell:  /bin/sh linked to /bin/bash
> Kernel: Linux 2.6.17-mm1
> Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8)
>
> Versions of packages aspell-en depends on:
> ii  aspell0.60.4-4   GNU Aspell spell-checker
> ii  dictionaries-common   0.67.2 Common utilities for spelling 
> dict
>
> aspell-en recommends no packages.
>
> -- debconf-show failed
>

-- 
Captain Logic is not steering this tugboat.


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

Bug#373895: g++-4.1: "multiple definition" linker errors with code that used to work

[Brian Nelson]

Package: g++-4.1
Version: 4.1.1-5
Severity: important

While linking code that uses boost date_time headers, I get lots of
errors like:

foo.o: (.data+0x0): multiple definition of 
`_ZN5boost9date_time18parse_match_resultIT_E11PARSE_ERRORE'
bar.o:(.data+0x0): first defined here

That's from boost/date_time/string_parse_tree.hpp, and the relevant code
looks like:

  template
  struct parse_match_result
  {
[...]
static const short PARSE_ERROR;
  };
  template
  const short parse_match_result::PARSE_ERROR = -1;


Reverting to 4.1.1-2 fixes this problem.  I'm guessing it's a consequence
of the patch for PR c++/26068.


-- 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.16.4
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages g++-4.1 depends on:
ii  gcc-4.1   4.1.1-5The GNU C compiler
ii  gcc-4.1-base  4.1.1-5The GNU Compiler Collection (base 
ii  libc6 2.3.6-15   GNU C Library: Shared libraries
ii  libstdc++6-4.1-dev4.1.1-5The GNU Standard C++ Library v3 (d

g++-4.1 recommends no packages.

-- no debconf information


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

Bug#372800: boost: Yet more compiler warnings

[Brian Nelson]

Package: boost
Version: 1.33.1-4
Severity: normal
Tags: patch

Along the same lines as #308291 and #322386, here's a patch to fix
another warning about an unused variable.

/usr/include/boost/date_time/time_facet.hpp: At global scope:
/usr/include/boost/date_time/time_facet.hpp: In instantiation of 
'boost::date_time::time_facet::time_facet(size_t) 
[with time_type = boost::posix_time::ptime, CharT = char, OutItrT = 
std::ostreambuf_iterator >]':
/usr/include/boost/date_time/posix_time/posix_time_io.hpp:198:   instantiated 
from 'std::basic_ostream<_CharT, _Traits>& 
boost::posix_time::operator<<(std::basic_ostream<_CharT, _Traits>&, const 
boost::posix_time::time_duration&) [with CharT = char, Traits = 
std::char_traits]'
/usr/include/boost/date_time/time_facet.hpp:200: warning: unused parameter 
'a_ref'

diff -urN boost.old/date_time/time.hpp boost/date_time/time.hpp
--- boost.old/date_time/time.hpp	2006-06-11 12:53:49.0 -0700
+++ boost/date_time/time.hpp	2006-06-11 12:50:14.0 -0700
@@ -77,14 +77,14 @@
 /*! Optional bool parameter will return time zone as an offset 
  * (ie "+07:00"). Empty string is returned for classes that do 
  * not use a time_zone */
-std::string zone_name(bool as_offset=false) const
+std::string zone_name(bool =false) const
 {
   return time_system::zone_name(time_);
 }
 /*! Optional bool parameter will return time zone as an offset 
  * (ie "+07:00"). Empty string is returned for classes that do 
  * not use a time_zone */
-std::string zone_abbrev(bool as_offset=false) const
+std::string zone_abbrev(bool =false) const
 {
   return time_system::zone_name(time_);
 }
diff -urN boost.old/date_time/time_facet.hpp boost/date_time/time_facet.hpp
--- boost.old/date_time/time_facet.hpp	2006-06-11 12:53:49.0 -0700
+++ boost/date_time/time_facet.hpp	2006-06-11 12:37:46.0 -0700
@@ -197,7 +197,7 @@
 #endif
 
 //! sets default formats for ptime, local_date_time, and time_duration
-explicit time_facet(::size_t a_ref = 0) 
+explicit time_facet(::size_t = 0) 
   //: base_type(standard_format),
   : base_type(default_time_format), 
 m_time_duration_format(string_type(duration_sign_negative_only) + default_time_duration_format)


-- 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.16.4
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Bug#368883: qt4-x11: FTBFS on alpha

[Brian Nelson]

Pierre Habouzit <[EMAIL PROTECTED]> writes:

> tag 368883 + pending
> thanks
>
> Le Sam 3 Juin 2006 10:57, Samuel Thibault a écrit :
>> Hi,
>>
>> Could this be fixed any time soon?  qt4-x11 is currently blocking no
>> less than 83 packages.
>>
>> Samuel
>
> that one is quite annoying.
>
> Brian: will you have time to fix that soon (like in less than a couple 
> of days ?) else I'll do an upload just to fix the alpha FTBFS now that 
> there is a patch.
>
> If I've no news from you, I suppose I'll do an upload on sunday.

I should be able to do it today (Saturday). If not, go ahead and upload
on Sunday.

-- 
Captain Logic is not steering this tugboat.

Bug#369835: qt4-x11: uninstallable with nvidia-glx-dev

[Brian Nelson]

severity 369835 normal
thanks

[Problems involving non-free packages are not RC bugs]

Mathieu Malaterre <[EMAIL PROTECTED]> writes:

> Package: qt4-x11
> Severity: grave
> Justification: renders package unusable
>
>
> I simply cannot install qt4-x11, therefore I cannot get the
> libQtAssistantClient libraries (Bug #355902).

Why would this be qt4's problem?  I'd think nvidia-glx-dev would be the
one that needs fixing.

-- 
Captain Logic is not steering this tugboat.


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

Bug#368883: qt4-x11: FTBFS on alpha

[Brian Nelson]

Filipus Klutiero <[EMAIL PROTECTED]> writes:

> gcc ICEd when attempting to build qt4-x11 on alpha on 2006-05-14. I
> don't know what's the issue and what could fix. However, 4.1.2-1 built
> and the changes to -2 seem minimal, so it should be easy to check
> whether there was a gcc regression or the qt4-x11 changes triggered the
> FTBFS and need
> a workaround.

Isn't an ICE always a compiler bug?  In any case, nothing in the Qt code
changed between -1 and -2, so it's certainly a GCC regression.

-- 
Captain Logic is not steering this tugboat.


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

Bug#357136: debug building by default

[Brian Nelson]

This is scheduled to be fixed upstream for 4.2.0:

http://www.trolltech.com/developer/task-tracker/index_html?method=entry&id=111573

(assuming the debug default on linux is a bug)

-- 
Captain Logic is not steering this tugboat.


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

Bug#358972: Fixed in 4.1.2?

[Brian Nelson]

Hi Benjamin,

Both of these bugs you reported were regressions in 4.1.1.  Can you test
the 4.1.2 packages and see if either of these bugs are fixed there?

-- 
Captain Logic is not steering this tugboat.


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

Bug#365933: offlineimap: Dies with "instance has no attribute 'getrestoreatime'"

[Brian Nelson]

John Goerzen <[EMAIL PROTECTED]> writes:

> On Wed, May 03, 2006 at 02:11:47PM -0700, Brian Nelson wrote:
>> >> trying to sync between two IMAP servers (both courier 0.47-13, the
>> >> remote one using ssl), I get:
>> >
>> > Did you enable restoreatime in your config file?
>> 
>> Nope.
>
> OK, I'm going to need some more information from you then.  I'm using
> 4.0.12 here and am not having trouble at all.
>
> Can you send me along your config file, and also tell me at what point
> do you get the error?

The error happens immediately on the first folder.  Here's the config
file:

[general]
accounts = Personal, Lists
ui = Noninteractive.Basic, Noninteractive.Quiet
maxsyncaccounts = 2

[Account Lists]
localrepository = Local
remoterepository = RemoteLists
autorefresh = 10
maxconnections = 3

[Account Personal]
localrepository = Local
remoterepository = RemotePersonal
maxconnections = 3
autorefresh = 1

[Repository Local]
type = IMAP
remotehost = localhost
ssl = no
remoteuser = nelson
remotepassfile = ~/.offlineimap.pass
holdconnectionopen = yes

[Repository RemoteLists]
type = IMAP
remotehost = mail.bignachos.net
ssl = yes
remoteuser = nelson
remotepassfile = ~/.offlineimap.pass
#preauthtunnel = ssh -q mail.bignachos.net '/usr/bin/imapd ./Maildir'
holdconnectionopen = no
folderfilter = lambda foldername: foldername not in ['INBOX', 
'INBOX.catchmedia',
 'INBOX.debian']
#nametrans = lambda foldername: re.sub('^INBOX\.', '.', foldername)

[Repository RemotePersonal]
type = IMAP
remotehost = mail.bignachos.net
ssl = yes
remoteuser = nelson
remotepassfile = ~/.offlineimap.pass
#preauthtunnel = ssh -q mail.bignachos.net '/usr/bin/imapd ./Maildir'
holdconnectionopen = no
folderfilter = lambda foldername: foldername in ['INBOX', 'INBOX.catchmedia',
 'INBOX.debian']
#nametrans = lambda foldername: re.sub('^INBOX\.', '.', foldername)

> Are you sure you have the current OfflineIMAP installed?  (Can you try
> removing and reinstalling it?)

Yeah, it was definitely 4.0.12, and the same error occurred on two
different machines after upgrading.  I'm using 4.0.11 right now though
so that I can still get my mail.  :)

-- 
Captain Logic is not steering this tugboat.

Bug#365933: offlineimap: Dies with "instance has no attribute 'getrestoreatime'"

[Brian Nelson]

John Goerzen <[EMAIL PROTECTED]> writes:

> On Wed, May 03, 2006 at 01:18:21PM -0700, Brian Nelson wrote:
>> Package: offlineimap
>> Version: 4.0.12
>> Severity: important
>> 
>> It appears the restoreatime patch doesn't work for my setup.  When
>> trying to sync between two IMAP servers (both courier 0.47-13, the
>> remote one using ssl), I get:
>
> Did you enable restoreatime in your config file?

Nope.

-- 
Captain Logic is not steering this tugboat.


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

Bug#365933: offlineimap: Dies with "instance has no attribute 'getrestoreatime'"

[Brian Nelson]

Package: offlineimap
Version: 4.0.12
Severity: important

It appears the restoreatime patch doesn't work for my setup.  When
trying to sync between two IMAP servers (both courier 0.47-13, the
remote one using ssl), I get:

Thread 'Folder sync Personal[INBOX]' terminated with exception:
Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/offlineimap/threadutil.py", line 153, 
in run
Thread.run(self)
  File "/usr/lib/python2.3/threading.py", line 422, in run
self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib/python2.3/site-packages/offlineimap/accounts.py", line 172, in 
syncfolder
if localrepos.getrestoreatime():
AttributeError: MappedIMAPRepository instance has no attribute 'getrestoreatime'


Downgrading to 4.0.11 fixes the problem.


-- 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.16.4
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages offlineimap depends on:
ii  python2.3 2.3.5-9.1  An interactive high-level object-o

offlineimap recommends no packages.

-- no debconf information

-- 
Captain Logic is not steering this tugboat.


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

Bug#357136: libqt4-dev sould depend on libqt4-debug-dev

[Brian Nelson]

"Jeremiah Savage" <[EMAIL PROTECTED]> writes:

> Package: libqt4-dev
> Version: 4.1.1-1
>
> When building the tutorial "Hello World" example, I got the following error:
> 
> $ qmake-qt4 -project
> $ qmake-qt4
> $ make
> g++ -c -pipe -g -Wall -W -D_REENTRANT  -DQT_GUI_LIB -DQT_CORE_LIB
> -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore
> -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -I. -I. -o hello.o
> hello.cc
> g++  -o kdeprog hello.o-L/usr/lib -lQtGui_debug -lQtCore_debug -lpthread
> /usr/bin/ld: cannot find -lQtGui_debug
> collect2: ld returned 1 exit status
> make: *** [kdeprog] Error 1
> 
>
> Installing libqt4-debug-dev allowed the program to compile without error:

Well, OK, but then the correct fix would be to make qmake not link
against the debug libs by default.  Having libqt4-dev depend on
libqt4-debug-dev doesn't make any sense.

-- 
Captain Logic is not steering this tugboat.


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

Bug#354266: libqt4-gui: Error loading MNG file(s)

[Brian Nelson]

Anthony Awtrey <[EMAIL PROTECTED]> writes:

> I was just about to report this as a bug in the packaging of the qt4-x11
> files, so I'll just append your report. We saw that when we linked to
> the debug libs we got animated gif and mng support, but with the
> optimized libs they didn't work. There are some missing files missing
> from the libqt4-gui package's install file:
>
>
> In the qt4-x11/debian/libqt4-gui.install file:
>
> usr/lib/libQtGui.so.*
> usr/lib/libQtOpenGL.so.*
> usr/bin/qtconfig-qt4
> usr/lib/qt4/plugins/imageformats/libqjpeg.so
> usr/lib/qt4/plugins/imageformats/libqgif.so   <-- Add this
> usr/lib/qt4/plugins/imageformats/libqmng.so   <-- Add this
> usr/lib/qt4/plugins/codecs/*codecs.so

Thanks, I'll be sure to add these to the package in the next release.

> It takes a long time to rebuild (like over an hour on our 2.5GHz box
> with a gig of RAM), but when it is done you should have debs that will work.
>
> I think the problem exists because it is easy for the debug files to get
> masked in as "*debug.so", but the non-debug files must be specified by
> name or they are not included in the package.

Indeed.  Unfortunately, there's no way with dh_install AFAIK to use
wildcards with a not clause, e.g. *.so files that don't end in
_debug.so.

-- 
Captain Logic is not steering this tugboat.


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

Bug#349640: FTBFS: undefined reference to `acommon::BlockSList::clear()'

[Brian Nelson]

On which architecture does this fail?


Max Kellermann <[EMAIL PROTECTED]> writes:

> Package: aspell
> Version: 0.60.4-1
> Tags: FTBFS
> Severity: minor
>
> tail of the build log:
>
> [...]
> creating libpspell.la
> (cd .libs && rm -f libpspell.la && ln -s ../libpspell.la libpspell.la)
> depbase=`echo prog/compress.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \
> if cc -DHAVE_CONFIG_H -I. -I. -I./gen  -I./gen -I./common
> -I./interfaces/cc/ -I./modules/speller/default/
> -DLOCALEDIR=\"/usr/share/locale\"   -g -Wall -O2 -MT prog/compress.o
> -MD -MP -MF "$depbase.Tpo" -c -o prog/compress.o prog/compress.c; \
> then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo";
> exit 1; fi
> /bin/sh ./libtool --tag=CC --mode=link cc  -g -Wall -O2   -o
> word-list-compress  prog/compress.o  -ldl -ldl 
> cc -g -Wall -O2 -o word-list-compress prog/compress.o  -ldl
> depbase=`echo prog/aspell.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \
> if g++ -DHAVE_CONFIG_H -I. -I. -I./gen  -I./gen -I./common
> -I./interfaces/cc/ -I./modules/speller/default/
> -DLOCALEDIR=\"/usr/share/locale\"   -g -Wall -O2 -fno-exceptions -MT
> prog/aspell.o -MD -MP -MF "$depbase.Tpo" -c -o prog/aspell.o
> prog/aspell.cpp; \
> then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo";
> exit 1; fi
> depbase=`echo prog/check_funs.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; \
> if g++ -DHAVE_CONFIG_H -I. -I. -I./gen  -I./gen -I./common
> -I./interfaces/cc/ -I./modules/speller/default/
> -DLOCALEDIR=\"/usr/share/locale\"   -g -Wall -O2 -fno-exceptions -MT
> prog/check_funs.o -MD -MP -MF "$depbase.Tpo" -c -o prog/check_funs.o
> prog/check_funs.cpp; \
> then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo";
> exit 1; fi
> depbase=`echo prog/checker_string.o | sed
> 's|[^/]*$|.deps/&|;s|\.o$||'`; \
> if g++ -DHAVE_CONFIG_H -I. -I. -I./gen  -I./gen -I./common
> -I./interfaces/cc/ -I./modules/speller/default/
> -DLOCALEDIR=\"/usr/share/locale\"   -g -Wall -O2 -fno-exceptions -MT
> prog/checker_string.o -MD -MP -MF "$depbase.Tpo" -c -o
> prog/checker_string.o prog/checker_string.cpp; \
> then mv -f "$depbase.Tpo" "$depbase.Po"; else rm -f "$depbase.Tpo";
> exit 1; fi
> /bin/sh ./libtool --tag=CXX --mode=link g++  -g -Wall -O2
> -fno-exceptions   -o aspell  prog/aspell.o prog/check_funs.o
> prog/checker_string.o libaspell.la -lncursesw -ldl -ldl 
> g++ -g -Wall -O2 -fno-exceptions -o .libs/aspell prog/aspell.o
> prog/check_funs.o prog/checker_string.o  ./.libs/libaspell.so
> -lncursesw -ldl
> ./.libs/libaspell.so: undefined reference to
> `acommon::HashTable::init(unsigned int)'
> ./.libs/libaspell.so: undefined reference to
> `acommon::HashTable::del()'
> ./.libs/libaspell.so: undefined reference to
> `acommon::BlockSList::clear()'
> collect2: ld returned 1 exit status
> make[2]: *** [aspell] Error 1
> make[2]: Leaving directory `/opt/debian/build/aspell-0.60.4'
>

-- 
Captain Logic is not steering this tugboat.


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

Bug#349899: aspell does not recognize correct accented words

[Brian Nelson]

Nicolas Évrard <[EMAIL PROTECTED]> writes:

> Hello, while using aspell I noticed that it did not find accented 
> character in its dictionnary:
>
> [EMAIL PROTECTED]:~$ echo "école" | aspell -a
> @(#) International Ispell Version 3.1.20 (but really Aspell 0.60.4)
> & école 15 0: recole, encolle, colle, recoler, recoles, recolle, accole, 
> encoller, encolles, coller, colles, collet, recoller, recolles, recolai
>
> [EMAIL PROTECTED]:~$ echo "mangé" | aspell -a
> @(#) International Ispell Version 3.1.20 (but really Aspell 0.60.4)
> & mangé 20 0: mange, manger, manges, mage, nage, mages, mangea, mangez, 
> mangue, ange, marge, fange, lange, mande, manne, manse, mante, range, d'ange, 
> l'ange
>
> [EMAIL PROTECTED]:~$ echo "mangé" | aspell -a --encoding=utf-8
> @(#) International Ispell Version 3.1.20 (but really Aspell 0.60.4)
> & mangé 20 0: mange, manger, manges, mage, nage, mages, mangea, mangez, 
> mangue, ange, marge, fange, lange, mande, manne, manse, mante, range, d'ange, 
> l'ange

Odd.  Using LANG=en_US.UTF-8 and trying the same commands you're using
(with --lang=fr to override the dictionary) seems to work fine.
However, if I export LANG=fr_BE.UTF-8, I see the same thing as you.  I'm
not sure what's going on...

-- 
Captain Logic is not steering this tugboat.

Bug#349438: libqt4-dev: Need symlink to /usr/bin/rcc

[Brian Nelson]

Steve Halasz <[EMAIL PROTECTED]> writes:

> To build qgis from CVS (--with-qtdir=/usr/share/qt4) I need a symlink
> from /usr/share/qt4/bin/rcc to /usr/bin/rcc. I could work around this
> in qgis, but it seems reasonable to have the link there.

Sure, I'll add it in the next upload.

-- 
Captain Logic is not steering this tugboat.


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

Bug#349141: /usr/lib/libQtSql.so: undefined reference to `mysql ...

[Brian Nelson]

[EMAIL PROTECTED] writes:

> Package: libqt4-sql
> Version: 4.1.0-3
>
>
> Hi, when i try to use this lib in my software I get:
>
> linux>make
> g++  -o prova main.o   -L/usr/lib -lQtSql -lQtGui -lQtCore -lpthread
> /usr/lib/libQtSql.so: undefined reference to [EMAIL PROTECTED]'
> /usr/lib/libQtSql.so: undefined reference to [EMAIL PROTECTED]'
> /usr/lib/libQtSql.so: undefined reference to [EMAIL PROTECTED]'
> /usr/lib/libQtSql.so: undefined reference to [EMAIL PROTECTED]'
> /usr/lib/libQtSql.so: undefined reference to [EMAIL PROTECTED]'
> ...
> ...
> ...
> /usr/lib/libQtSql.so: undefined reference to [EMAIL PROTECTED]'
> /usr/lib/libQtSql.so: undefined reference to [EMAIL PROTECTED]'
> /usr/lib/libQtSql.so: undefined reference to [EMAIL PROTECTED]'
> collect2: ld returned 1 exit status
> make: *** [prova] Error 1

Does upgrading libmysqlclient15 to 5.0.18-7 fix it?  I think this might
be related to this bug:

http://bugs.debian.org/348854

-- 
Captain Logic is not steering this tugboat.


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

Bug#348400: gaim & sylpheec-claws won't start, libaspell errors

[Brian Nelson]

"Rodney D. Myers" <[EMAIL PROTECTED]> writes:

> package: libaspell
> version: 0.60.2+2005012
>
> debian release: debian stable/sarge
> apt preferences: stable
> architecture: i386
>
> When trying to run either gaim or sylpheed-claws, with a fresh install,
> from the command line, I get this error message;
>
> relocation error: /usr/lib/libaspell.so.15: undefined symbol:
> _ZTVN10__cxxabiv120__si_class_type_infoE

I tested both of these programs in a sarge chroot on my system and could
not reproduce this error with either one.  I'm completely at a loss to
explain why you're experiencing this problem.

Does running it like this help?

$ LD_PRELOAD=libstdc++.so.5 gaim

-- 
Captain Logic is not steering this tugboat.


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

Bug#319513: xorg-x11: xvmc support for the via unichrome family

[Brian Nelson]

Unichrome support is included upstream in the 6.9.0 release, isn't it?
So this bug can presumably be closed...

-- 
Captain Logic is not steering this tugboat.


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

Bug#348102: reportbug: Do not give users the option of filing bugs of severities higher than "normal"

[Brian Nelson]

Package: reportbug
Version: 3.18
Severity: critical

(Severity a tad over-inflated to make a point)

I'm sick of continuously having to downgrade bug severities because
users always over-inflate them.  By definition, a bug is at least
severity important to a user, or otherwise they wouldn't file it.  Or
something.  I don't particularly understand the phenomenon, but I do
wish it would go away.

Please give users only the options normal, minor, and wishlist.  A
clueful enough user can edit the pseudo-header themselves to file higher
severity bugs.  Otherwise, the maintainer can increase the severity at
his or her discretion.


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

Versions of packages reportbug depends on:
ii  python2.3 2.3.5-9An interactive high-level object-o

Versions of packages reportbug recommends:
ii  python2.3-iconvcodec  1.1.2-2Python universal Unicode codec, us

-- no debconf information


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

Bug#348092: libqt4-gui: Built to not support gifs (as per build default)

[Brian Nelson]

severity 348092 wishlist
thanks

Russell Jones <[EMAIL PROTECTED]> writes:

> Package: libqt4-gui
> Version: 4.0.1-5
> Severity: important

Woah, hey now, don't you think that severity is a little over-inflated?

> I understand that by default the Qt configure script disables gif
> support. It can be re-enabled in debian/rules by supplying -qt-gif
> as a parameter to ./configure.  I have not tested this thoroughly, but I
> cannot find any mention of gif in the debian directory, so I assume this
> has not been changed. I have had a problem when a Qt4 application I
> compiled tried to load a gif, but due to the nature of the application
> it's hard to test whether there's a problem or not.

Hmm, well I don't any reason to not enable it, so I'll include it in the
next upload.

-- 
Captain Logic is not steering this tugboat.


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

Bug#347589: aspell: doesn't handle \% correctly for .tex files

[Brian Nelson]

tag 347589 upstream
forwarded 347589 
http://sourceforge.net/tracker/index.php?func=detail&aid=1405044&group_id=245&atid=100245
thanks

Matthew Roberts <[EMAIL PROTECTED]> writes:

> When spell checking a .tex file, aspell assumes any '%' character will
> result in a comment on the remainder of the line and ignores remaining
> words.  However, a '\%' sequence denotes that a percent sign should be
> printed, and spell checking should continue on the rest of the line.
>
> The following line will not generate a mistake in aspell:
>
> More than 60\% of the students feilled the exam.

I was able to reproduce this on 0.60.4 as well, so I forwarded it
upstream to
http://sourceforge.net/tracker/index.php?func=detail&aid=1405044&group_id=245&atid=100245.

-- 
Captain Logic is not steering this tugboat.


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

Bug#347191: aspell: Dumps core with when (r)eplacing with 00

[Brian Nelson]

tag 347191 upstream
forwarded 347191 
http://sourceforge.net/tracker/index.php?func=detail&aid=1405037&group_id=245&atid=100245
thanks

Panu Kalliokoski <[EMAIL PROTECTED]> writes:

> On Mon, Jan 09, 2006 at 09:31:45AM -0800, Brian Nelson wrote:
>> What versions of aspell, libaspell15, and aspell-fi do you have
>> installed?
>
> $ dpkg -l aspell-bin libaspell15 aspell-fi
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: 
> uppercase=bad)
> ||/ NameVersion Description
> +++-===-===-==
> ii  aspell-bin  0.60.2+20050121-2   GNU Aspell standalone spell-check 
> utilities
> ii  libaspell15 0.60.2+20050121-2   The GNU Aspell spell-checker 
> runtime toolkits
> ii  aspell-fi   0.7-14.1The Finnish dictionary for aspell

I was able to reproduce this on current aspell packages in unstable as
well, so I forwarded it upstream.

-- 
Captain Logic is not steering this tugboat.


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

Bug#347782: Add sqlite support to Qt-4.1.0

[Brian Nelson]

Thorvald Natvig <[EMAIL PROTECTED]> writes:

> Could you add sqlite3 support to Qt? The source is included in the Qt
> distribution, so it's just a matter of adding -qt-sql-sqlite to the
> configure string.

Already added to 4.1.0-2, which is currently sitting in the NEW queue
and should become available shortly.

-- 
Captain Logic is not steering this tugboat.


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

Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package

[Brian Nelson]

"Kevin B. McCarty" <[EMAIL PROTECTED]> writes:

> Brian Nelson wrote:
>
>> It's not clear to me that splitting out the headers is actually a good
>> thing (it's very annoying for autobuilders since the corresponding -dev
>> package won't be installable until the new version has been autobuilt),
>> so I certainly don't think policy should endorse it.
>
> It wouldn't be an endorsement, just a permission.  It seems to me that
> policy currently prohibits -headers packages for shared libraries by
> saying that development files must be in the -dev package.  Do you feel
> -headers packages _should_ be explicitly prohibited?

Sure, I don't see any advantage to having them.

> My main motive in making the suggestion is that when the headers are
> architecture-independent and there are a lot of them, splitting them out
> into a separate arch:all package can save a lot of archive space.  (I
> don't know what the motive was of the developers who created packages
> like libqt3-headers, which are arch:any.)

Get:1 http://rubeus sid/main libqt3-headers 3:3.3.5-3 [364kB]
Fetched 364kB in 1s (226kB/s)

I wouldn't call 364kB a lot of saved archive space, and you'd be
hard-pressed to find a package with more headers than Qt.

>> "Kevin B. McCarty" <[EMAIL PROTECTED]> writes:
>>>CC'ed to debian-devel in case anyone wants to add to or disagree with
>>>this suggestion.
>> 
>> Uh, no it's not.
>
> For "CC'ed" read "X-Debbugs-CC'ed".  The web archive of the mailing list
> hasn't been updated since early this morning (as of this writing), but
> you can see my email in the gated newsgroup, for instance on Google
> Groups, http://groups.google.com/group/linux.debian.devel .
> If it isn't showing up to debian-devel email subscribers, something
> strange is going on (I read the list through the web archive so I don't
> know whether or not this is the case).

Oh, I guess the mail I replied to hadn't been processed by the submit
bot then.  My mistake.

-- 
Captain Logic is not steering this tugboat.


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

Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package

[Brian Nelson]

"Kevin B. McCarty" <[EMAIL PROTECTED]> writes:

> Could Policy be amended slightly to explicitly permit library source
> packages to create a -headers package containing include files?
>
> I am thinking that something like the following could be added between
> the existing first and second paragraphs of Section 8.4, "Development
> files",
> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-dev
>
> [begin suggested text]
> If your library source package includes a large number of header files
> that are to be installed in /usr/include or subdirectories thereof, it
> may place them in a binary package called librarynamesoversion-headers
> or (if you prefer only to support one development version at a time, or
> if the library API is preserved across different soversions)
> libraryname-headers.  If you do this, the development package must
> Depend upon the headers package.  If the development package is
> architecture-dependent and the headers package is not, the development
> package should not require exactly the same version of the headers
> package in order to prevent problems arising from binary NMUs.
> [end suggested text]
>
> Without this or a similar text, it is not clear to me that source
> packages creating -headers binary packages are in compliance
> with Policy, which currently says "The development files associated to a
> shared library need to be placed in a package called
> librarynamesoversion-dev, or if you prefer only to support one
> development version at a time, libraryname-dev."

It's not clear to me that splitting out the headers is actually a good
thing (it's very annoying for autobuilders since the corresponding -dev
package won't be installable until the new version has been autobuilt),
so I certainly don't think policy should endorse it.

> CC'ed to debian-devel in case anyone wants to add to or disagree with
> this suggestion.

Uh, no it's not.

-- 
Captain Logic is not steering this tugboat.


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

Bug#347360: qt4-x11: FTBFS in ARM (no matching function for call to 'getXDefault(const char [4], const char [6], qreal*))

[Brian Nelson]

Isaac Clerencia <[EMAIL PROTECTED]> writes:

> qt4 is FTBFS'ing in ARM with the following problem:
> kernel/qapplication_x11.cpp: In function 'void
>   qt_init(QApplicationPrivate*, int, Display*, Qt::HANDLE, Qt::HANDLE)':
> kernel/qapplication_x11.cpp:1547: error: no matching function for call
>   to 'getXDefault(const char [4], const char [6], qreal*)'
> kernel/qapplication_x11.cpp:1174: note: candidates are: void
>   getXDefault(const char*, const char*, int*)
> kernel/qapplication_x11.cpp:1185: note: void
>   getXDefault(const char*, const char*, double*)
> kernel/qapplication_x11.cpp:1196: note: void
>   getXDefault(const char*, const char*, bool*)
> kernel/qapplication_x11.cpp: At global scope:
> kernel/qapplication_x11.cpp:1185: warning: 'void getXDefault(const
>   char*, const char*, double*)' defined but not used
>
> the problem is that in ARM qreal is defined as float and not as double,

Do you know if there's a good reason for this?

> I guess the easiest fix would be to add another implementation of
> getXDefault with prototype: void getXDefault(const char*, const char*,
> float*) similar to the double one in kernel/qapplication_x11.cpp.

I already applied a different fix in svn--I changed the qreal
declaration to double instead of float, which is how it was declared
before 4.1.0.  If you think this will be problematic for some reason,
let me know.

-- 
Captain Logic is not steering this tugboat.


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

Bug#335831: qt4-x11 4.1.0-1 still FTBFS in mips/mipsel

[Brian Nelson]

Isaac Clerencia <[EMAIL PROTECTED]> writes:

> It looks like the problem still exists, I'm attaching a fixed qatomic32.s 
> created by Ryan Murray.

Eh, did no one see this message?

http://lists.debian.org/debian-mips/2006/01/msg00021.html

-- 
Captain Logic is not steering this tugboat.


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

Bug#346605: libqt4-dev: linker error cannot find -lQt3Support_debug when compiling in debug mode

[Brian Nelson]

Benjamin Mesing <[EMAIL PROTECTED]> writes:

> An update of libqt4-debug to 4.1 (which was still 4.0.1 before) fixed
> this issue and brought it down to bug 346586.
> So probably libqt4-dev 4.1 should conflict with libqt4-debug <= 4.0.1?

Conflicts with earlier versions are frowned upon in policy (7.3).  I
think the right thing to do would be to split all of the _debug.so
symlinks into a separate libqt4-debug-dev package.  The current scheme
of lumping them all into libqt4-dev and not explicitly depending on
libqt4-debug is broken, I think.

Then, if you're going to build and link against the debug libs, you just
declare a build dependency on libqt4-debug-dev.

-- 
Captain Logic is not steering this tugboat.


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

Bug#346586: libqt4-dev: linker error: /usr/lib/libQtSql.so: undefined reference to

[Brian Nelson]

Benjamin Mesing <[EMAIL PROTECTED]> writes:

>> /usr/lib/libQtSql.so: undefined reference to [EMAIL PROTECTED]'
>> /usr/lib/libQtSql.so: undefined reference to [EMAIL PROTECTED]'
>> [...]
> An update of libmysqlclient14(-dev) to version 4.1.15-1 solved the
> issue. 
> So maybe libqt4-dev should depend on libmysqlclient14(-dev) >= 4.1.15-1?
>
> Btw. I have a wishlist bug to build against libmysqlclient15 instead of
> 14, any chance you will switch over at one point? Couldn't find a
> relevant wishlist bug for your packages.

Yeah, I plan to do so for the next upload.

-- 
Captain Logic is not steering this tugboat.


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

Bug#347251: libqt4-gui: Most icons don't load for some reason (and crash from time to time)

[Brian Nelson]

severity 347251 important
thanks

"Nach M. S." <[EMAIL PROTECTED]> writes:

> Since the upgrade to Qt 4.1.0, I noticed icons pretty much everywhere
> have disappeared. For example, load up Designer, aside from the Window
> icon, icons everywhere else such as tool bar or for the item pains and
> menus have all disappeared.

Try removing libqt4-debug and see if the problem still occurs.  If that
fixes it, then it's due to some upstream problems with the build system
and plugins loading.  See, for example, #337764, #337847, #341807 ...

> In my own apps I noticed the same thing, icons vanished everywhere but
> from the Window icons. Also in my own apps, I've gotten this:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1220241728 (LWP 22025)]
> 0xb7bb8893 in QImage::scanLine () from /usr/lib/libQtGui.so.4

Hmm, I haven't seen this before.  I wonder if it's related, or if it's
yet another bug...

-- 
Captain Logic is not steering this tugboat.


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

Bug#347191: aspell: Dumps core with when (r)eplacing with 00

[Brian Nelson]

Panu Kalliokoski <[EMAIL PROTECTED]> writes:

> I'm using aspell with the finnish dictionary.
>
> When I run aspell on a file containing the three characters "OO\n" (that
> is, big Oh, big Oh, newline, and use the (r)eplace functionality to
> replace "OO" with "00" (zero, zero), aspell dumps core.

What versions of aspell, libaspell15, and aspell-fi do you have
installed?

-- 
Captain Logic is not steering this tugboat.


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

Bug#342658: libqt4-core: Locking Issue?

[Brian Nelson]

Ian Wienand <[EMAIL PROTECTED]> writes:

> On Mon, Dec 12, 2005 at 01:39:13PM +0200, Brian Nelson wrote:
>> Ian Wienand <[EMAIL PROTECTED]> writes:
>> 
>> [...]
>> > (gdb) back
>> > #0  0x21363d81 in __pthread_sigsuspend (set=0x6fbf7270)
>> > at ../linuxthreads/sysdeps/unix/sysv/linux/ia64/pt-sigsuspend.c:32
>> > #1  0x21362380 in __pthread_wait_for_restart_signal 
>> > (self=0x2137edc8) at pthread.c:1216
>> > #2  0x2135d050 in __pthread_cond_wait (cond=0x60004338, 
>> > mutex=0x600042e0) at restart.h:34
>> > #3  0x2103f400 in QReadWriteLock::lockForWrite () from 
>> > /usr/lib/libQtCore.so.4
>> > #4  0x211d0340 in qt_addObject () from /usr/lib/libQtCore.so.4
>> > #5  0x211d0e50 in QObject::QObject () from /usr/lib/libQtCore.so.4
>> > #6  0x21184e20 in QFactoryLoader::QFactoryLoader () from 
>> > /usr/lib/libQtCore.so.4
>> > #7  0x2120b670 in QTextDecoder::~QTextDecoder () from 
>> > /usr/lib/libQtCore.so.4
>> > #8  0x21210ef0 in QTextCodec::codecForName () from 
>> > /usr/lib/libQtCore.so.4
>> > #9  0x2120c160 in QTextEncoder::fromUnicode () from 
>> > /usr/lib/libQtCore.so.4
>> > #10 0x2120efd0 in QTextCodec::codecForLocale () from 
>> > /usr/lib/libQtCore.so.4
>> > #11 0x210b30d0 in QString::toLocal8Bit () from 
>> > /usr/lib/libQtCore.so.4
>> > #12 0x210e04b0 in locale_encode () from /usr/lib/libQtCore.so.4
>> > #13 0x210e06f0 in QFile::encodeName () from /usr/lib/libQtCore.so.4
>> > #14 0x210f8e20 in QFileEngineHandler::QFileEngineHandler () from 
>> > /usr/lib/libQtCore.so.4
>> > #15 0x210e5460 in QFile::open () from /usr/lib/libQtCore.so.4
>> > #16 0x40001070 in main ()
>> >
>> > It seems that lock in qt_addObject has already been taken by
>> > something.  Has anything changed in this area recently?
>> 
>> In the code?  No, not by me.  I don't see any reason why that lock would
>> be taken indefinitely anyway.
>
> I ruled out a few things, namely it seems to happen with both
> LinuxThreads and NPTL, so it seems unlikely that the threading
> library/kernel is at fault.
>
> The changes-4.0.1 file says that support has been added for SGI Altix,
> which means someone must have been interested in getting it working on
> IA64?  Any idea who that person might be?

No, no idea.

Does this still happen with Qt 4.1.0?

-- 
Captain Logic is not steering this tugboat.


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

Bug#345801: main window empty

[Brian Nelson]

Hadmut Danisch <[EMAIL PROTECTED]> writes:

> On Thu, Jan 05, 2006 at 06:08:00PM -0500, Brian Nelson wrote:
>> 
>> Does the new version, 4.1.0, which just hit unstable today, look better
>> to you?
>
>
> Yup, now there is a menu bar. 
>
> But shouldn't there be a status bar at the bottom as well? 

There is--it's just empty.  It appears in the .ui though.

-- 
Captain Logic is not steering this tugboat.


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

Bug#345801: main window empty

[Brian Nelson]

[EMAIL PROTECTED] writes:

> when I start the qt4 designer, I get the full workbench, everything
> seems ok. But when starting a new form and choosing a "main window",
> the created window is just empty. Regarding to the docs it should have
> the usual decoration such as a menu bar. It should be possible to
> create a missing menu bar through the context menu. 
>
> But there is neither a menu bar, nor does the context menu allow
> this. The other decorations are missing as well. 
>
> Any idea?

Does the new version, 4.1.0, which just hit unstable today, look better
to you?

-- 
Captain Logic is not steering this tugboat.


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

Bug#345388: libqt4-dev: qmake adds -L/usr/lib

[Brian Nelson]

Marc Glisse <[EMAIL PROTECTED]> writes:

> qmake adds -L/usr/lib to (the beginning of) LIBS. This is unneeded, and
> actually causes many problems.

I agree it's unneeded, but what problems does it cause?

-- 
Captain Logic is not steering this tugboat.


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

Bug#343739: qt4-dev-tools: menu item for assistant

[Brian Nelson]

Petr Mensik <[EMAIL PROTECTED]> writes:

> Is there any reason why Qt Assistant does have any Menuitem in some
> debian Xserver menus? In KDE menu i didnt found any of Qt Designer, Qt
> Linguist, or Qt Assistant. That doest bother me much, as its under
> Debian subtree. Still i think it might be there, because who else will
> try using Qt language than KDE programmer? 

Plenty, I'd guess, including myself...

> But maybe against debian policies, dunno. But what i look for is
> Assistant menuitem somewhere.  Its simple program, but its helpful
> when you doing something with Qt.  But i did not found other way of
> starting assistant, than from commandline. I think some menuitem would
> not do something bad, so why would not add Qt Assistant to help
> section or applications/programming?  Not everyone know he has
> installed it when he cant find it in menu. Will it be there, or there
> are reasons why its not already there?

There is a menu entry for it, under Apps/Tools.  This might not be the
most logical place for it, but the Debian menu hierarchy is a total mess
anyway.  I don't think Apps/Programming is appropriate since you can't
actually use it for programming, unlike the other stuff that appears
under there.  I'm open to other suggestions though.

-- 
Captain Logic is not steering this tugboat.


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

Bug#343060: yes, need to rebuild

[Brian Nelson]

Peter Moulder <[EMAIL PROTECTED]> writes:

> To reproduce a crash with the existing aspell build (0.60.4-1_i386):
>
>   # apt-get install scim-pinyin
>   $ GTK_IM_MODULE=scim gedit
>
> On my machine at work, gedit crashes on startup, i.e. with just the above
> procedure.  On my home machine, the following addition is needed:
>
>   Press Ctrl+Space
>   A short bar should appear at the bottom of the screen;
>   select Chinese (simplified) > Smart Pinyin.
>   Type `w'.  Should crash at this point:
>   *** glibc detected *** free(): invalid pointer: 0x082d35d8 ***

The backtrace for that crash on my machine looks like:

(gdb) bt
#0  0xe410 in __kernel_vsyscall ()
#1  0x4a3ad691 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0x4a3aef5b in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0x4a3e3bb7 in __libc_message () from /lib/tls/i686/cmov/libc.so.6
#4  0x4a3ea187 in _int_free () from /lib/tls/i686/cmov/libc.so.6
#5  0x4a3ea622 in free () from /lib/tls/i686/cmov/libc.so.6
#6  0x410e8dc1 in operator delete () from /usr/lib/libstdc++.so.6
#7  0xb7a47dea in scim::CommonLookupTable::~CommonLookupTable ()
   from /usr/lib/libscim-1.0.so.8
#8  0xb7ad0b8f in scim::SocketInstance::do_transaction ()
   from /usr/lib/scim-1.0/1.4.0/IMEngine/socket.so
#9  0xb7ad4f56 in scim::SocketInstance::commit_transaction ()
   from /usr/lib/scim-1.0/1.4.0/IMEngine/socket.so
#10 0xb7ad5cff in scim::SocketInstance::process_key_event ()
   from /usr/lib/scim-1.0/1.4.0/IMEngine/socket.so
#11 0xb7aecfe3 in gtk_im_context_scim_new ()
   from /usr/lib/gtk-2.0/2.4.0/immodules/im-scim.so
#12 0x4abeb481 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#13 0x4add742a in _gdk_events_queue () from /usr/lib/libgdk-x11-2.0.so.0
#14 0x4a88f421 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#15 0x4a892687 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#16 0x4a892bd8 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#17 0x4abea629 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#18 0x080607c1 in main ()

I don't see how libaspell could be blamed...

-- 
Captain Logic is not steering this tugboat.


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

Bug#343190: libqt4-dev: qmake adding unneeded libraries to the linker command line

[Brian Nelson]

Benjamin Mesing <[EMAIL PROTECTED]> writes:

> to reduce dependencies between packages, it is suggested to add only
> neccessary libraries as linker arguments. Steve Langasek explained the
> problems in [1]. Now qmake pulls in loads of unneeded dependencies,
> including e.g. libfreetype (-lfreetype). 

Any idea of how to fix it?

-- 
Captain Logic is not steering this tugboat.


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

Bug#342658: libqt4-core: Locking Issue?

[Brian Nelson]

Ian Wienand <[EMAIL PROTECTED]> writes:

[...]
> (gdb) back
> #0  0x21363d81 in __pthread_sigsuspend (set=0x6fbf7270)
> at ../linuxthreads/sysdeps/unix/sysv/linux/ia64/pt-sigsuspend.c:32
> #1  0x21362380 in __pthread_wait_for_restart_signal 
> (self=0x2137edc8) at pthread.c:1216
> #2  0x2135d050 in __pthread_cond_wait (cond=0x60004338, 
> mutex=0x600042e0) at restart.h:34
> #3  0x2103f400 in QReadWriteLock::lockForWrite () from 
> /usr/lib/libQtCore.so.4
> #4  0x211d0340 in qt_addObject () from /usr/lib/libQtCore.so.4
> #5  0x211d0e50 in QObject::QObject () from /usr/lib/libQtCore.so.4
> #6  0x21184e20 in QFactoryLoader::QFactoryLoader () from 
> /usr/lib/libQtCore.so.4
> #7  0x2120b670 in QTextDecoder::~QTextDecoder () from 
> /usr/lib/libQtCore.so.4
> #8  0x21210ef0 in QTextCodec::codecForName () from 
> /usr/lib/libQtCore.so.4
> #9  0x2120c160 in QTextEncoder::fromUnicode () from 
> /usr/lib/libQtCore.so.4
> #10 0x2120efd0 in QTextCodec::codecForLocale () from 
> /usr/lib/libQtCore.so.4
> #11 0x210b30d0 in QString::toLocal8Bit () from /usr/lib/libQtCore.so.4
> #12 0x210e04b0 in locale_encode () from /usr/lib/libQtCore.so.4
> #13 0x210e06f0 in QFile::encodeName () from /usr/lib/libQtCore.so.4
> #14 0x210f8e20 in QFileEngineHandler::QFileEngineHandler () from 
> /usr/lib/libQtCore.so.4
> #15 0x210e5460 in QFile::open () from /usr/lib/libQtCore.so.4
> #16 0x40001070 in main ()
>
> It seems that lock in qt_addObject has already been taken by
> something.  Has anything changed in this area recently?

In the code?  No, not by me.  I don't see any reason why that lock would
be taken indefinitely anyway.

> BTW, using the libQtCore_debug.so.4 library didn't give me any useful
> line numbers or other debugging info.  If you load it into gdb and run
> 'info functions' all the symbols are defined as non-debugging symbols.
> This may have something to do with the way it was built.

That's bug #341807.

-- 
Captain Logic is not steering this tugboat.


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

Bug#343060: libaspell15: aspell has to be targetted for C++ ABI transition

[Brian Nelson]

# Lowering the severity since I don't see this bug
severity 343060 important
thanks

Akira TAGOH <[EMAIL PROTECTED]> writes:

> There is no rebuild of aspell package after the reversion of
> the mt allocator which was happened at 4.0.2-4. it causes
> the strange crash when the applications/libraries which was
> rebuilt against the newer libstdc++, uses libaspell15 which
> was built against the old libstdc++, but has the same
> soname. I'm not sure why they didn't change it and why the
> rebuild package list was missing aspell though, when I input
> something with scim on gaim, it crashes immediately, and
> rebuilding aspell got it fixed.

AIUI, there is no need for libaspell to be rebuilt for the mt allocator
transition.  That transition only affects certain C++ libraries, and
although libaspell is written in C++, it only exports a C interface.

Furthermore, I haven't had the problem you've described.  Are you sure
you've diagnosed the problem correctly?

-- 
Captain Logic is not steering this tugboat.


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

Bug#341658: libqt4-core: QBitArray operator{&,|,^}(...) missing from libQtCore.so

[Brian Nelson]

tag 341658 fixed-upstream
thanks

Torsten Marek <[EMAIL PROTECTED]> writes:

> The functions
>
> QBitArray operator&(const QBitArray &, const QBitArray &);
> QBitArray operator|(const QBitArray &, const QBitArray &);
> QBitArray operator^(const QBitArray &, const QBitArray &);
>
> are missing from libQtCore.so.

This is upstream bug scheduled to be fixed in 4.1.0:

  http://www.trolltech.com/developer/tasktracker.html?method=entry&id=83512

-- 
Captain Logic is not steering this tugboat.


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

Bug#340756: aspell-no: Incorrect arch, provides wrong aspell dictionary type

[Brian Nelson]

Package: aspell-no
Version: 2.0-22
Severity: serious

The aspell-no package should provide "aspell6a-dictionary", not
"aspell-dictionary".  The reason for this is that the
"aspell-dictionary" virtual package is reserved for dictionaries that
use the aspell-autobuildhash system and are thus independent of the
dictionary format.

This package, on the other hand, builds the hash at package build time
and includes it in the .deb.  The next time the aspell dictionary format
changes, this package will need to be rebuilt.  Aspell ensures the
installed dictionaries have the correct format by conflicting with
incompatible formats, and it relies on the provides relationship to do
this.

Also, since the dictionary hashes are affected by endianess, this
package should be Arch: any, not Arch: all.  Otherwise it won't work
properly on arches that have a different endianess from the system on
which you built it.

So, to be clear:

aspell-dictionary: uses aspell-autobuildhash, Arch: all, independent of
aspell version

aspell6a-dictionary: packages dictionary hash in the .deb, Arch: any,
depends on specific aspell versions due to dictionary format changes.


Note that packaging dictionaries using the aspell-autobuildhash system
is strongly preferred, but the quick fix for this package is to just
change the Arch: and Provides: control fields.


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

-- 
Captain Logic is not steering this tugboat.


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

Bug#340755: aspell-fi: Provides wrong aspell dictionary type

[Brian Nelson]

Package: aspell-fi
Version: 0.7-16
Severity: serious

The aspell-fi package should provide "aspell6a-dictionary", and not
"aspell-dictionary".  The reason for this is that the
"aspell-dictionary" virtual package is reserved for dictionaries that
use the aspell-autobuildhash system and are thus independent of the
dictionary format.

This package, on the other hand, builds the hash at package build time
and includes it in the .deb.  The next time the aspell dictionary format
changes, this package will need to be rebuilt.  Aspell ensures the
installed dictionaries have the correct format by conflicting with
incompatible formats, and it relies on the provides relationship to do
this.

So, to be clear:

aspell-dictionary: uses aspell-autobuildhash, Arch: all, independent of
aspell version

aspell6a-dictionary: packages dictionary hash in the .deb, Arch: any,
depends on specific aspell versions due to dictionary format changes.


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

-- 
Captain Logic is not steering this tugboat.


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

Bug#340754: aspell-he: Incorrect "contents" file created

[Brian Nelson]

Package: aspell-he
Version: 0.9+0-3
Severity: normal

In your debian/rules, there's a line:

echo he >> $(BASEDIR)/usr/share/aspell/he/.contents

that should instead be:

echo he >> $(BASEDIR)/usr/share/aspell/he.contents

This is probably my fault, since I think the original explanation I
wrote for creating auto-hash-building dictionaries contained the same
typo.

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


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

Bug#339357: libqt4-dev: a simple test

[Brian Nelson]

Artur Wiebe <[EMAIL PROTECTED]> writes:

> No, I could not find anything. I've just played around with this: A
> QTreeWidget with setContextMenuPolicy(Qt::CustomContextMenu) and the signal
> customContextMenuRequested(const QPoint&) connected to a my_slot(const
> QPoint&) which looks like
>
> void myView::my_slot(const QPoint& pos)
> {
> QMenu popup(this);
>
> popup.addAction("test 1");
> popup.addAction("test 2");
> popup.addAction("test 3");
>
> //QAction* retval = popup.exec(m_tw->mapToGlobal(pos));
> QAction* retval = popup.exec(QCursor::pos());
> qDebug() << retval;
> }
>
> This works. The commented out version does not. It opens a popup but
> clicking left outside the menu returns not 0.

Well, I just looked over the QMenu code to try to see what could be
happening here, but nothing obvious stood out.

Would you like to file a bug upstream and see if the trolls can figure
it out?

-- 
Captain Logic is not steering this tugboat.


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

Bug#327359: qmake generates invalid -L linker Option

[Brian Nelson]

tag 327359 upstream
thanks

This actual bug is filed as
http://www.trolltech.com/developer/tasktracker.html?method=entry&id=87775
upstream, scheduled to be fixed in 4.1.1.

-- 
Captain Logic is not steering this tugboat.


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

Bug#337764: libqt4-debug: Building apps in debug mode breaks image loading

[Brian Nelson]

tag 337764 confirmed
thanks

Andreas Pakulat <[EMAIL PROTECTED]> writes:

> On 18.11.05 10:20:54, Brian Nelson wrote:
>> Andreas Pakulat <[EMAIL PROTECTED]> writes:
>> 
>> > Building QT4 apps using
>> >
>> > CONFIG += debug
>> >
>> > breaks the loading of any icons in the application. Remove debug and
>> > everythings fine. This not only happens to the icons created for that
>> > app, but also for the icons in standard dialog, like the QFileDialog.
>> 
>> Hmm, I can't reproduce this.  Can you test some of the examples from Qt
>> and see if you can reproduce it with any of those.  The stuff under
>> mainwindows/ seem like good candidates.
>
> Sure, just take the "application" example, add
>
> CONFIG += debug
>
> and run qmake-qt4 && make. The program won't display any icon, except the
> one for paste. This is with an up to date sid and I'm having Qt3 as
> default Qt (i.e. qmake == qmake-qt3).
>
> QTDIR is set to point to /usr/share/qt3, but changing to /usr/share/qt4
> doesn't help either.

OK, I see it now.  Strange I couldn't reproduce it the first time I
tried.

I wonder if this is a consequence of this bug:
http://www.trolltech.com/developer/tasktracker.html?method=entry&id=86441

Examining the strace, it does look like it's loading both the debug and
non-debug versions of the plugins.

-- 
Captain Logic is not steering this tugboat.


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

Bug#337764: libqt4-debug: Building apps in debug mode breaks image loading

[Brian Nelson]

Andreas Pakulat <[EMAIL PROTECTED]> writes:

> Building QT4 apps using
>
> CONFIG += debug
>
> breaks the loading of any icons in the application. Remove debug and
> everythings fine. This not only happens to the icons created for that
> app, but also for the icons in standard dialog, like the QFileDialog.

Hmm, I can't reproduce this.  Can you test some of the examples from Qt
and see if you can reproduce it with any of those.  The stuff under
mainwindows/ seem like good candidates.

You can find the examples in the Qt source, or in the new qt4-doc
package I'm about to upload (4.0.1-5).

-- 
Captain Logic is not steering this tugboat.


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

Bug#339357: libqt4-dev: QMenu::exec() returns wrong value

[Brian Nelson]

Artur Wiebe <[EMAIL PROTECTED]> writes:

> When opening a popup menu with QMenu::exec() and clicking left outside
> of the menu exec() returns not 0 as I would expect it. If this is not a
> bug, sry for wasting your time.

It does sound like a bug.  Did you search the bug reports on
http://www.trolltech.com/developer/tasktracker.html for anything
relevant?  I just looked but couldn't find anything.

-- 
Captain Logic is not steering this tugboat.


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

Bug#338976: pbuilder: pdebuild dies if /etc/shadow doesn't exist

[Brian Nelson]

Package: pbuilder
Version: 0.138
Severity: normal

For whatever reason, /etc/shadow doesn't exist in my chroot, and so when
I run pdebuild, it dies:

[...]
+ save_aptcache
+ local doit
+ '[' -n '' ']'
+ trap umountproc_cleanbuildplace exit
+ createbuilduser
+ '[' -n 'su -p root' ']'
+ grep -q '^root:' /home/nelson/pbuilder/build//10521/etc/passwd
+ grep -q '^root:' /home/nelson/pbuilder/build//10521/etc/group
+ grep -q '^root:' /home/nelson/pbuilder/build//10521/etc/shadow
grep: /home/nelson/pbuilder/build//10521/etc/shadow: No such file or directory
+ cowprotect /home/nelson/pbuilder/build//10521/etc/shadow
+ for A in '"$@"'
+ readlink -f /home/nelson/pbuilder/build//10521/etc/shadow
/home/nelson/pbuilder/build/10521/etc/shadow
++ readlink -f /home/nelson/pbuilder/build//10521/etc/shadow
+ A=/home/nelson/pbuilder/build/10521/etc/shadow
+ mv /home/nelson/pbuilder/build/10521/etc/shadow /home/nelson/pbuilder/build/10
521/etc/shadow~
mv: cannot stat `/home/nelson/pbuilder/build/10521/etc/shadow': No such file or
directory
+ umountproc_cleanbuildplace
+ '[' 1 -ne 0 ']'
+ echo ' -> Aborting with an error'
 -> Aborting with an error
[...]


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

Versions of packages pbuilder depends on:
ii  cdebootstrap  0.3.9  Bootstrap a Debian system
ii  coreutils 5.93-2 The GNU core utilities
ii  debianutils   2.15.1 Miscellaneous utilities specific t
ii  gcc   4:4.0.2-1  The GNU C compiler
ii  wget  1.10.2-1   retrieves files from the web

Versions of packages pbuilder recommends:
ii  devscripts2.9.8  Scripts to make the life of a Debi
ii  fakeroot  1.5.5  Gives a fake root environment
ii  sudo  1.6.8p9-3  Provide limited super user privile

-- no debconf information


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