catch current XkbLayout

[gustavo halperin]

Hello



I'm using  "Enlightenment Window Manager"  without KDE  and without Gnome. My XFree86 is 
configured with three keyboard layouts:


Option 
"XkbLayout" "es,il,us"


Option 
"XkbOptions"    "grp:shift_toggle"

My question is : when ever the keyboard Layout changes, how can I catch
that such a change occurred and how can I catch the layout type. 
This in order
to write an applet that will display a different layout for every language


Thank you in advance



Gustavo Halperin

Re: catch current XkbLayout

[Chris Vanden Berghe]

Hey,

Google for XKBlib.pdf.  This document explains how to register for
keyboard related events.

Cheers,
Chris.

---
gustavo halperin wrote:
> Hello
> 
> I'm using  "Enlightenment Window Manager"  without KDE  and without
> Gnome. My XFree86 is configured with three keyboard layouts:
>  Option  "XkbLayout" "es,il,us"
>  Option  "XkbOptions""grp:shift_toggle"
> My question is : when ever the keyboard Layout changes, how can I catch
> that such a change occurred and how can I catch the layout type.
> This in order to write an applet that will display a different layout
> for every language
> 
> Thank you in advance
> 
> Gustavo Halperin


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

Re: catch current XkbLayout

[gustavo halperin]

Really Thanks, I don't know how I miss it.

  Thanks again

  GustavoOn 10/11/05, Chris Vanden Berghe <[EMAIL PROTECTED]> wrote:
Hey,Google for XKBlib.pdf.  This document explains how to register forkeyboard related events.Cheers,Chris.---gustavo halperin wrote:> Hello>> I'm using  "Enlightenment Window Manager"  without KDE  and without
> Gnome. My XFree86 is configured with three keyboard layouts:>  Option  "XkbLayout"
"es,il,us">  Option  "XkbOptions""grp:shift_toggle"> My question is : when ever the keyboard Layout changes, how can I catch> that such a change occurred and how can I catch the layout type.
> This in order to write an applet that will display a different layout> for every language>> Thank you in advance>> Gustavo Halperin

Re: Update on GNOME 2.10 schedule

[Miles Bader]

Adam C Powell IV <[EMAIL PROTECTED]> writes:
>> Use MozPlugger for that, like explained here:
>> http://ubuntuforums.org/showthread.php?t=25685
>
> Terrific!  Thanks very much.

Mozplugger even works with xpdf (which I far prefer to the gnome
viewers).

I was stunned (and thrilled) when all had to do was install mozplugger
and embedding just started _working_...

-miles
-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson


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

Bug#333282: ITP: tcpxtract -- extracts files from network traffic based on file signatures

[Nico Golde]

Package: wnpp
Severity: wishlist
Owner: Nico Golde <[EMAIL PROTECTED]>

* Package name: tcpxtract
  Version : 1.0
  Upstream Author : Nicholas Harbour <[EMAIL PROTECTED]>
* URL : http://tcpxtract.sourceforge.net/
* License : GPL
  Description : extracts files from network traffic based on file signatures

Tcpxtract can caputer files from tcp based network streams.
It can be greatly combined with network sniffers like
tcpdump.
The features are:
o Supports 25 popular file formats out-of-the-box. New formats can be added by
  simply editing its config file.
o With a quick conversion, you can use your old Foremost config file with 
tcpxtract.
o Custom written search algorithm is lightning fast and very scalable.
o Search algorithm searches across packet boundries for total coverage and
  forensic quality.
o Uses libpcap, a popular, portable and stable library for network data capture.
o Can be used against a live network or a tcpdump formatted capture file.

-- 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.13
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: 
LC_ALL set to [EMAIL PROTECTED])

-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
$ route add default roma.it


signature.asc
Description: Digital signature

Debian Installer build problem

[João Silva]

Hi, recently i'm trying to rebuild de debian installer. The current built i'm working is 20050317.
First when a i try to build the original package, it gives-me an error that doesn't have
the slang1-utf8-pic. I install this library and it enters in confilcts with the libnewt-pic that is also in the control file.
Well, i resolved this, delecting the libnewt-pic from the control file.
Second:
when i'm building the package, it gives me almost in the end the following error:

536 symbols, 22 unresolved
Traceback (most recent call last):
  File "/usr/bin/mklibs", line 438, in ?
    raise "Unresolvable symbol " + symbol
Unresolvable symbol SLutf8_enable
make[7]: *** [stamps/tree-cdrom_el-torito-stamp] Error 1
make[6]: *** [_build] Error 2
make[5]: *** [flavour_build] Error 2
make[4]: *** [medium_build] Error 2
make[3]: *** [subarch_build] Error 2
make[2]: *** [all_build] Error 2
make[2]: Leaving directory `/mnt/mirror/source/debian-installer/debian-installer-20050317/build'
make[1]: *** [build-images] Error 2
make[1]: Leaving directory `/mnt/mirror/source/debian-installer/debian-installer-20050317'
make: *** [install] Error 2

So, anybody can helpme in this?

Thanks.
-- Cumprimentos,João Carlos Galaio da Silva

Re: applet showing the current XkbLayout

[Philipp Matthias Hahn]

Hello!

On Thu, Oct 06, 2005 at 04:00:41PM +0300, gustavo halperin wrote:
> I'm using enlightenment without KDE and without Gnome. My XFree86 is
> configured with three keyboard layout:
> Option "XkbLayout" "es,il,us"
> Option "XkbOptions" "grp:shift_toggle"
> My question is how I can cache when ever the keyboard Layout change and
> which one is the current, this in order
> to write an applet for enlightenment and X showing an ensign of the current
> country Layout.

Take a look at "xkbwatch", available for example from
http://www.x.org/pub/unsupported/test/Xkb/programs/xkbwatch.c:

$ gcc -L /usr/X11R6/lib -lX11 xkbwatch.c
$ ./a.out
Watching the keyboard state...
--- group   --- modifiers -
id key   event  eff  base  latch  lock   eff  base  latch  lock  compat
 1  50down0 0  0 0  0x01* 0x01*  0x00  0x000x01*
 1  62down1*0  0 1* 0x01  0x01   0x00  0x000x81*
 1  50  up1 0  0 1  0x00* 0x00*  0x00  0x000x80*
 1  50down1 0  0 1  0x01* 0x01*  0x00  0x000x81*
 1  62down2*0  0 2* 0x01  0x01   0x00  0x000x81
 1  50  up2 0  0 2  0x00* 0x00*  0x00  0x000x80*
 1  50down2 0  0 2  0x01* 0x01*  0x00  0x000x81*
 1  62down0*0  0 0* 0x01  0x01   0x00  0x000x01*
 1  50  up0 0  0 0  0x00* 0x00*  0x00  0x000x00*

BYtE
Philipp
-- 
Philipp Matthias Hahn <[EMAIL PROTECTED]>
 GPG/PGP: 9A540E39 @ keyrings.debian.org


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

using symbols generated by dh_strip --dbg-package= (was Re: Bug#333253: libcurl3-dbg: segfault when using export LD_PRELOAD=/usr/lib/debug/...)

[Domenico Andreoli]

On Tue, Oct 11, 2005 at 08:17:41AM +0200, Tino Keitel wrote:
> 
> Hi,

hi Tino,

> I want to debug a program which uses curl, so I did this:
> 
> export LD_PRELOAD=/usr/lib/debug/usr/lib/libcurl.so.3.0.0
> 
> However, everytime I start any program now, I get a segfault.
> 
> Is this a bug, or is it my fault?

i really don't know. i'm pretty sure the file contains only debug
symbols so maybe another procedure is required in order to use them.

i'm CCing debian-devel mailing list to get some feedback about this
issue.

regards
domenico

-[ Domenico Andreoli, aka cavok
 --[ http://people.debian.org/~cavok/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50


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

Re: using symbols generated by dh_strip --dbg-package= (was Re: Bug#333253: libcurl3-dbg: segfault when using export LD_PRELOAD=/usr/lib/debug/...)

[martin f krafft]

also sprach Domenico Andreoli <[EMAIL PROTECTED]> [2005.10.11.1152 +0200]:
> > export LD_PRELOAD=/usr/lib/debug/usr/lib/libcurl.so.3.0.0

No.

> i really don't know. i'm pretty sure the file contains only debug
> symbols so maybe another procedure is required in order to use them.

gdb can load them, and should do so automatically.

http://developer.apple.com/documentation/DeveloperTools/gdb/gdb/gdb_16.html#SEC137

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"everyone smiles as you drift past the flower
 that grows so incredibly high."
-- the beatles


signature.asc
Description: Digital signature (GPG/PGP)

Re: Automatically sending test suite results from buildds to upstream

[Jeroen van Wolffelaar]

On Tue, Oct 11, 2005 at 08:32:51AM +0200, Jeroen Massar wrote:
> On Tue, 2005-10-11 at 02:13 +0200, Florian Ragwitz wrote:
> > On Mon, Oct 10, 2005 at 08:07:52PM -0400, Daniel Jacobowitz wrote:
> 
> > > or to include test results in the .deb files and retrieve them after
> > > the build.  That latter is what the GCC packages do.
> > 
> > I don't like that solution. Users of the package don't care about the
> > test results so it's useless to bloat the packages with them.
> 
> Stick the debug files into a seperate -debug package, which nobody will
> install anyway and just consumes some archive space.

Packages that nobody will install should not be in the Debian archive. -debug
packages only make really sense for a small number of the most high-profile
packages.

In this case, the extract results from buildd.d.o way is the way to go IMHO.
It can be automated too if really needed if you make sure to output specific
markers before & after the tests run.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


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

Re: Bug#332858: ITP: cvsup -- The CVS-Optimized General-Purpose Network File Distribution System

[George Danchev]

On Monday 10 October 2005 16:45, Javier Fernández-Sanguino Peña wrote:
--cut--
> > CVSync [1] is a possible alternative to CVSup, not compatible with it,
> > but written in plain C.
>
> That one looks interesting, I did not find it when I was googling for
> alternatives to CVSup. I would love to see something like this packaged so

Someone should at least hint wnpp then ;-)

> that we could distribute copies of our CVS worlwide and not have issues if
> we have any issues with the servers holding our CVS in the future.

I find rsync being enough for mirroring CVS repos. Yes, I'm familiar with 
CVSup usage of the rsync algorythm for some files and some special algorythms 
tailored for rcs files, but I don't think that could be a showstopped for 
mirroring CVS repos with rsync only.

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


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

Re: apt-get wants to remove hotplug?

[Julien BLACHE]

Jason Clinton <[EMAIL PROTECTED]> wrote:

> Also note that libgphoto2-2 (upon which much of the desktop metapackages 
> depend) will conflict with the new udev-0.070-3 until a NMU can be processed 
> as the maintainer is on vacation.

 libgphoto2 2.1.6-5.1

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


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

Bug#333309: ITP: libuniversal-require-perl -- require modules from a variable

[Stephen Quinney]

Package: wnpp
Severity: wishlist
Owner: Stephen Quinney <[EMAIL PROTECTED]>


* Package name: libuniversal-require-perl
  Version : 0.10
  Upstream Author : Michael G Schwern <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~mschwern/UNIVERSAL-require-0.10/
* License : GPL (>= 1) or Perl Artistic
  Description : require modules from a variable

 If you've ever had to do this...
 .
eval "require $module";
 .
 to get around the bareword caveats on require(), this module is for
 you. It creates a universal require() class method that will work
 with every Perl module and its secure. So instead of doing some
 arcane eval() work, you can do this:
 .
$module->require;
 .
 It doesn't save you much typing, but it'll make alot more sense to
 someone who's not a ninth level Perl acolyte.
 .
 Also provided is a use() method which works in a similar way.

NOTE


This used to be provided as part of the libuniversal-exports-perl
package but upstream has now decided to split it out. Most people were
installing libuniversal-exports-perl just to get at the functionality
of libuniversal-require-perl.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11.10
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Bug#333331: ITP: khmer-to-unicode -- converts legacy Khmer encodings to Unicode

[Paul Wise]

Package: wnpp
Severity: wishlist
Owner: Paul Wise <[EMAIL PROTECTED]>

* Package name: khmer-to-unicode
  Version : 1.8a
  Upstream Author : Javier Solá <[EMAIL PROTECTED]>
* URL : http://www.khmeros.info/drupal/?q=en/download/others
* License : LGPL
  Description : converts legacy Khmer encodings to Unicode

These programs take a plain text file encoded in either of the ABC or
Limon Khmer legacy fonts and creates a file that is the equivalent in
Khmer Unicode (UTF-8).

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Debian Installer build problem

[Daniel Ruoso]

Em Ter, 2005-10-11 às 10:36 +0100, João Silva escreveu:
> Hi, recently i'm trying to rebuild de debian installer. The current
> built i'm working is 20050317.
> First when a i try to build the original package, it gives-me an error
> that doesn't have
> the slang1-utf8-pic. I install this library and it enters in confilcts
> with the libnewt-pic that is also in the control file.

That means a problem. Looking at packages.debian.org I can't see the
conflict you mentioned. Are you sure that libnewt-pic is conflicting
with slang1-utf8-pic?

> Well, i resolved this, delecting the libnewt-pic from the control
> file.

You created another problem...

> Second:
> when i'm building the package, it gives me almost in the end the
> following error:
> 536 symbols, 22 unresolved
> Traceback (most recent call last):
>   File "/usr/bin/mklibs", line 438, in ?
> raise "Unresolvable symbol " + symbol
> Unresolvable symbol SLutf8_enable

Well, that's why it was on the build-dependencies...

daniel


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

Re: apt-get wants to remove hotplug?

[Francesco P. Lovergine]

On Mon, Oct 10, 2005 at 10:26:56PM +0200, Marco d'Itri wrote:
> On Oct 10, Francesco Paolo Lovergine <[EMAIL PROTECTED]> wrote:
> 
> > Mousedev, evdev and usbmouse here, to have a working setup for X with
> usbmouse is blacklisted, so it's not supposed to be loaded.
> The driver for USB mice is usbhid.
> 

It is (was?) not loaded anyway, keeping off my usb logitech mouse.

-- 
Francesco P. Lovergine


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

Re: Debian Installer build problem

[João Silva]

Yes, sure i'm know that this problem is because i had removed
the lib. But sure when i try to install libnewt-pic, it removes the slang-utf8-pic.
On 10/11/05, Daniel Ruoso <[EMAIL PROTECTED]> wrote:
Em Ter, 2005-10-11 às 10:36 +0100, João Silva escreveu:> Hi, recently i'm trying to rebuild de debian installer. The current> built i'm working is 20050317.> First when a i try to build the original package, it gives-me an error
> that doesn't have> the slang1-utf8-pic. I install this library and it enters in confilcts> with the libnewt-pic that is also in the control file.That means a problem. Looking at 
packages.debian.org I can't see theconflict you mentioned. Are you sure that libnewt-pic is conflictingwith slang1-utf8-pic?> Well, i resolved this, delecting the libnewt-pic from the control> file.
You created another problem...> Second:> when i'm building the package, it gives me almost in the end the> following error:> 536 symbols, 22 unresolved> Traceback (most recent call last):
>   File "/usr/bin/mklibs", line 438, in ?> raise "Unresolvable symbol " + symbol> Unresolvable symbol SLutf8_enableWell, that's why it was on the build-dependencies...
daniel-- Cumprimentos,João Carlos Galaio da Silva

Re: Debian Installer build problem

[Colin Watson]

On Tue, Oct 11, 2005 at 10:36:27AM +0100, João Silva wrote:
> Hi, recently i'm trying to rebuild de debian installer. The current built
> i'm working is 20050317.
> First when a i try to build the original package, it gives-me an error that
> doesn't have
> the slang1-utf8-pic.

You *must* do either one of the following:

  * Build the sarge version of debian-installer against the sarge
archive. For the moment, this involves setting 'SUITE ?= sarge' in
build/config/common; if there is ever another upload of
debian-installer to sarge, we'll fix this.

  * Build the SVN trunk of debian-installer (or the version in unstable)
against the unstable archive.

You *cannot* build the sarge version of debian-installer against the
unstable archive; it sounds as if that's what you're trying to do.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: Debian Installer build problem

[Otavio Salvador]

João Silva <[EMAIL PROTECTED]> writes:

> Yes, sure i'm know that this problem is because i had removed
> the lib. But sure when i try to install libnewt-pic, it removes the 
> slang-utf8-pic.

Which version of  installer you're trying to build?

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."

Bug#333349: openssl: Must either version symbols or conflict with ALL libraries linked to previous version

[Henrique de Moraes Holschuh]

Package: openssl
Version: 0.9.8-2
Severity: critical
Justification: breaks unrelated software

OpenSSL does not version symbols.  This means all applications that somehow
end up linked to both openssl 0.9.7 and 0.9.8 segfault or behave otherwise
erratically (which would be a critical bug by itself, as openssl is a
data privacy/authentication framework with severe consequences for overall
system security).

Therefore, ANY new ABI-introducing version of openssl has to conflict with
ALL **libraries** (not applications) that are linked against other openssl
versions.  Not doing so is just hiding the mess for the users to find out as
segfaults.  Transitions like this should be enforced by package
dependencies, always.

The whole deal is made even worse because some of the libraries linking to
openssl are used by PAM modules and/or nssswitch modules, and thus
dlopen()ed by a lot/potentially all applications in the system.

The conflicts are quite messy, but unless either symbol versioning or
another technique that avoids the symbol mess while linked is employed (weak
symbols might do it, I think -- but symbol versioning is much easier to
predict and understand), it is what must be done.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13.4-debian1+libata+bluesmoke+imq+lm85
Locale: LANG=pt_BR.ISO-8859-1, LC_CTYPE=pt_BR.ISO-8859-1 (charmap=ISO-8859-1)

Versions of packages openssl depends on:
ii  libc6 2.3.5-6GNU C Library: Shared libraries an
ii  libssl0.9.8   0.9.8-2SSL shared libraries

openssl recommends no packages.

-- no debconf information

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

RFC: GTK+ icon cache

[Josselin Mouette]

Hi list,

there is an ongoing disagreement in the GNOME team about the handling of
icon caches, and we (or at least, I) would appreciate more input. Let me
try to sum it up.

1. The issue
Desktop environment and applications are using more and more icons, for
many reasons. They are put in /usr/share/icons/$theme/$size/$purpose/
directories. This way, an application looking for an icon will have to
look through the whole directory structure of /usr/share/icons/$theme
for the current theme and all themes it inherits from. This is very
slow.

2. The cure
A mmap()-able cache file format was proposed, and is generated by
gtk-update-icon-cache in /usr/share/icons/$theme/icon-theme.cache files.
It helps a lot to improve speed.

3. The side-effect (for an euphemism)
The current code in GTK+ follows the freedesktop.org specification: if
the mtime of /usr/share/icons/$theme/ is more recent than that of
icon-theme.cache, the cache is considered outdated, and the whole
directory structure is read instead. As a result, if an application
installs a new icon, of course the mtime of a directory two levels up
isn't changed. When started, the application doesn't find the icon. Some
applications only become ugly, some simply refuse to launch.

4. The current state of affairs
In sarge - and this is still the case in unstable - the icon cache is
generated for most themes, but not for "gnome" and "hicolor", which are
the default directories applications install icons in. That means some
themes in gnome-themes-extras (which don't inherit from gnome) benefit
from the icon cache, but other themes (especially the default) don't.

5. The proposed solution
The Redhat people, who implemented the cache specification, obviously
don't have problems with applications suddenly becoming unusable after
some change: they started to generate cache for all directories,
automatically adding post-installation snippets to the application
packages. As "this worked", and as the GTK+ developers - which happen to
be partly the same people - don't want to change the code, their
recommendation is to do the same for Debian. Applying this solution
means that, as soon as some packages start using the new debhelper
snippet, hundreds of other packages will more or less break when
installed after the cache generation.

In short, some people in the GNOME team want to apply this solution
nevertheless, while other people (including me) don't want of it.
Alternative proposed solutions are to keep things as they are in sarge,
or to change the code to check for the mtime's of all subdirectories
(which of course would be slower). I'm not searching for support here,
but for a decision. If a consensus about applying it arises, I'll apply
it - I even already started to write the debhelper script.

Regards,
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom


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

Re: RFC: GTK+ icon cache

[sean finney]

On Tue, Oct 11, 2005 at 03:51:15PM +0200, Josselin Mouette wrote:
> 2. The cure
> A mmap()-able cache file format was proposed, and is generated by
> gtk-update-icon-cache in /usr/share/icons/$theme/icon-theme.cache files.
> It helps a lot to improve speed.

without saying more on this issue (i don't know enough to care
one way or another, i guess), keep in mind that the location
/usr/share/icons/$theme/icon-theme.cache is not policy
compliant, and that it should instead be something like
/var/cache/$foo/$theme/icon-theme.cache.


sean


signature.asc
Description: Digital signature

Re: Bug#333120: ITP: icu4j -- International Components for Unicode for Java

[Arnaud Vandyck]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Seo Sanghyeon wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Seo Sanghyeon <[EMAIL PROTECTED]>
> 
> * Package name: icu4j
>   Version : 3.4
>   Upstream Author : IBM
> * URL : http://icu.sourceforge.net/
> * License : MIT/X
>   Description : International Components for Unicode for Java

It's a Java package, wouldn' you consider maintaining it under the
umbrella of the pkg-java Alioth's project?

http://pkg-java.alioth.debian.org/

You are welcome to join us.

- --
  .''`.
 : :' :rnaud
 `. `'
   `-
Java Trap: http://www.gnu.org/philosophy/java-trap.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDS8jZ4vzFZu62tMIRAlEWAJ0cVGI8NEji06zhjW51tTBKh5+8TQCgjLHV
Lri2LKEbXVaAALaCm8kg/Mc=
=n21T
-END PGP SIGNATURE-


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

Re: Bug#333120: ITP: icu4j -- International Components for Unicode for Java

[Michael Koch]

On Tue, Oct 11, 2005 at 04:14:49PM +0200, Arnaud Vandyck wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Seo Sanghyeon wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Seo Sanghyeon <[EMAIL PROTECTED]>
> > 
> > * Package name: icu4j
> >   Version : 3.4
> >   Upstream Author : IBM
> > * URL : http://icu.sourceforge.net/
> > * License : MIT/X
> >   Description : International Components for Unicode for Java
> 
> It's a Java package, wouldn' you consider maintaining it under the
> umbrella of the pkg-java Alioth's project?
> 
> http://pkg-java.alioth.debian.org/
> 
> You are welcome to join us.

Already cleared up on IRC. It will be uploaded under the Debian Java
Maintainers umbrella. I already reviewed the existing package and gave
some advices. I will take care of it.


Cheers,
Michael
-- 
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html

Join the community at http://planet.classpath.org/


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

Re: RFC: GTK+ icon cache

[Gabor Gombas]

On Tue, Oct 11, 2005 at 03:51:15PM +0200, Josselin Mouette wrote:

> 2. The cure
> A mmap()-able cache file format was proposed, and is generated by
> gtk-update-icon-cache in /usr/share/icons/$theme/icon-theme.cache files.
> It helps a lot to improve speed.

You mean _/var_//$theme/icon-theme.cache, don't you?

> 5. The proposed solution
> The Redhat people, who implemented the cache specification, obviously
> don't have problems with applications suddenly becoming unusable after
> some change: they started to generate cache for all directories,
> automatically adding post-installation snippets to the application
> packages. As "this worked", and as the GTK+ developers - which happen to
> be partly the same people - don't want to change the code, their
> recommendation is to do the same for Debian. Applying this solution
> means that, as soon as some packages start using the new debhelper
> snippet, hundreds of other packages will more or less break when
> installed after the cache generation.

My personal opinion that when a package modifies/extends a theme by
installing a new icon it is a reasonable requirement to somehow
"register" the changes (in this case by updating the cache file).

What about adding a script to /etc/cron.daily to regenerate the caches
on a regular basis until all applications are updated? Users of unstable
should be prepared for short breakages anyway.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: Bug#333120: ITP: icu4j -- International Components for Unicode for Java

[Arnaud Vandyck]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Koch wrote:
> On Tue, Oct 11, 2005 at 04:14:49PM +0200, Arnaud Vandyck wrote:
>>Seo Sanghyeon wrote:
>>>Package: wnpp
>>>Severity: wishlist
>>>Owner: Seo Sanghyeon <[EMAIL PROTECTED]>
>>>* Package name: icu4j
>>It's a Java package, wouldn' you consider maintaining it under the
>>umbrella of the pkg-java Alioth's project?
> Already cleared up on IRC. It will be uploaded under the Debian Java
> Maintainers umbrella. I already reviewed the existing package and gave
> some advices. I will take care of it.

Thanks Michael,

- --
  .''`.
 : :' :rnaud
 `. `'
   `-
Java Trap: http://www.gnu.org/philosophy/java-trap.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDS82A4vzFZu62tMIRAt8VAKCdBapb0jISJ/76L/T28MtuM2m6WwCcD5ac
Lp3XWADVwxARXYthONHhHxk=
=WphX
-END PGP SIGNATURE-


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

Bug#333355: ITP: bmpx -- Universal audio player supporting Winamp skins

[Mathias Weyland]

Package: wnpp
Severity: wishlist

* Package name: bmpx
  Version : 0.13
  Upstream Author : M. Derezynski <[EMAIL PROTECTED]>
* URL : http://bmpx.berlios.de/w/index.php/BMPx_Homepage
* License : GPL
  Description : Universal audio player supporting Winamp skins

The beep media player x is an audio player that can be either used with
 a built-in frontend which currently utilizes Winamp 2.x compatible skins,
 or as a daemon for other frontends to connect via a DBus interface. It
 relies on libxine and can therefore play all the formats which are
 supported by this library. BMPx comes with a VFS layer that allows 
 location-independent access to files.
 .
 Please note that BMPx is a rewrite and does not share the xmms codebase
 anylonger. This means that xmms plugins and old BMP plugins are not supported
 by this package.


---
Note: Upstream decided to abandon the old xmms source code base. I decided to
provide BMPx as a separate package. This has three reasons:

1. The plugin API completely changed. For example, BMPx will use libvisual for
   visualization plugins. Current beep media player plugins and ported xmms 
plugins
   won't work.

2. BMPx is usable at the moment, but can't be considered as a replacement for
   the beep media player currently in Debian. This can change soon, but it does 
not
   have to.

3. The name of the current BMP package is beep-media-player, which is quite
   long IMO. Section 2.3 of the new maintainer guide suggest to use 
abbreviations.

Please also note that I have a package ready but it may take some time until it
gets into Debian unstable because some of the dependencies are still only
available in experimental.

Best regards
Mathias Weyland


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

Re: Automatically sending test suite results from buildds to upstream

[Florian Ragwitz]

On Tue, Oct 11, 2005 at 04:07:16AM +0200, Steinar H. Gunderson wrote:
> On Tue, Oct 11, 2005 at 01:35:06AM +0200, Florian Ragwitz wrote:
> > Therefor I'd like to automatically upload these results to
> > http://smoke.pugscode.org after the packages are built on the
> > buildds.
> 
> Make your package building fail whenever a test in the testsuite
> fails? The FTBFS bugs and the buildd logs are sure to tell you what
> test went wrong.  Having a known-bad package built is a generally bad
> thing anyhow, so you won't really lose much on failing it :-)

Pugs is currenyly in a phase of quite early and rapid development. Not
everything is ought to at the moment anyway and it's not able to be used
in productive environments. I doubt it will ever be because it'll be
replaced by the real Perl6 interpreter as soon as it's available. I
don't think a single test fail makes a package totally unusable.


Regards,
Flo

-- 
BOFH excuse #373:
Suspicious pointer corrupted virtual machine


signature.asc
Description: Digital signature

Re: Automatically sending test suite results from buildds to upstream

[Florian Ragwitz]

On Tue, Oct 11, 2005 at 12:09:57PM +0200, Jeroen van Wolffelaar wrote:
> On Tue, Oct 11, 2005 at 08:32:51AM +0200, Jeroen Massar wrote:
> > On Tue, 2005-10-11 at 02:13 +0200, Florian Ragwitz wrote:
> > > On Mon, Oct 10, 2005 at 08:07:52PM -0400, Daniel Jacobowitz wrote:
> > 
> > > > or to include test results in the .deb files and retrieve them after
> > > > the build.  That latter is what the GCC packages do.
> > > 
> > > I don't like that solution. Users of the package don't care about the
> > > test results so it's useless to bloat the packages with them.
> > 
> > Stick the debug files into a seperate -debug package, which nobody will
> > install anyway and just consumes some archive space.
> 
> Packages that nobody will install should not be in the Debian archive. -debug
> packages only make really sense for a small number of the most high-profile
> packages.
> 
> In this case, the extract results from buildd.d.o way is the way to go IMHO.
> It can be automated too if really needed if you make sure to output specific
> markers before & after the tests run.

I think that's the way to go here. Thanks.


-Flo

-- 
BOFH excuse #292:
We ran out of dial tone and we're and waiting for the phone company to
deliver another bottle.


signature.asc
Description: Digital signature

Finding out in postinst whether some other package is configured

[Frank Küster]

Hi,

is there an established way to find out in the postinst script of a
package whether an other package (e.g. one which we Recommend or
Suggest) is configured?  Testing for file contents can only tell whether
it is unpacked, but that might not be enough.

If there isn't, are there other people who felt the need to know this?

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Finding out in postinst whether some other package is configured

[martin f krafft]

also sprach Frank Küster <[EMAIL PROTECTED]> [2005.10.11.1928 +0200]:
> is there an established way to find out in the postinst script of a
> package whether an other package (e.g. one which we Recommend or
> Suggest) is configured?  Testing for file contents can only tell whether
> it is unpacked, but that might not be enough.

Assuming it provides a conffile, can you check for $FILE.dpkg-new ?

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"i am a deeply superficial person."
  -- andy warhol


signature.asc
Description: Digital signature (GPG/PGP)

Re: Finding out in postinst whether some other package is configured

[Ben Armstrong]

On Tue, 2005-10-11 at 19:28 +0200, Frank Küster wrote:
> is there an established way to find out in the postinst script of a
> package whether an other package (e.g. one which we Recommend or
> Suggest) is configured?  Testing for file contents can only tell whether
> it is unpacked, but that might not be enough.
> 
> If there isn't, are there other people who felt the need to know this?

I worry about why you would need to know this.  I'm envisioning a
package "A" that has a particular default configuration if you install A
before B, but a different configuration if you install B before A.  What
will the user be missing out on if they're installed in the "wrong"
order?  And what corrective action can the user take?

Ben


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

Re: Finding out in postinst whether some other package is configured

[Frank Küster]

martin f krafft <[EMAIL PROTECTED]> wrote:

> also sprach Frank Küster <[EMAIL PROTECTED]> [2005.10.11.1928 +0200]:
>> is there an established way to find out in the postinst script of a
>> package whether an other package (e.g. one which we Recommend or
>> Suggest) is configured?  Testing for file contents can only tell whether
>> it is unpacked, but that might not be enough.
>
> Assuming it provides a conffile, can you check for $FILE.dpkg-new ?

But this file will stay there if the user chooses to keep their changed
version.  So I would have to check for $FILE, too.  But then I can't
discriminate between "was removed but not purged, now it is unpacked but
unconfigured" and "is configured but the user chose to keep the old
changed conffile", can I?

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Finding out in postinst whether some other package is configured

[Frank Küster]

Ben Armstrong <[EMAIL PROTECTED]> wrote:

> On Tue, 2005-10-11 at 19:28 +0200, Frank Küster wrote:
>> is there an established way to find out in the postinst script of a
>> package whether an other package (e.g. one which we Recommend or
>> Suggest) is configured?  Testing for file contents can only tell whether
>> it is unpacked, but that might not be enough.
>> 
>> If there isn't, are there other people who felt the need to know this?
>
> I worry about why you would need to know this.  I'm envisioning a
> package "A" that has a particular default configuration if you install A
> before B, but a different configuration if you install B before A.  What
> will the user be missing out on if they're installed in the "wrong"
> order?  And what corrective action can the user take?

In the particular case, the reason is something else: If the recommended
package B (tetex-bin) is there, it makes sense to run one of its
executables (mktexlsr, updmap) to register the files of package A (any TeX
font package).  This is a time-consuming process.  However, if B is
installed but unconfigured, we can save this time because when B is
configured, it will run these executables, anyway, and doing this also
will pick up package A's files.

While writing this, I get the feeling that I don't want to know this.  I
have been thinking about a mechanism to run these time-consuming
processed with a dpkg-postinstallation hook as zope does for a long
time.  But I decided not to do this because they sometimes fail (99%
because of user misconfiguration), and it's better to know which package
was configured when it failed.  For the same reason, I probably don't
want to delay the registration process if tetex-bin isn't already
configured. 

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

[Fwd: major problem with gnome-games dependency]

[Arthur H. Edwards]

I work at a government laboratory where computer games are prohibited. I 
also use the gnome desktop. When I try to remove gnome-games apt wanst 
to remove gnome because gnome depends on gnome-games. This is really a 
show-stopper for government use of Linux. Also, I would think that the 
dependency should work the other way: gnome-games should depend on gnome.


Art Edwards

--
Arthur H. Edwards
Senior Research Physicist
Air Force Research Laboratory
AFRL/VSSE
Bldg. 914
3550 Aberdeen Ave. SE
KAFB, NM 87117-5776

(505) 853-6042 (O)
(505) 463-6722 (C)
(505) 846-2290 (F)


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





--
Arthur H. Edwards
Senior Research Physicist
Air Force Research Laboratory
AFRL/VSSE
Bldg. 914
3550 Aberdeen Ave. SE
KAFB, NM 87117-5776

(505) 853-6042 (O)
(505) 463-6722 (C)
(505) 846-2290 (F)


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

Re: [Fwd: major problem with gnome-games dependency]

[Thomas Bushnell BSG]

"Arthur H. Edwards" <[EMAIL PROTECTED]> writes:

> I work at a government laboratory where computer games are prohibited. I 
> also use the gnome desktop. When I try to remove gnome-games apt wanst 
> to remove gnome because gnome depends on gnome-games. This is really a 
> show-stopper for government use of Linux. Also, I would think that the 
> dependency should work the other way: gnome-games should depend on gnome.

It should be an easy matter not to play the games even when they are
installed.  Regardless, the "gnome" package is not necessary for the
system; it is just a meta-package that depends on all the
gnome-related packages.  If you don't want all the gnome-related
packages, then you can skil installing the "gnome" package and just
choose the ones you want.

Thomas


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

Re: Finding out in postinst whether some other package is configured

[Ben Armstrong]

On Tue, 2005-10-11 at 19:28 +0200, Frank Küster wrote:
> is there an established way to find out in the postinst script of a
> package whether an other package (e.g. one which we Recommend or
> Suggest) is configured?

Assuming your package does something reasonable with this knowledge ...

> Testing for file contents can only tell whether
> it is unpacked, but that might not be enough.

I don't know about an "established" way, but libc6.postinst looks
interesting:

# Only get the ones that are installed, and configured
check=$(dpkg -s $check 2> /dev/null | egrep '^Package:|^Status:' | awk '{if ($1 
~ /^Package:/) { package=$2 } else if ($0 ~ /^Status: .* installed$/) { print 
package }}')

Ben


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

Bug#333392: ITP: rkward -- A KDE frontend to the R statistics language

[Thomas Friedrichsmeier]

Package: wnpp
Severity: wishlist
Owner: Thomas Friedrichsmeier <[EMAIL PROTECTED]>


* Package name: rkward
  Version : 0.3.3
  Upstream Author : Thomas Friedrichsmeier <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : GPL
  Description : A KDE frontend to the R statistics language

Description: A KDE frontend to the R statistics language
 RKWard is meant to become an easy to use, transparent frontend to the 
R-language, a very powerful, yet hard-to-get-into scripting-language with a 
strong focus on statistic functions. It will not only provide a convenient  
user-interface, however, but also take care of seamless integration with an  
office-suite. Practical statistics is not just about calculating, after all, 
but also about documenting and ultimately publishing the results.
 RKWard is still in early development status.

Homepage: http://rkward.sourceforge.net
Downloads: http://sourceforge.net/project/showfiles.php?group_id=50231
CVS instructions: http://sourceforge.net/cvs/?group_id=50231

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: [Fwd: major problem with gnome-games dependency]

[Arthur H. Edwards]

First, we don't play the games, but they are inventoried, and they can't 
be there. Second, I can, indeed, remove gnome and re-install individual 
packages and waste a fair amount of time. Government computers are a 
fairly large group and I would think that you might want to facilitate 
the use of Linux and of Debian on them by swapping the dependency. If 
not you will be telling each of us to embark on a Rube Goldberg 
installation process.


Art Edwards

Thomas Bushnell BSG wrote:


"Arthur H. Edwards" <[EMAIL PROTECTED]> writes:

 

I work at a government laboratory where computer games are prohibited. I 
also use the gnome desktop. When I try to remove gnome-games apt wanst 
to remove gnome because gnome depends on gnome-games. This is really a 
show-stopper for government use of Linux. Also, I would think that the 
dependency should work the other way: gnome-games should depend on gnome.
   



It should be an easy matter not to play the games even when they are
installed.  Regardless, the "gnome" package is not necessary for the
system; it is just a meta-package that depends on all the
gnome-related packages.  If you don't want all the gnome-related
packages, then you can skil installing the "gnome" package and just
choose the ones you want.

Thomas

 



--
Arthur H. Edwards
Senior Research Physicist
Air Force Research Laboratory
AFRL/VSSE
Bldg. 914
3550 Aberdeen Ave. SE
KAFB, NM 87117-5776

(505) 853-6042 (O)
(505) 463-6722 (C)
(505) 846-2290 (F)


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

Re: [Fwd: major problem with gnome-games dependency]

[Steinar H. Gunderson]

On Tue, Oct 11, 2005 at 12:10:22PM -0600, Arthur H. Edwards wrote:
> I work at a government laboratory where computer games are prohibited. I 
> also use the gnome desktop. When I try to remove gnome-games apt wanst 
> to remove gnome because gnome depends on gnome-games. This is really a 
> show-stopper for government use of Linux. Also, I would think that the 
> dependency should work the other way: gnome-games should depend on gnome.

I've always wanted apt to be able to distinguish between a task and a
metapackage; something like “I want GNOME, but without the games and
Evolution, please”...

Would it help having our metapackages use all Recommends instead of Depends?

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: [Fwd: major problem with gnome-games dependency]

[Thomas Bushnell BSG]

"Arthur H. Edwards" <[EMAIL PROTECTED]> writes:

> First, we don't play the games, but they are inventoried, and they can't 
> be there. Second, I can, indeed, remove gnome and re-install individual 
> packages and waste a fair amount of time. Government computers are a 
> fairly large group and I would think that you might want to facilitate 
> the use of Linux and of Debian on them by swapping the dependency. If 
> not you will be telling each of us to embark on a Rube Goldberg 
> installation process.

Removing the "gnome" package does not cause you to remove the
individual packages it depended on.

Swapping the dependency is wrong; gnome-games does not depend on all
of gnome.

The purpose of the "gnome" package is just to be a placeholder for
"all gnome-related packages".  Deleting that package does not delete
the individual packages that it depended on.


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

Re: [Fwd: major problem with gnome-games dependency]

[Ben Armstrong]

On Tue, 2005-10-11 at 11:20 -0700, Thomas Bushnell BSG wrote:
> It should be an easy matter not to play the games even when they are
> installed.  Regardless, the "gnome" package is not necessary for the
> system; it is just a meta-package that depends on all the
> gnome-related packages.  If you don't want all the gnome-related
> packages, then you can skil installing the "gnome" package and just
> choose the ones you want.

This property of metapackages has always irked me.  If I install gnome
and then remove gnome-games, I won't automatically benefit in the next
release from any other goodies the gnome maintainers have added to
"gnome" package.

Of course, the user could use the "equivs" package to make a fake
gnome-games to satisfy the dependency, but the dire warnings in the
description of the equivs package (assuming the user even knows equivs
exists) are going to discourage most users from trying this.

Ben


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

Re: [Fwd: major problem with gnome-games dependency]

[Thomas Bushnell BSG]

Ben Armstrong <[EMAIL PROTECTED]> writes:

> This property of metapackages has always irked me.  If I install gnome
> and then remove gnome-games, I won't automatically benefit in the next
> release from any other goodies the gnome maintainers have added to
> "gnome" package.

I think the question is: do you want all the goodies or you don't want
all the goodies?

I would not object to a meta package gnome-without-games if the gnome
maintainers want to add one.  

I would love a way to have a negative way of handling the whole darn
thing.  I thought tasks were supposed to get rid of metapackages
anyway.  

Thomas


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

Re: [Fwd: major problem with gnome-games dependency]

[Ben Armstrong]

On Tue, 2005-10-11 at 11:51 -0700, Thomas Bushnell BSG wrote:
> I think the question is: do you want all the goodies or you don't want
> all the goodies?

Well, the problem is, when "all the goodies" is a significant number of
packages, it is tedious to have to collect them all myself.

> I would not object to a meta package gnome-without-games if the gnome
> maintainers want to add one.  

And what about the user who said "and evolution"?  So far we have
gnome-without-games, gnome-without-games-and-evolution, and (logically)
gnome-without-evolution.  Care to add a few more exceptions and all of
their permutations? :)

> I would love a way to have a negative way of handling the whole darn
> thing.  I thought tasks were supposed to get rid of metapackages
> anyway.  

Sure.  So did I.

Ben


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

Re: [Fwd: major problem with gnome-games dependency]

[Ross Burton]

On Tue, 2005-10-11 at 20:32 +0200, Steinar H. Gunderson wrote:
> On Tue, Oct 11, 2005 at 12:10:22PM -0600, Arthur H. Edwards wrote:
> > I work at a government laboratory where computer games are prohibited. I 
> > also use the gnome desktop. When I try to remove gnome-games apt wanst 
> > to remove gnome because gnome depends on gnome-games. This is really a 
> > show-stopper for government use of Linux. Also, I would think that the 
> > dependency should work the other way: gnome-games should depend on gnome.
> 
> I've always wanted apt to be able to distinguish between a task and a
> metapackage; something like “I want GNOME, but without the games and
> Evolution, please”...

That is what gnome-core is for: just enough of GNOME to be usable, but
no real apps beyond EoG and gedit.  Purposefully created for people who
want to use GNOME, don't want to install all packages manually, but want
some control over what extra packages are installed.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF

Re: [Fwd: major problem with gnome-games dependency]

[Ben Armstrong]

On Tue, 2005-10-11 at 20:07 +0100, Ross Burton wrote:
> That is what gnome-core is for: just enough of GNOME to be usable, but
> no real apps beyond EoG and gedit.  Purposefully created for people who
> want to use GNOME, don't want to install all packages manually, but want
> some control over what extra packages are installed.

$ apt-cache show-differing-dependencies gnome-core gnome
Dependencies only in gnome-core:
  Depends: ...
  Suggests: ...
  ...
Dependencies only in gnome
   ...

But in the absence of such a feature, I can't tell what I'd be missing
if I only installed gnome-core.

Ben


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

Re: [Fwd: major problem with gnome-games dependency]

[Daniel Burrows]

On Tue, Oct 11, 2005 at 11:33:50AM -0700, Thomas Bushnell BSG <[EMAIL 
PROTECTED]> was heard to say:
> "Arthur H. Edwards" <[EMAIL PROTECTED]> writes:
> 
> > First, we don't play the games, but they are inventoried, and they can't 
> > be there. Second, I can, indeed, remove gnome and re-install individual 
> > packages and waste a fair amount of time. Government computers are a 
> > fairly large group and I would think that you might want to facilitate 
> > the use of Linux and of Debian on them by swapping the dependency. If 
> > not you will be telling each of us to embark on a Rube Goldberg 
> > installation process.
> 
> Removing the "gnome" package does not cause you to remove the
> individual packages it depended on.

  It does if you're using aptitude; you'd have to do something like
"aptitude keep ~Rdepends:^gnome$".  (but not if you're using
experimental, 'cos that'll send it into an infinite memory-eating
loop...great, another bug to fix)

  Daniel


signature.asc
Description: Digital signature

Bug#333399: ITP: libapache2-mod-cband -- An Apache 2 module for bandwidth limiting the webserver

[Jonas Genannt]

Package: wnpp
Severity: wishlist
Owner: Jonas Genannt <[EMAIL PROTECTED]>


* Package name: libapache2-mod-cband
  Version : 0.9.5
  Upstream Author : Lukasz Dembinski <[EMAIL PROTECTED]>,
Sergey V. Beduev <[EMAIL PROTECTED]>,
Kyle Poulter <[EMAIL PROTECTED]>
* URL : http://cband.linux.pl
* License : GPL
 Description : An Apache 2 module for bandwidth limiting the webserver

This Apache 2 module provided to solve the problem of limiting users'  and
virtualhosts' bandwidth usage. When a configured virtualhost's transfer
limit is exceeded, mod_cband will redirect all further requests to a
location specified in the configuration file.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686-smp
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: [Fwd: major problem with gnome-games dependency]

[Daniel Burrows]

On Tue, Oct 11, 2005 at 08:32:35PM +0200, "Steinar H. Gunderson" <[EMAIL 
PROTECTED]> was heard to say:
> On Tue, Oct 11, 2005 at 12:10:22PM -0600, Arthur H. Edwards wrote:
> > I work at a government laboratory where computer games are prohibited. I 
> > also use the gnome desktop. When I try to remove gnome-games apt wanst 
> > to remove gnome because gnome depends on gnome-games. This is really a 
> > show-stopper for government use of Linux. Also, I would think that the 
> > dependency should work the other way: gnome-games should depend on gnome.
> 
> I've always wanted apt to be able to distinguish between a task and a
> metapackage; something like “I want GNOME, but without the games and
> Evolution, please”...
> 
> Would it help having our metapackages use all Recommends instead of Depends?

  No, because people like to turn off the installation of recommendations
and then file bugs when major functionality is missing from packages :-/.

  Daniel


signature.asc
Description: Digital signature

Re: [Fwd: major problem with gnome-games dependency]

[Frans Pop]

On Tuesday 11 October 2005 21:34, Daniel Burrows wrote:
>   No, because people like to turn off the installation of
> recommendations

Or yes, because it offers more flexibility to people who have a basic idea 
of what they are doing.

> and then file bugs when major functionality is missing 
> from packages :-/.

Bugs that result from stupidity or being clueless can be closed.


pgp5pR3X82nTS.pgp
Description: PGP signature

ACPI problem on Sid

[Alejandro Bonilla]

Hi all,

This ain't a development question, but it can be a bug...

I was wondering, could this be related to Sid or with the kernel itself?

The battery meter icon in gnome goes to n/a.

IBM T42, Sid 2.6.14-rc4-git latest, but I have seen this behavior before...

dmesg is full of:

ACPI-0213: *** Error: Method reached maximum reentrancy limit (255)
ACPI-0508: *** Error: Method execution failed
[\_SB_.PCI0.LPC_.EC__.BAT0._BIF] (Node c14cd4c0), AE_AML_METHOD_LIMIT

A reboot normally fixes this, but I have only seen this 3 times.

/etc/init.d/acpid restart has no effect.

.Alejandro


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

Re: [Fwd: major problem with gnome-games dependency]

[Jeroen van Wolffelaar]

On Tue, Oct 11, 2005 at 09:49:49PM +0200, Frans Pop wrote:
> On Tuesday 11 October 2005 21:34, Daniel Burrows wrote:
> >   No, because people like to turn off the installation of
> > recommendations
> 
> Or yes, because it offers more flexibility to people who have a basic idea 
> of what they are doing.

Those can simply install the pacakges they want. It isn't rocket science.
 
> > and then file bugs when major functionality is missing 
> > from packages :-/.
> 
> Bugs that result from stupidity or being clueless can be closed.

Well, if the meta packages description is: "Gives you the full GNOME suite
with all associated programs", which is minus phrasing what the actual
description is, then a recommends would simply by plainly wrong. If you don't
want the "The GNOME Desktop Environment, with extra components", don't install
gnome. With today's size of a typical harddisk, for 99% of the people such a
package would be exactly what they want. If you have specialized requirements,
like the thread starter, you can put together your own set of packages. Or you
can use debtags, to install "desktop-environment::gnome && !type::game"
(pseudo-syntax).

The main things that this thread shows me, is that it is *not* immediately
clear to people not too familiar with Debian that the removal of the 'gnome'
package will not have *any* effect on what actual software is actually installed
on your system.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


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

Re: [Fwd: major problem with gnome-games dependency]

[Joe Smith]

"Frans Pop" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Tuesday 11 October 2005 21:34, Daniel Burrows wrote:

  No, because people like to turn off the installation of
recommendations


Or yes, because it offers more flexibility to people who have a basic idea
of what they are doing.


Exactly. Unless you plan to examine each and every reccomendation of each 
and every package you install then you should not turn off reccomendation 
installation.


Recoomendations are intended to be weak depends. In other words 
recommendations mean: "This package does not actually NEED the listed 
packages, but it is unlikely you will want to install this package without 
the listed package." An even better way to think of it is a Depends that can 
be overridden without apt complaining.




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

Re: [Fwd: major problem with gnome-games dependency]

[Thijs Kinkhorst]

On Tue, 2005-10-11 at 22:00 +0200, Jeroen van Wolffelaar wrote:
> The main things that this thread shows me, is that it is *not* immediately
> clear to people not too familiar with Debian that the removal of the 'gnome'
> package will not have *any* effect on what actual software is actually 
> installed
> on your system.

Indeed, and this is because the meta-package is not a really good tool
for this job. It has to depend on all packages in order to install them
all, so if you remove one component you get the confusing message that
you need to remove "gnome" aswell.

As most of us I'm not too affectionally engaged with our friends from
Redmond, but they've solved this kind of problem in a simple and elegant
way in the installation of MS Office. If you check the box in front of
PowerPoint, you get the whole thing, or uncheck it and don't install it.
But users who want to customize a bit, can click the + or arrow or
whatever in front of PowerPoint and are offered the choice to
(de-)select many of the sub-components of the item.

I'm not sure whether something like this is already possible, but in my
opinion would be a good way to offer this kind of choice during the
installation.


regards,
Thijs



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

Re: major problem with gnome-games dependency

[Arthur H. Edwards]

I want to thank all of you for responding. I'm quoting here a response I 
gave to an off-line communication because I thought it might be germane 
to the discussion. I have expanded my response a little.


I have removed gnome, gnome-desktop-environment and gnome-games with no
apparent side effects. However, there were a number of KDE games that
I had to remove by hand (Yes, I had both KDE and gnome on the machine).


The workings of meta packages are very interesting and, in the end, very 
clean, if you are initiated (as I am beginning to be). I would just 
point out that if Debian is targeting
scientists and engineers with limited time, and some, but not burning, 
curiosity about installation, that you spend a little time thinking 
about how to make meta packages transparent at installation.


As a layman's recommendation, it might be nice to have a gnome
installation dialog that asked you to check the components you want for
installation, similar to the task selection on the (old?) debian
installer. Some care would be required so that this had a human level of 
detail. For example, you might have tasks, such as mail, office, games, 
network (or, perhaps, browser). This would always be imperfect, but it 
would obviate the need for gnome-without-games or 
gnome-without-evolution, etc.


Art Edwards

[EMAIL PROTECTED] wrote:

I work at a government laboratory where computer games are prohibited. I 
also use the gnome desktop. When I try to remove gnome-games apt wanst 
to remove gnome because gnome depends on gnome-games. This is really a 
show-stopper for government use of Linux. Also, I would think that the 
dependency should work the other way: gnome-games should depend on gnome.
   



I worked at a government laboratory where computer games were prohibited.
We used Debian there; it behaved exactly the same way.  Strangely, it
didn't cause us a problem.

The reason it didn't is because when you remove gnome-games, apt does
*not* try to remove the GNOME desktop.  Instead, it tries to remove
the meta-package "gnome", which is not the same thing.

You may want to google this list's archives on what meta-packages are
and how they work.

Cheers,

-c

P.S.  The meta-package "gnome"'s dependence upon the (meta?) package
gnome-games is perfectly sane, given what meta-packages are for.





 



--
Arthur H. Edwards
Senior Research Physicist
Air Force Research Laboratory
AFRL/VSSE
Bldg. 914
3550 Aberdeen Ave. SE
KAFB, NM 87117-5776

(505) 853-6042 (O)
(505) 463-6722 (C)
(505) 846-2290 (F)


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

Re: Finding out in postinst whether some other package is configured

[martin f krafft]

also sprach Frank Küster <[EMAIL PROTECTED]> [2005.10.11.2003 +0200]:
> But this file will stay there if the user chooses to keep their changed
> version. 

No, then it would be moved to *.dpkg-dist

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"in the figure of the president, george w. bush, the incompetence,
 stupidity, and sheer inhumanity that characterize so much of
 america’s money-mad corporate elite find their quintessentially
 repulsive expression."
 -- journalist, aftermath of katrina


signature.asc
Description: Digital signature (GPG/PGP)

Re: Bug#333392: ITP: rkward -- A KDE frontend to the R statistics language

[Dirk Eddelbuettel]

Thomas Friedrichsmeier  gmx.de> writes:
> Package: wnpp
> Severity: wishlist
> Owner: Thomas Friedrichsmeier  users.sourceforge.net>
> 
> * Package name: rkward
>   Version : 0.3.3
>   Upstream Author : Thomas Friedrichsmeier  users.sourceforge.net>
> * URL : http://www.example.org/

That should behttp://rkward.sourceforge.net   instead.

> * License : GPL
>   Description : A KDE frontend to the R statistics language
> 
> Description: A KDE frontend to the R statistics language
>  RKWard is meant to become an easy to use, transparent frontend to the 
> R-language, a very powerful, yet hard-to-get-into scripting-language with
> a strong focus on statistic functions.

I understand that you just copied this from the Rkward website, but I'd still 
suggest some editing. See the R FAQ, section 2.1:

   R is a system for statistical computation and graphics. It consists of a
   language plus a run-time environment with graphics, a debugger, access to
   certain system functions, and the ability to run programs stored in script
   files.

That said, I don't mean to discourage you -- I'd be glad to test a package
or two before you upload them.  It will be nice to have this in Debian, and
I'll surely add it to Quantian too :)

Regards, Dirk 


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

Bug#333438: ITP: gtk2hs -- A GUI library for Haskell based on GTK

[Marco Tulio Gontijo e Silva]

Package: wnpp
Severity: wishlist
Owner: Marco Tulio Gontijo e Silva <[EMAIL PROTECTED]>

This is a very important package for haskell developers.

* Package name: gtk2hs
  Version : x.y.z
  Upstream Author : Name <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Description : A GUI library for Haskell based on GTK

 It features:
 * Automatic memory management.
 * Nearly complete coverage of the underlying Gtk+ library.
 * Unicode support.
 * Documentation.
 * Support for Linux, Unix, MacOS X and Windows platforms.
 * Bindings for several Gnome modules:
  * libglade for loading GUIs from xml files at run-time. This allows you to
design your user interface visually using the Glade user interface
builder.
  * GConf, Gnome’s system for storing application preferences.
  * SourceView, a source code editor widget with syntax highlighting.
 * Bindings for the Mozilla browser rendering engine.
 .
 Homepage: http://www.gtk2hs.org/

-- 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-1-k7
Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1)


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

Re: major problem with gnome-games dependency

[Paul E Condon]

I suggest Debian add two metapackages: 'gnome-govt' for use by all
governments and 'gnome-USgovt' for US government in particular. ;-)

On Tue, Oct 11, 2005 at 04:09:55PM -0600, Arthur H. Edwards wrote:
> I want to thank all of you for responding. I'm quoting here a response I 
> gave to an off-line communication because I thought it might be germane 
> to the discussion. I have expanded my response a little.
> 
> I have removed gnome, gnome-desktop-environment and gnome-games with no
> apparent side effects. However, there were a number of KDE games that
> I had to remove by hand (Yes, I had both KDE and gnome on the machine).
> 
snip...

-- 
Paul E Condon   
[EMAIL PROTECTED]


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

Re: [Fwd: major problem with gnome-games dependency]

[Adeodato Simó]

  [CC'ing the aptitude maintainer, mainly for the last paragraph.]

* Jeroen van Wolffelaar [Tue, 11 Oct 2005 22:00:22 +0200]:

> The main things that this thread shows me, is that it is *not* immediately
> clear to people not too familiar with Debian that the removal of the 'gnome'
> package will not have *any* effect on what actual software is actually 
> installed
> on your system.

  Do not forget, though, that with aptitude becoming the prefered tool
  for package management (over plain apt-get), this is no longer true.
  "aptitude install gnome" will mark all of its dependencies as "auto",
  i.e. just installed because of a dependency. Which means that
  "aptitude remove gnome" will want to remove all the dependencies _for
  real_, unless they have been previously marked as "noauto" by hand.

  If grasping the concept "removing a metapackage won't remove the
  dependencies" was already difficult, grasping the whole auto/noauto
  story can be... ykwim. Which, IMV, means that the user should not have
  to care (much) about that.

 * * *

  As mentioned in [1], we've been considering switching to Recommends
  for KDE metapackges, and mention in the description about the use of
  --with-recommends.

  What perhaps would be really best, though, would be some kind of
  special handling for metapackages from aptitude et al. For example
  (just the first I could think of), assume --with-recommends for
  packages that have "Metapackage: yes". But this leaves the problem of
  how to detect on upgrades if a recommended but not installed package
  was uninstalled by the user, or newly introduced in the new version.
  Daniel, do you have any comments on this? Is there a bug open about
  handling of metapackages, or perhaps would be a good idea to open one?

  Cheers,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself.  Therefore all
progress depends on the unreasonable man.
-- George Bernard Shaw


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

Re: [Fwd: major problem with gnome-games dependency]

[Adeodato Simó]

>   As mentioned in [1]

  [1] http://lists.debian.org/debian-release/2005/04/msg00070.html

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
He has never been known to use a word that might send a reader to the
dictionary.
-- William Faulkner (about Ernest Hemingway)


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

request for pbuilder-user-mode-linux development/tester

[Junichi Uekawa]

Hi,

I've not been able to resurrect user-mode-linux on my system,
and it doesn't run; and thus I'm looking for someone who
may be interested in pbuilder-uml, and has or has an intention of 
having functional user-mode-linux.

pbuilder-uml has been unmaintained for the past year; and 
I guess it will have some rough edges.

requirements are:

1. running testsuite/run-test-uml.sh daily to make sure pbuilder-uml
  is somewhat functional.

2. have a running user-mode-linux

3. commit fixes to pbuilder when pbuilder-uml doesn't seem to work;
  be a co-maintainer of pbuilder.

4. Cooperation with pbuilder-maint mailing list.


regards,
junichi


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

Re: [Fwd: major problem with gnome-games dependency]

[Daniel Burrows]

On Wed, Oct 12, 2005 at 03:13:30AM +0200, Adeodato Simó <[EMAIL PROTECTED]> was 
heard to say:
>   As mentioned in [1], we've been considering switching to Recommends
>   for KDE metapackges, and mention in the description about the use of
>   --with-recommends.
> 
>   What perhaps would be really best, though, would be some kind of
>   special handling for metapackages from aptitude et al. For example
>   (just the first I could think of), assume --with-recommends for
>   packages that have "Metapackage: yes". But this leaves the problem of
>   how to detect on upgrades if a recommended but not installed package
>   was uninstalled by the user, or newly introduced in the new version.
>   Daniel, do you have any comments on this? Is there a bug open about
>   handling of metapackages, or perhaps would be a good idea to open one?

  The issue of recommendations appearing in new versions is a general
problem, not one specific to metapackages.  I have some code that tries
to detect new recommendations, but I haven't actually used it as a
replacement for the default rule of "only recommendations of newly
installed packages are important".  I need to talk to the apt developers
about how to integrate this (last time I checked apt changes were needed
to get it working), then test it.

  In addition to forcing the program to follow recommendations, the
other thing to deal with is the interaction between metapackages and
"cruft removal".  I think you could deal with that using the rule that
"when a metapackage is placed into manual mode, so are all its
(pre)dependencies and recommendations".  This would make it annoying to
put a metapackage back into automatic mode, but it's safe and not hard
to 

  I don't remember if there are any bugs open about metapackages, but
they aren't especially useful until we have a way of formally
identifying metapackages; e.g., by adding a "Metapackage: yes" header in
the control file.  On the other hand, debtags does flag metapackages, and
I can probably work with that for the time being.

  Daniel


signature.asc
Description: Digital signature

Re: [Fwd: major problem with gnome-games dependency]

[Joey Hess]

Adeodato Simó wrote:
>   As mentioned in [1], we've been considering switching to Recommends
>   for KDE metapackges, and mention in the description about the use of
>   --with-recommends.

If you do that you will make the desktop task no longer install an
appropriate amount of kde[2]:

[EMAIL PROTECTED]:~/src/tasksel>grep recommends tasksel.pl
my $ret=system("aptitude", "--without-recommends", "-y", "install", 
@aptitude_install) >> 8;

It's very easy to end up with a recommends chain that pulls in all of X
when you wanted something simple like cups. At least that kind of thing
was common when I turned it off in tasksel.

Some other good reasons not to use recommends for metapackage would
include those of us who have aptitude configured not to take recommends
by default, or probably anyone who wants to use synaptic.

-- 
see shy jo

[2] Not that it currently installs kde, since it's broken, but anyway.


signature.asc
Description: Digital signature

apt-get in Sid broke sound and /etc/modules?

[Alejandro Bonilla Beeche]

Hi,

   I think this is udev's fault.

1. Nothing is apparently doing what /etc/modules says. (order)
2. My sound card is now not recognized, maybe this is because hotplug is 
not there anymore?
:00:1f.5 Multimedia audio controller: Intel Corporation 
82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)


IBM T42

.Alejandro


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

real-i386 (was Re: i386 requalification for etch

[Nathanael Nerode]

I sent a message about this earlier, but it seems to have gotten lost.
> On Saturday 08 October 2005 22:38, Nathanael Nerode wrote:
> > Disgustingly, I worked out that we could have revived real i386 support
> > for etch thanks to changes in gcc-3.4 and gcc-4.0 which nobody bothered
> > to advertise.  But it's too late now, since everything is built with
> > arch=i486.  :-P
> 
Frans Pop wrote:
> Do you mean that the security-flawed kernel patch would not have been 
> needed?
Yes.  Details follow:

In gcc-3.3, the C++ headers contained inline functions which contained i486 
assembly, as part of the atomic opertations implementation.  Because they 
were inline functions which manipulated arbitrary shared data, they were part 
of the ABI.

In gcc-3.4 and gcc-4.0, these functions have been replaced with out-of-line 
functions, implemented in libstdc++.  They are therefore no longer part of 
the ABI; a libstdc++ which uses the i386 versions instead is a drop-in 
replacement.  (The out-of-line implementation is probably significantly 
slower, of course, for programs which need to do a lot of atomic locking.)

However, in the wake of gcc-3.3, Debian switched to using --arch=i486 by 
default.  Although GCC doesn't generate any other i486-only instructions, 
other programs and libraries -- such as glibc -- detect this and build 
i486-specific code.  So this would have to be reverted and all affected 
libraries rebuilt before i386 support could be restored.

It would also be advisable to make sure that libstdc++ was properly 
multilibbed, so that an i386 and an i486 version are both installed, with the 
correct version chosen at runtime (vaguely like glibc-i686, though I'd 
recommend both be installed at all times) -- otherwise an even larger 
slowdown would result due to using the quite-slow i386 locking routine on 
i486s and newer.

Of course, i386-specific kernels would also have to return to the archive.

I'm not at all sure this all is worth it, but it's possible now.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

Make sure your vote will count.
http://www.verifiedvoting.org/


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

Re: Developing a kiosk type system - advice needed

[Kai Hendry]

I suggest working from Live Kiosk from: http://www.livecd.net/


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

unsuccessful unsubscribe request

[SmartList]

It has been requested that the following address:

   debian-devel@lists.debian.org

should be deleted from the debian-gcc mailing list.

Sorry, but this address has NOT been found on the list.

Please check carefully the spelling of this address.
You may send an unsubscribe request with another address.
If the address is on the list you will receive a confirmation
message. A reply to this message will remove the address.

It follows a copy of your unsubscribe request

>From [EMAIL PROTECTED]  Wed Oct 12 00:14:03 2005
>Return-Path: <[EMAIL PROTECTED]>
>X-Original-To: [EMAIL PROTECTED]
>Received: from master.debian.org (master.debian.org [146.82.138.7])
>   by murphy.debian.org (Postfix) with ESMTP id B53062EB1E
>   for <[EMAIL PROTECTED]>; Wed, 12 Oct 2005 00:14:03 -0500 (CDT)
>Received: from www-data by master.debian.org with local (Exim 3.35 1 (Debian))
>   id 1EPYwF-0004Sa-00; Wed, 12 Oct 2005 00:14:03 -0500
>From: debian-devel@lists.debian.org
>To: [EMAIL PROTECTED]
>Errors-To: [EMAIL PROTECTED]
>Reply-To: debian-devel@lists.debian.org
>Subject: unsubscribe debian-devel@lists.debian.org
>X-Remote-IP: 202.43.217.195
>Message-Id: <[EMAIL PROTECTED]>
>Sender: www-data <[EMAIL PROTECTED]>
>Date: Wed, 12 Oct 2005 00:14:03 -0500
>X-Rc-Virus: 2005-08-24_01
>
>unsubscribe debian-devel@lists.debian.org
>


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

Re: [Fwd: major problem with gnome-games dependency]

[Matthew Palmer]

On Wed, Oct 12, 2005 at 03:13:30AM +0200, Adeodato Simó wrote:
>   [CC'ing the aptitude maintainer, mainly for the last paragraph.]
> 
> * Jeroen van Wolffelaar [Tue, 11 Oct 2005 22:00:22 +0200]:
> 
> > The main things that this thread shows me, is that it is *not* immediately
> > clear to people not too familiar with Debian that the removal of the 'gnome'
> > package will not have *any* effect on what actual software is actually 
> > installed
> > on your system.
> 
>   Do not forget, though, that with aptitude becoming the prefered tool
>   for package management (over plain apt-get), this is no longer true.
>   "aptitude install gnome" will mark all of its dependencies as "auto",
>   i.e. just installed because of a dependency. Which means that
>   "aptitude remove gnome" will want to remove all the dependencies _for
>   real_, unless they have been previously marked as "noauto" by hand.

What will "aptitude remove gnome-games" do?  Remove gnome, leaving the deps
behind, or remove gnome and then remove it's deps because they're auto?

- Matt

Re: [Fwd: major problem with gnome-games dependency]

[Brian Kimball]

Ben Armstrong wrote:

> This property of metapackages has always irked me.  If I install
> gnome and then remove gnome-games, I won't automatically benefit in
> the next release from any other goodies the gnome maintainers have
> added to "gnome" package.

Amen brother.

Why aren't metapackages using Recommends instead of Depends?  It seems 
like that would solve this, at least for us aptitude users.

  brian


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

Re: [Fwd: major problem with gnome-games dependency]

[Peter Samuelson]

[Daniel Burrows]
> you'd have to do something like "aptitude keep ~Rdepends:^gnome$".

Too arcane.  (:

I've occasionally wanted a simple command in aptitude for "remove the
auto flag from all the depends of this package" - not only for
metapackages but also for dummy upgrade packages.  Another way to look
at it is a combined command for "remove this package but arrange not to
remove anything it pulled in".

This seems a bit better to me than unconditionally keeping dependencies
of removed metapackages, as Bug #328441 suggests.


signature.asc
Description: Digital signature

Re: Finding out in postinst whether some other package is configured

[Frank Küster]

Ben Armstrong <[EMAIL PROTECTED]> wrote:

> I don't know about an "established" way, but libc6.postinst looks
> interesting:
>
> # Only get the ones that are installed, and configured
> check=$(dpkg -s $check 2> /dev/null | egrep '^Package:|^Status:' | awk '{if 
> ($1 ~ /^Package:/) { package=$2 } else if ($0 ~ /^Status: .* installed$/) { 
> print package }}')

Thanks, that looks very good.  And it answers the question (or at least
gives a good indication) whether calling dpkg -s during a run of "dpkg
--install " gives a sensible output; otherwise
they'd probably know.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: major problem with gnome-games dependency

[Peter Samuelson]

[Paul E Condon]
> I suggest Debian add two metapackages: 'gnome-govt' for use by all
> governments and 'gnome-USgovt' for US government in particular. ;-)

I suppose you were joking, but in all seriousness, why does _Debian_
need to add them?  Let the site administrator do it, using 'equivs'.
If you're installing more than a few machines somewhere, sooner or
later you'll want to create one or more site metapackages anyway.


signature.asc
Description: Digital signature