Bug#319586: wrong dependency on xlibs-pic

[Jose Antonio]

Package: libqt4-dev
Version: 4.0.0-2
Severity: minor

xlibs-pic is a transitional package. Please, correct the dependencies to reflect
the new name of the Xlibs package, xlibs-static-pic. Severity set to minor
because the transitional package solves the problem; maybe should be raised.

On the other hand, thank you por these packages.

Jose Antonio

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL 
PROTECTED])

Versions of packages libqt4-dev depends on:
ii  libaudio-dev  1.7-2  The Network Audio System (NAS). (d
ii  libc6-dev 2.3.2.ds1-22   GNU C Library: Development Librari
ii  libfreetype6-dev  2.1.10-1   FreeType 2 font engine, developmen
ii  libglu1-xorg-dev [libglu- 6.8.2.dfsg.1-3 Mesa OpenGL utility library develo
ii  libjpeg62-dev 6b-10  Development files for the IJG JPEG
ii  libmng-dev1.0.8-1M-N-G library (Development headers
ii  libpng12-dev [libpng12-0- 1.2.8rel-1 PNG library - development
ii  libqt4-core   4.0.0-2Qt 4 core non-GUI functionality ru
ii  libxcursor-dev1.1.3-1X cursor management library (devel
ii  libxft-dev2.1.7-1FreeType-based font drawing librar
ii  libxinerama-dev   6.8.2.dfsg.1-3 X Window System multi-head display
ii  libxrender-dev1:0.9.0-2  X Rendering Extension client libra
ii  xlibmesa-gl-dev [libgl-de 6.8.2.dfsg.1-3 Mesa 3D graphics library developme
ii  xlibs-dev 6.8.2.dfsg.1-3 X Window System client library dev
ii  xlibs-pic 6.8.2.dfsg.1-3 X.Org static PIC libraries transit
ii  zlib1g-dev1:1.2.3-1  compression library - development

Versions of packages libqt4-dev recommends:
ii  libqt4-gui4.0.0-2Qt 4 core GUI functionality runtim
pn  qt4-dev-tools  (no description available)

-- no debconf information


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

CAN-2005-1920: information leak in kate / kwrite

[Martin Schulze]

Hi,

did you notice ?

I'm building an update for sarge now.  Can you tell me which version
of the package will have the fix included in sid?

Regards,

Joey

-- 
Long noun chains don't automatically imply security.  -- Bruce Schneier

Please always Cc to me when replying to me on the lists.


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

Re: CAN-2005-1920: information leak in kate / kwrite

[Adeodato Simó]

* Martin Schulze [Sat, 23 Jul 2005 18:17:48 +0200]:

> Hi,

  Hi Martin,

> did you notice ?

  Yes.

> I'm building an update for sarge now.  Can you tell me which version
> of the package will have the fix included in sid?

  No, we really can't tell. The upload that will fix this is quite far
  away, because it depends on several other libraries (Qt, aRts, kdelibs)
  doing its C++ ABI transition first. With this timespan, it'd be hard
  to predict the version number (we still don't know whether it'll be
  KDE 3.4.1 or 3.4.2, go figure).

  If you want to mention something about sid in the advisory, perhaps
  you could go with something similar to "This issue has been fixed in
  kate 3.4.1-1, available from experimental. Packages based on this
  version will be uploaded to unstable as soon as the necessary
  libraries have made their C++ ABI transition."

  Thanks for your interest,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
Algebraic symbols are used when you do not know what you are talking about.
-- Philippe Schnoebelen


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

Processed: merging 318017 319154

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.8.14
> merge 318017 319154
Bug#318017: kdelibs4-dev: gcc4 issues causes build failures
Bug#319154: kile: ftbfs [sparc] error: ISO C++ forbids declaration of 
'KXMLGUIClient' with no type
Merged 318017 319154.

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Processed: tagging 319586

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.9.2
> tags 319586 pending
Bug#319586: wrong dependency on xlibs-pic
There were no tags set.
Tags added: pending

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: Bug#319016: Information leak through insufficient permissions on backup files in kate (CAN-2005-1920)

[Adeodato Simó]

* Moritz Muehlenhoff [Tue, 19 Jul 2005 11:13:44 +0200]:

> Package: kate
> Severity: important
> Tags: security

> Kate creates backup files with default permissions, which may cause
> sensitive information to be visible to other users on the system.
> Please see http://www.kde.org/info/security/advisory-20050718-1.txt
> for full details.

> stable, testing and sid are affected, oldstable is not.
> It's been fixed in the 3.4.1 packages in experimental.

  I've marked this bug as closed as of 4:3.4.1-1 (currently in
  experimental, as you say). For sid, we plan no other action for fixing
  than wait till all the necessary libraries have made their C++ ABI
  transition (Qt, aRts, kdelibs4) and then upload KDE 3.4.1 to unstable
  as planned.

  As for testing, I don't know if the testing-security distribution is
  meant to be operating so early in the release cycle, but if it is,
  this could be a great opportunity to check if it really works, given
  that getting the fix through unstable will mean a significant delay.
  Not that the vulnerability is critical, though.

  Cheers,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
Testing can show the presence of bugs, but not their absence.
-- Dijkstra


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

Processed: Re: Bug#319456: man dangling symlinks

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> tag 319456 confirmed
Bug#319456: man dangling symlinks
There were no tags set.
Tags added: confirmed

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Bug#319456: man dangling symlinks

[Brian Nelson]

tag 319456 confirmed
thanks

On Fri, Jul 22, 2005 at 10:32:17AM +0200, Jose Antonio wrote:
> from /etc/cron.daily/man-db:
> mandb: warning: /usr/share/man/man1/moc.1.gz is a dangling symlink
> mandb: warning: /usr/share/man/man1/uic.1.gz is a dangling symlink
> mandb: warning: /usr/share/man/man1/qtconfig.1.gz is a dangling symlink
> mandb: warning: /usr/share/man/man1/qmake.1.gz is a dangling symlink
> mandb: warning: /usr/share/man/man1/lupdate.1.gz is a dangling symlink
> mandb: warning: /usr/share/man/man1/lrelease.1.gz is a dangling symlink
> 
> maybe related to #318765 (update-alternatives bug)
 
Nope, that's my fault--they're dangling because there aren't any real
manpages to point to.  I've been meaning to add those manpages but
haven't gotten around to it yet...

-- 
Society is never going to make any progress until we all learn to
pretend to like each other.


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

Processed: tagging 319456

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.9.2
> tags 319456 pending
Bug#319456: man dangling symlinks
Tags were: confirmed
Tags added: pending

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Bug#319154: kdelibs' ftbfs: simple fix

[David Schmitt]

Hello *!


Including  in kdeui/kactioncollection.h fixes this ftbfs, 
though I have not yet tried whether the new packages work and the build 
sports quite a few warnings.


Regards, David
-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Bug#319679: kdelibs4 broken dependency

[Beto]

Package: kdelibs4
Version: 4:3.3.2-7

It's impossible to install KDE. I have installed Debian Sid (Sarge
netinstall and then upgraded to Sid) today and if I try to install
KDE, it cannot, so I finally got the problem:
'apt-get install kdelibs4' says it depends on libaspell15, but it's
not installable, so I tried  'apt-get install libaspell15' and it says
that this package is replaced by libaspell15c2 (this one CAN be
installed), but not libaspell15, soy kdelibs4 won't install and I
can't use KDE.

Sorry if you find mistakes on my text, I'm spanish.

-- 
Betorr

Re: Keyboard lockup after X startup; possible cause

[Enrico Zini]

On Sat, Jul 23, 2005 at 01:50:10AM +0400, Nikita V. Youshchenko wrote:

I had the same bug.  It used to happen when you changed inittab to use
more than 6 VCs, I had no idea it could race even on lower VCs.

> I don't know which is the correct way to fix it.
> Possible ways:
> 
> *) ensure that X is never started on vt on which getty is going to be 
> started - in this case, having default Xservers files to set explicit vtN 
> is enough, and kdm 3.4 should provide some way to ensure that it will not 
> choose vt on which getty will be started later,

Defining the vtN explicitly makes sense, especially as we seem to have
standardised on having X running on vc7.  People who change inittab to
allocate vc7 for something else, should also change the display manager.
A comment in the default inittab reminding of the issue could also help.

> *) debian should not treat *dm like other services, and start it after 
> getty's, not before them

I recommend against this one, as there's been quite some talking about
invoking *dm earlier in the boot process, to speed up getting to the
working environment.

> *) some other way?

What would be required for getty and X to allocate the vc without
messing each other up?  The cleaner solution (to me) would be to have
getty not run if X is using the vc, or X running on another vc if getty
is using it; but I reckon it might not be technically possible, at least
judging from the past discussions on bug#116747, bug#47451 and bug#165241,


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature