Re: adding desktop files to misc packages

[Manoj Srivastava]

On Thu, 26 Jul 2007 12:49:34 +0100, Ross Burton <[EMAIL PROTECTED]> said: 

> On Thu, 2007-07-26 at 13:33 +0200, Andreas Tille wrote:
>> I was even not able to get rid of this nautilus thingy at all because
>> killing it opens a new one.  I just renamed it and killed it to get
>> rid of.

> If you don't use nautilus, why not remove the package?  If you want to
> keep the package installed but never use it, why not remove it from
> the session?

Because other users of the machine might want to? Or is Gnome
 only useful on the subset of single user machines?

manoj
-- 
A pencil with no point needs no eraser.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: adding desktop files to misc packages

[Manoj Srivastava]

On Fri, 27 Jul 2007 14:07:16 +0200, Josselin Mouette <[EMAIL PROTECTED]> said: 

> Le vendredi 27 juillet 2007 à 03:52 -0700, Steve Langasek a écrit :
>> > In the end, the people who know whether an application should be
>> > given tags that will exclude it from certain menus are the
>> > application's maintainers, not the menu systems maintainers. So far
>> > they have been reasonable about what is included in the menu, and I
>> > have no reason to think this wouldn't remain like that.
>> 
>> In that case, I guess I'm confused, because I had the impression that
>> you were still opposed to migrating the existing Debian menu to use
>> the freedesktop standard.

> Sorry, that wasn't clear: people are currently reasonable with what
> they include in the *freedesktop* menu. I'm not fond of the idea of
> converting the Debian menu entries because it will lead to including
> all that's currently in the *Debian* menu, which is not reasonable.

> If desktop entries are not generated automatically, and if there are
> clear rules on how they should be tagged, I think only a small number
> of maintainers wouldn't follow them.

Hmm.  I am not sure that the results shall be what you think
 they will be. Take for example, someone who packages something that has
 menu entries (me, for example).  Well, such people, like, evidently
 think the package enahnces the menu; and thus, if we swithc to using
 desktop format by default, I would still want to see my package on the
 menu.

So, if you want to keep you menu small and non-comprehensive,
 you should not be pushing for f.d.o formatting. :)

manoj
-- 
Weekend, where are you?
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: adding desktop files to misc packages

[Manoj Srivastava]

On Wed, 25 Jul 2007 19:22:11 +0200, Frank Küster <[EMAIL PROTECTED]> said: 

> Josselin Mouette <[EMAIL PROTECTED]> wrote:
>> As long as it is not shown, it doesn't matter, so I guess we can
>> agree on this matter.

> No, not at all.  I have not yet seen a convincing argument for hiding
> menu entries.  The only ones were "less is more", which is to vague to
> get one much further, and "we need to hide stuff like python", which
> is plain wrong IMHO because I think python shouldn't have a menu entry
> at all.

Actually, microsoft (which seems to be what GNOME folk are
 trying ever so  hard to emulate) came up with a decent solution -- they
 added shaded areas to menus to indicate that something is hidden from
 the user, and the user can just hover over the are to open up the
 hidden entries.

So, for people with a phobia of information, the "bad" extra
 information is hidden; but it is easy enough to unhide, without
 having to remember which menu one needed to go to to do so.

manoj
-- 
Goals... Plans... they're fantasies, they're part of a dream
world... Wally Shawn
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: adding desktop files to misc packages

[Ross Burton]

On Sat, 2007-07-28 at 04:39 -0500, Manoj Srivastava wrote:
> > If you don't use nautilus, why not remove the package?  If you want to
> > keep the package installed but never use it, why not remove it from
> > the session?
> 
> Because other users of the machine might want to? Or is Gnome
>  only useful on the subset of single user machines?

Session-removal is per-user.

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



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

another "just deinstall" crap: x-session-manager

[Eduard Bloch]

#include 
* Ross Burton [Thu, Jul 26 2007, 12:49:34PM]:

> > I was even not
> > able to get rid of this nautilus thingy at all because killing it opens
> > a new one.  I just renamed it and killed it to get rid of.
> 
> If you don't use nautilus, why not remove the package?  If you want to
> keep the package installed but never use it, why not remove it from the
> session?

Ha Ha Ha. This is the same stupid fallacy which exists with our
x-session-manager management in Xsession. Why is _always_ some
x-session-manager provider started (and not x-window-manager) after you
have ONLY installed installed a such monster? This situation happens
very easy, one user of many asks you to install KDE and *boom* the login
behaviour has changed for everybody.

And there is no way to get rid of it without editing stuff. When I asked
why the easy configurable option of usin a WM has to be disabled in this
situation, I got an answer like: "because if something else handles
startup it has to comply with X Session standard". No explanation of
apples-oranges situation helped the maintainer to understand.

Eduard.

-- 
 diese netzverbindung ist aber schon ne maechtig kewle sache:
frueher haben wir ueber ne schnur zwischen denk balkonen kommuniziert,
da hing ne kaffeedose mit steinen dran.
 was?
 wieviel kbyte gehen denn da drueber?
 Getty: 4 stones/minute
 da schaf ich mehr stones 
 also ne flasche bier passt nicht, da kam es zu einem
leitungszusammenbruch.
 wobei, eigentlich war das ja mehr ein verbindungsabsturz


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

ITP: randim -- Random Image Generation using Iterated Function Systems

[Gürkan Sengün]

Package: wnpp
Severity: wishlist

* Package name: randim
   Version : 0.5
   Upstream Author: Adrian Robert <[EMAIL PROTECTED]>
* URL : http://interstitiality.net/ifs_f.html
* License : GNU GPL
   Description : Random Image Generation using Iterated Function 
Systems

 This is an interactive fractal image generation program based on the
theory of iterated function systems as developed by M. F. Barnsley 
(1988).
One well-known and remarkable image generated by this method is a 
detailed
picture of a fern leaf (see, e.g., Gleick, 1987).  It is remarkable 
because
despite the amazing degree of detail present in the image -- enough to 
render
it practically indistinguishable from a silhouette of the actual 
natural shape
-- it is specified by just 4 sets of 6 numbers, each specified by one 
or two
digits only.  Roughly 80 bits of information to specify a complex 
natural
shape!  Perhaps even more amazing is the way in which these numbers 
are used

to generate the image.

For the impatient:
http://gnu.ethz.ch/debian/randim/ (not quite finished, but working)

There's already a similiar program in Debian called evolvotron if 
you're interested

in this sort of image generation...


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

Re: adding desktop files to misc packages

[Eduard Bloch]

#include 
* Florent Rougon [Thu, Jul 26 2007, 02:55:16PM]:
> Mike Hommey <[EMAIL PROTECTED]> wrote:
> 
> >> >> Witness:
> >> >>   - usable completion in the File Open dialog   -> gone
> 
> [...]
> 
> > Note that AFAIK, completion never disappeared from the file open dialogs.
> > You just have to enable it with a keystroke.
> 
> I know that; the shortcut is Ctrl-L. But I wrote "usable completion"
> because even after hitting Ctrl-L, the kind of completion you get is
> *much* less efficient than that you got for free in the good old days of
> GTK+ 1.2. IOW, there is no usable completion in GNOME's current File
> Open/Save dialogs (neither in Qt, for that matter :-/).
> 
> > Even if not, it is a problem with gimp if it refuses to set menu shortcuts
> > if you change gtk-can-change-accels in your config.
> 
> OK, it's not GNOME. But I had the impression that the original feature,
> which was accessible out-of-the-box, was removed/made inaccessible
> *because* of GNOME's concerns about "usability". That is why I brought
> this point here.

This my impression as well, the idioticy of the current file-open dialog
behaviour perfectly matches the GNOME "development". And the performance
is still flawed, the dialog (here: Iceweasel) keeps reading data of each
and every file when doing completion. For what? It has never to display
the type and icon, I wanna enter this filename manually.

I wonder what the people are smoking anyway. Few years ago, performance
of kfm in KDE 1.x sucked because it tried to read every file. Looks like
GNOME people urge to repeat their mistakes.

Eduard.
-- 
 Ich find die Domain auch scheisse, aber nem geschenkten Gaul schaut man
nicht ins Maul oder wie war das?


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

Re: adding desktop files to misc packages

[Ben Hutchings]

On Sat, 2007-07-28 at 04:47 -0500, Manoj Srivastava wrote:
> On Wed, 25 Jul 2007 19:22:11 +0200, Frank Küster <[EMAIL PROTECTED]> said: 
> 
> > Josselin Mouette <[EMAIL PROTECTED]> wrote:
> >> As long as it is not shown, it doesn't matter, so I guess we can
> >> agree on this matter.
> 
> > No, not at all.  I have not yet seen a convincing argument for hiding
> > menu entries.  The only ones were "less is more", which is to vague to
> > get one much further, and "we need to hide stuff like python", which
> > is plain wrong IMHO because I think python shouldn't have a menu entry
> > at all.
> 
> Actually, microsoft (which seems to be what GNOME folk are
>  trying ever so  hard to emulate) came up with a decent solution -- they
>  added shaded areas to menus to indicate that something is hidden from
>  the user, and the user can just hover over the are to open up the
>  hidden entries.


That's actually terrible for usability.  First, any UI feature that
involves hovering is hostile both to novices, because it's effectively
hidden, and to experienced users, because they know where they're going
and don't want to wait.  Second, users cannot learn where menu entries
are if they keep moving around.

Windows XP and later versions don't hide anything in the Programs
sub-menu but they try to duplicate the most commonly used programs
directly on the Start menu, with the option of explicitly "pinning" them
in place.  This works pretty well, though there are some difficulties in
working out which are most commonly used (see the series of articles
beginning with
).

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain. - Lily Tomlin


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

Bug#435020: ITP: p54 -- Driver for Prism54 "softmac" 802.11 wireless LAN adapters

[Sam Morris]

Package: wnpp
Severity: wishlist
Owner: Sam Morris <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

  Package name: p54
  Version : 20070728-6e46e62
  Upstream Author : Jean-Baptiste Note, NetChip Technology, Inc.,
David Brownell, Michael Wu, Christian Lamparter,
Nokia Corporation
  URL : nominally http://prism54.org/ but it's hugely out of date
  License : GPL
  Programming Lang: C
  Description : Driver for Prism54 "softmac" 802.11 (wireless LAN) adapters

- -- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (530, 'testing'), (520, 'unstable'), (510, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-1-k7 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

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

iD8DBQFGq1VHshl/216gEHgRAlrWAJsEB7RmGqJmNzn1pDwfQvN0JoT71gCdEgbZ
+IfCyY2MlBR5hqpLD2BjvmQ=
=8WkM
-END PGP SIGNATURE-


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

Re: adding desktop files to misc packages

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le vendredi 27 juillet 2007 à 03:52 -0700, Steve Langasek a écrit :
>> > In the end, the people who know whether an application should be given
>> > tags that will exclude it from certain menus are the application's
>> > maintainers, not the menu systems maintainers. So far they have been
>> > reasonable about what is included in the menu, and I have no reason to
>> > think this wouldn't remain like that.
>> 
>> In that case, I guess I'm confused, because I had the impression that you
>> were still opposed to migrating the existing Debian menu to use the
>> freedesktop standard.
>
> Sorry, that wasn't clear: people are currently reasonable with what they
> include in the *freedesktop* menu. 

Do you mean the menu as shown by desktop environments like gnome, or the
menu as specified by the set of .desktop files?  

> I'm not fond of the idea of
> converting the Debian menu entries because it will lead to including all
> that's currently in the *Debian* menu, which is not reasonable.

I still don't understand what you want:  Is it particular categories
that you want to hide, or is it the sheer number of applications, and
the fact that there are going to be multiple applications for
(approximately) the same task, that bothers you?

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le vendredi 27 juillet 2007 03:52 -0700, Steve Langasek a écrit :
>> > In the end, the people who know whether an application should be given
>> > tags that will exclude it from certain menus are the application's
>> > maintainers, not the menu systems maintainers. So far they have been
>> > reasonable about what is included in the menu, and I have no reason to
>> > think this wouldn't remain like that.
>>
>> In that case, I guess I'm confused, because I had the impression that you
>> were still opposed to migrating the existing Debian menu to use the
>> freedesktop standard.
>
> Sorry, that wasn't clear: people are currently reasonable with what they
> include in the *freedesktop* menu.

Do you mean the menu as shown by desktop environments like gnome, or the
menu as specified by the set of .desktop files?

> I'm not fond of the idea of
> converting the Debian menu entries because it will lead to including all
> that's currently in the *Debian* menu, which is not reasonable.

I still don't understand what you want:  Is it particular categories
that you want to hide, or is it the sheer number of applications, and
the fact that there are going to be multiple applications for
(approximately) the same task, that bothers you?

Regards, Frank

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Frank Küster]

Josselin Mouette <[EMAIL PROTECTED]> wrote:

> Le jeudi 26 juillet 2007 08:25 +0200, Frank Küster a écrit :
>
>> Could you give guidelines how a maintainer of an application should
>> classify their app,
>
> Using categories described in [0] is a good start. The maintainers would
> also have to agree on new categories if the ones listed are not
> sufficient.

To me, these categories look very poor, I really wouldn't want the
well-structured debian menu (note that I'm talking about the new Debian
menu, not the default menu for etch) to be replaced by anything like
this.  To me, it rather looks like it doesn't make sense to add
additional ones, given that we already have something much better.

Moreover, this doesn't answer my question at all, but I was probably
unclear.  What I meant was "How (do you think) should a maintainer
decide whether a particular application is marked as "not for Gnome", or
"not for desktop environments", or such.  I wanted something more
general than "Python should be hidden", "switching windowmanagers should
be hidden", because it's hard to discuss whether this hiding thing makes
sense when I have no idea what you think should be hidden, except some
special examples.

> On the
> contrary, NotShowIn should be used if similar functionality is available
> in one or several environments and displaying an icon would only be a
> source of confusion.

Okay, that makes sense - a frontend to setxkbmap shouldn't have a menu
entry when there's a specific tool for customizing the keyboard for the
desktop environement.

That's the type of general guideline I'd like to see, but this
particular one won't catch many applications.

> For applications that aren't useful in the general case, NoDisplay=3Dtrue
> should be set. Let me show an example: gstreamer-properties used to have
> an icon in the menu. In current releases, the appropriate sinks to use
> (esd, alsa, etc.) are autodetected which means there is no *need* for
> users to launch it, and this allowed us to set NoDisplay=3Dtrue. The same
> should hold for configuration dialogs that are specific to an
> application and already available from it.

That also makes sense, but here I would argue that those shouldn't have
a menu entry at all.

>> and how Gnome would decide which classes to hide?
>
> ConsoleOnly, Shell, Screensaver, X-WindowManager are good candidates. We
> could also exclude things like FileManager as nautilus is always
> launched, for example.=20

ACK

> Sound judgement should do the rest.

I'm sceptical about that.  Up to this discussion I didn't even have an
idea that people might want to hide things from the menu, and I still
don't feel I understand exactly what and why you want to hide.  But it's
going to be the package maintainers like me who assign these classes, so
we'd better give them some guidelines.


One guideline could be "if there's an application for doing $foo that's
provided by the desktop environment, only show this one".  Maybe that is
what you applied when you suggested to not display other file managers
besides Nautilus.

However, I don't think this is a good rule in general: If both
$gnome_wordprocessor and openoffice.org-writer are installed, I'm sure
it would confuse users if there was no menu entry for
openoffice.org-writer.  Or, nearer to my own packaging work, if someone
starts to learn LaTeX, and all they find in the menu to look at DVI
files is evince or kdvi or similar, while everyone in the LaTeX
community only talks about xdvi (and for a reason).

Regards, Frank

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: adding desktop files to misc packages

[Frank Küster]

Andreas Tille <[EMAIL PROTECTED]> wrote:

> I really wonder whether this concept of user roles are really that strange
> or stupid that all posters seem to ignore this idea.  (Feel free to teach
> me in private to keep silent with those stupid ideas.)

Personally, I think it's probably a very good idea.  Maybe I'd even like
to switch between different types of users (oh, ideally even different
users in different workspaces at the same time).

I imagine that the reason why no one responds to this suggestion is that
the discussion is very focused:  The friends of the complete Debian menu
on the one hand, and the advocates of a "newbie friendly" desktop
environment - and those newbies (I think) are generally believed to use
their computer for "home office" work, from writing a letter and web
browsing to listening to music and managing their photos.

But in fact, I think a user can both be a newbie to Linux (and even to
serious computer usage) and still have a quite focused interest, be it
"administration of a non-profit organization", a particular field of
science, game development, ...

Regards, Frank

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Bug#435020: ITP: p54 -- Driver for Prism54 "softmac" 802.11 wireless LAN adapters

[Hendrik Sattler]

Am Samstag 28 Juli 2007 16:40 schrieb Sam Morris:
> Package: wnpp
> Severity: wishlist
> Owner: Sam Morris <[EMAIL PROTECTED]>
>
>   Package name: p54
>   Version : 20070728-6e46e62
>   Upstream Author : Jean-Baptiste Note, NetChip Technology, Inc.,
> David Brownell, Michael Wu, Christian Lamparter,
>   Nokia Corporation
>   URL : nominally http://prism54.org/ but it's hugely out of
> date License : GPL
>   Programming Lang: C
>   Description : Driver for Prism54 "softmac" 802.11 (wireless LAN)
> adapters

Is that really worth it, knowing that it will probably never be in a stable 
release? There is also a p54 in wireless-dev, based on mac80211.
Maybe you have knowledge of what's going on there? Please enlighten me.

HS


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

Re: adding desktop files to misc packages

[Josselin Mouette]

Le samedi 28 juillet 2007 à 04:36 -0500, Manoj Srivastava a écrit :
> So, if you want to keep you menu small and non-comprehensive,
>  you should not be pushing for f.d.o formatting. :)

But I am not pushing it. I am trying to prevent the mess that will be if
that actually happens.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Bug#435020: ITP: p54 -- Driver for Prism54 "softmac" 802.11 wireless LAN adapters

[Sam Morris]

On Sat, 28 Jul 2007 17:15:50 +0200, Hendrik Sattler wrote:
> Is that really worth it, knowing that it will probably never be in a
> stable release? There is also a p54 in wireless-dev, based on mac80211.
> Maybe you have knowledge of what's going on there? Please enlighten me.

The wireless-dev tree's p54 driver is the one I am going to package; I 
should have made that clearer in the ITP.

The p54 driver certainly seems stable enough for regular use based on my 
own testing of it.

I think that creating this package is worthwhile if it helps _anyone_ get 
their wireless hardware working under Linux, and if it lets upstream get 
_any_ useful feedback or bug reports.

PS, please CC me in your responses as I read debian-devel though Gmane 
and may miss out on your messages. :)

-- 
Sam Morris
http://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078


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

Re: ITP: randim -- Random Image Generation using Iterated Function Systems

[Guus Sliepen]

On Sat, Jul 28, 2007 at 12:53:42PM +0200, Gürkan Sengün wrote:

> Package: wnpp
> Severity: wishlist
> 
> * Package name: randim
>Version : 0.5
>Upstream Author: Adrian Robert <[EMAIL PROTECTED]>
> * URL : http://interstitiality.net/ifs_f.html
> * License : GNU GPL
>Description : Random Image Generation using Iterated Function 
> Systems
>  This is an interactive fractal image generation program based on the
> theory of iterated function systems as developed by M. F. Barnsley 
> (1988).
> One well-known and remarkable image generated by this method is a 
> detailed picture of a fern leaf (see, e.g., Gleick, 1987).
[...blabla...]

It's interesting that IFS can generate such a remarkable image, and it
is interesting to know that it is only 4 sets of 6 numbers that produces
it, but this is not a description of randim. What does randim do and how
would you use it? Does it have a graphical user interface or is it a
command line utility? Does it output vector or bitmap graphics? Things
like that should be in the description.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Bug#435020: ITP: p54 -- Driver for Prism54 "softmac" 802.11 wireless LAN adapters

[Hendrik Sattler]

Am Samstag 28 Juli 2007 18:05 schrieb Sam Morris:
> On Sat, 28 Jul 2007 17:15:50 +0200, Hendrik Sattler wrote:
> > Is that really worth it, knowing that it will probably never be in a
> > stable release? There is also a p54 in wireless-dev, based on mac80211.
> > Maybe you have knowledge of what's going on there? Please enlighten me.
>
> The wireless-dev tree's p54 driver is the one I am going to package; I
> should have made that clearer in the ITP.
>
> The p54 driver certainly seems stable enough for regular use based on my
> own testing of it.
>
> I think that creating this package is worthwhile if it helps _anyone_ get
> their wireless hardware working under Linux, and if it lets upstream get
> _any_ useful feedback or bug reports.
>
> PS, please CC me in your responses as I read debian-devel though Gmane
> and may miss out on your messages. :)

Maybe I was irritated by the "softmac" in the description as that's also the 
name of the old stack.

HS


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

Bug#435030: ITP: pkpgcounter -- a generic Page Description Language parser

[Kumar Appaiah]

Package: wnpp
Severity: wishlist
Owner: Kumar Appaiah <[EMAIL PROTECTED]>


* Package name: pkpgcounter
  Version : 2.18
  Upstream Author : Jérôme Alet <[EMAIL PROTECTED]>
* URL : http://www.pykota.com/software/pkpgcounter
* License : GPL
  Programming Lang: Python
  Description : a generic Page Description Language parser

 pkpgcounter is a generic Page Description Language parser which can
 either count the number of pages or compute the percent of ink
 coverage needed to print various types of documents. It is written in
 Python.
 .
 It currently recognizes the following file formats :
 .
  * PostScript (both DSC compliant and binary)
  * PDF
  * PCL3/4/5
  * PCLXL (aka PCL6)
  * DVI
  * Plain text
  * TIFF
  * ESC/P2
  * OpenDocument (ISO/IEC DIS 26300)
  * Zenographics ZjStream
  * Samsung QPDL (aka SPL2)
  * Samsung SPL1
 .
 The five latter ones, as well as some TIFF documents, are currently
 only supported in page counting mode.
 .
  Homepage: http://www.pykota.com/software/pkpgcounter


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

Kernel: Linux 2.6.18-ck1 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) (ignored: LC_ALL set to 
en_US)
Shell: /bin/sh linked to /bin/bash

Role based menus [Was: adding desktop files to misc packages]

[Andreas Tille]

On Sat, 28 Jul 2007, Frank Küster wrote:


I imagine that the reason why no one responds to this suggestion is that
the discussion is very focused:  The friends of the complete Debian menu
on the one hand, and the advocates of a "newbie friendly" desktop
environment - and those newbies (I think) are generally believed to use
their computer for "home office" work, from writing a letter and web
browsing to listening to music and managing their photos.


Probably the term "newbie" has to be avoided at all - people might
be offended by that.  Roles "Office" and "Multimedia" fit better.


But in fact, I think a user can both be a newbie to Linux (and even to
serious computer usage) and still have a quite focused interest, be it
"administration of a non-profit organization", a particular field of
science, game development, ...


This is exactly what I was talking about (and why the CDD concept
exists).

Kind regards

Andreas.

--
http://fam-tille.de

Re: emacs21 removal?

[Trent W. Buck]

Tatsuya Kinoshita <[EMAIL PROTECTED]> writes:
>> There is now emacs22 in lenny/sid.  While emacs21 still exists, to
>> prefer emacs22 (or emacs), I'll submit bug reports with `Severity:
>> wishlist'.  If emacs21 is removed, the severities will be bumped up.
>
> I've submited a wishlist Bug #434978 to lintian to add a new check.
> [...]
> Trent Buck <[EMAIL PROTECTED]>
>paredit-el
> [...]

Done at 


http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=paredit-el
http://mentors.debian.net/debian/pool/main/p/paredit-el

I'm not a DD, so a sponsor is needed to push this change to Debian
proper.
-- 
Trent W. Buck


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

stupid dependencies on update-inetd

[Marco d'Itri]

I don't know exactly how it happened, but a large number of maintainers
apparently ignored the discussions on this list and added to their
packages a dependency on update-inetd.
This is *TOTALLY WRONG* because the /usr/sbin/update-inetd interface is
guaranteed to be provided by whatever implements the inet-superserver
virtual package and not by the update-inetd package currently depended
on by some inetd packages.
Indeed, the update-inetd package does not depend on a daemon package nor
it provides one itself.

Some of these packages instead are only slightly less broken and depend
both on inet-superserver and update-inetd, making impossible to install
a future xinetd package providing its own /usr/sbin/update-inetd.

For the same reason the dependency on netbase must be removed,
especially now that it does not depend anymore on inet-superserver.
(I know that in theory I should have waited for all packages to be fixed
before removing the dependency, but realistically this would not have
happened before lenny or lenny+1...)


grep-dctrl -s Package,Depends --field=Depends update-inetd \
  --and --not --field=Provides inet-superserver /var/lib/dpkg/available

Richard A Nelson (Rick) <[EMAIL PROTECTED]>
   sendmail

Masayuki Hatta (mhatta) <[EMAIL PROTECTED]>
   ebnetd

Jari Aalto <[EMAIL PROTECTED]>
   micro-httpd

Russ Allbery <[EMAIL PROTECTED]>
   kftgt
   remctl
   sident

Chris Butler <[EMAIL PROTECTED]>
   wu-ftpd

Debian CUPS Maintainers <[EMAIL PROTECTED]>
   cupsys

Debian Qt/KDE Maintainers <[EMAIL PROTECTED]>
   kdenetwork

Debian Samba Maintainers <[EMAIL PROTECTED]>
   samba

Ludovic Drolez <[EMAIL PROTECTED]>
   atftp

Turbo Fredriksson <[EMAIL PROTECTED]>
   midentd

Debian QA Group <[EMAIL PROTECTED]>
   ffingerd

Sam Hartman <[EMAIL PROTECTED]>
   krb5

Michael Holzt <[EMAIL PROTECTED]>
   gwhois

John H. Robinson, IV <[EMAIL PROTECTED]>
   nullidentd

Alberto Gonzalez Iniesta <[EMAIL PROTECTED]>
   linux-ftpd

LTSP Debian/Ubuntu Maintainers <[EMAIL PROTECTED]>
   ltsp

Martin Loschwitz <[EMAIL PROTECTED]>
   gidentd

Francesco Paolo Lovergine <[EMAIL PROTECTED]>
   proftpd-dfsg

Robert Luberda <[EMAIL PROTECTED]>
   solid-pop3d

Rene Mayorga <[EMAIL PROTECTED]>
   afbackup

Steve McIntyre <[EMAIL PROTECTED]>
   cvs

Pedro Zorzenon Neto <[EMAIL PROTECTED]>
   fakepop

Anibal Monsalve Salazar <[EMAIL PROTECTED]>
   bootp
   bsd-finger
   pidentd

Steve McIntyre <[EMAIL PROTECTED]>
   cvs

Pedro Zorzenon Neto <[EMAIL PROTECTED]>
   fakepop

Anibal Monsalve Salazar <[EMAIL PROTECTED]>
   bootp
   bsd-finger
   pidentd

Martin Schulze <[EMAIL PROTECTED]>
   sendfile

Jonas Smedegaard <[EMAIL PROTECTED]>
   uw-imap

paul cannon <[EMAIL PROTECTED]>
   hotway

-- 
ciao,
Marco


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

Re: stupid dependencies on update-inetd

[Russ Allbery]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> I don't know exactly how it happened, but a large number of maintainers
> apparently ignored the discussions on this list and added to their
> packages a dependency on update-inetd.

> This is *TOTALLY WRONG* because the /usr/sbin/update-inetd interface is
> guaranteed to be provided by whatever implements the inet-superserver
> virtual package and not by the update-inetd package currently depended
> on by some inetd packages.

> Indeed, the update-inetd package does not depend on a daemon package nor
> it provides one itself.

So what are they *supposed* to depend on, only inet-superserver?  I'm
failing to extract a clear guideline from half-remembered debian-devel
discussions (as is clear from the fact that I apparently got the lintian
check wrong).  Is this documented somewhere that anyone could expect to
find it?

Currently, lintian allows any combination of dependencies on the following
packages to satisfy the dependency requirement from calling update-inetd
in maintainer scripts:

update-inetd inet-superserver openbsd-inetd rlinetd

I gather update-inetd should be removed from that list.  Is it otherwise
correct?

> Some of these packages instead are only slightly less broken and depend
> both on inet-superserver and update-inetd, making impossible to install
> a future xinetd package providing its own /usr/sbin/update-inetd.

Should no package ever depend on update-inetd unless it also provides
inet-superserver?  If so, I can add a lintian check for that.  If not, is
there something else that lintian can check for?

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: stupid dependencies on update-inetd

[Mark Brown]

On Sun, Jul 29, 2007 at 12:57:03AM +0200, Marco d'Itri wrote:
> I don't know exactly how it happened, but a large number of maintainers
> apparently ignored the discussions on this list and added to their
> packages a dependency on update-inetd.
> This is *TOTALLY WRONG* because the /usr/sbin/update-inetd interface is
> guaranteed to be provided by whatever implements the inet-superserver
> virtual package and not by the update-inetd package currently depended
> on by some inetd packages.
> Indeed, the update-inetd package does not depend on a daemon package nor
> it provides one itself.

It might be helpful if you could summarise what packages are supposed to
be doing here - this may even affect enough packages to warrant a mail
to debian-devel-announce.  I don't recall ever seeing an announcement
about this and I imagine that even among those maintainers who read this
list there will be some who have only scanned the threads about inetd
since they tend to get a bit bogged down in the details.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Re: update-inetd don't update xinetd.conf

[Marco d'Itri]

On Jul 24, Magnus Holmgren <[EMAIL PROTECTED]> wrote:

> Anyway, you have proposed that all superserver packages provide their own 
> update-inetd implementation, which is fine and simple enough, except that 
> it's not clear how the configuration would be transferred when one 
> superserver is replaced by another. There needs to be some common data 
update-inetd would update its own little database when called by
postinst.
It's not a beautiful design, but it allows users to modify
/etc/inetd.conf and maintainers to not modify their own packages.

On Jul 23, Pierre Habouzit <[EMAIL PROTECTED]> wrote:

>   IMHO the problem is easy to solve, I'd go this way: Have a registry in
> /etc/ with a simple syntax (like ini-style), that would be a superset of
> all the features in all supported superservers.  Local administrators
> would have to edit those files to make their local changes.
This is what makes it unacceptable.

>   The downside of this proposal is that every package using a super
> server would have to be updated, but OTOH that is not a big number of
> packages:
> 
>   $ grep-dctrl -s Package -FDepends netkit-inetd -o -FDepends 
> inet-superserver -o -FDepends update-inetd \
>   /var/lib/apt/lists/mad_debian_dists_sid_main_binary-amd64_Packages | wc 
> -l
>   51
This lists only a small part of them, most ones still depend only on
netbase.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: stupid dependencies on update-inetd

[Marco d'Itri]

On Jul 29, Russ Allbery <[EMAIL PROTECTED]> wrote:

> So what are they *supposed* to depend on, only inet-superserver?  I'm
Yes. Actually "openbsd-inetd | inet-superserver", since it is a virtual
package.

> failing to extract a clear guideline from half-remembered debian-devel
> discussions (as is clear from the fact that I apparently got the lintian
> check wrong).  Is this documented somewhere that anyone could expect to
> find it?
Probably not, but in this case common sense would have been enough since
update-inetd does not depend on anything else.

> Currently, lintian allows any combination of dependencies on the following
> packages to satisfy the dependency requirement from calling update-inetd
> in maintainer scripts:
> 
> update-inetd inet-superserver openbsd-inetd rlinetd
> 
> I gather update-inetd should be removed from that list.  Is it otherwise
> correct?
openbsd-inetd and rlinetd should be removed too since they provide
inet-superserver (unless they are provided as alternatives to the
virtual package).

> > Some of these packages instead are only slightly less broken and depend
> > both on inet-superserver and update-inetd, making impossible to install
> > a future xinetd package providing its own /usr/sbin/update-inetd.
> Should no package ever depend on update-inetd unless it also provides
> inet-superserver?  If so, I can add a lintian check for that.
Correct.

> If not, is
> there something else that lintian can check for?
Dependencies on netbase are almost always wrong too.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: stupid dependencies on update-inetd

[Russ Allbery]

[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Jul 29, Russ Allbery <[EMAIL PROTECTED]> wrote:

>> Currently, lintian allows any combination of dependencies on the
>> following packages to satisfy the dependency requirement from calling
>> update-inetd in maintainer scripts:
>> 
>> update-inetd inet-superserver openbsd-inetd rlinetd
>> 
>> I gather update-inetd should be removed from that list.  Is it
>> otherwise correct?

> openbsd-inetd and rlinetd should be removed too since they provide
> inet-superserver (unless they are provided as alternatives to the
> virtual package).

So is anything ever valid other than openbsd-inetd | inet-superserver as a
dependency?  I keep getting confused on the rules around using virtual
packages.  Would rlinetd | inet-superserver be okay?  Would
inet-superserver all by itself be okay?

>> Should no package ever depend on update-inetd unless it also provides
>> inet-superserver?  If so, I can add a lintian check for that.

> Correct.

Okay, I'll look at doing that.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Bug#435058: ITP: smolt -- Fedora hardware profiler

[Ricky Zhou]

Package: wnpp
Severity: wishlist
Owner: Ricky Zhou <[EMAIL PROTECTED]>


* Package name: smolt
  Version : 0.9.8.3
  Upstream Author : Mike McGrath <[EMAIL PROTECTED]>
* URL : https://hosted.fedoraproject.org/projects/smolt/
* License : GPL
  Programming Lang: Python
  Description : Fedora hardware profiler

The Fedora hardware profiler is a server-client system that does a
hardware scan against a machine and sends the results to a public Fedora
Project turbogears server.  The sends are anonymous and should not
contain any private information other than the physical hardware
information and basic OS info.

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

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


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

Re: stupid dependencies on update-inetd

[Marco d'Itri]

On Jul 29, Russ Allbery <[EMAIL PROTECTED]> wrote:

> So is anything ever valid other than openbsd-inetd | inet-superserver as a
> dependency?  I keep getting confused on the rules around using virtual
> packages.  Would rlinetd | inet-superserver be okay?  Would
Formally yes, but I do not think there is a reason for a package to
choose a different default.

> inet-superserver all by itself be okay?
No, but this would be taken care of by
virtual-package-depends-without-real-package-depends (which explains
the part you are missing).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Non-security updates between stable releases?

[Tim Hull]

Hi,

I must say I hope no one takes this the wrong way or flames me because of it
- I really appreciate what Debian has done, and I think you have the most
stable, logically laid out, and free (as in freedom) Linux distribution out
there.

That said, there is a significant issue that I see with Debian and most
distributions in general that I wanted to bring up.  The issue is that once
a stable release is declared stable, that's it - there are no updates except
for security holes.  This is good, except when you need a feature included
in a newer version of software included in Debian (for example, if a newer
kernel has a non-security bugfix in it that you need). Yes, you can compile
from source (or, in some cases, use unofficial packages) but that is far
from ideal.
What I am wondering is - has there been any effort and/or interest in
working on this area?  I know about debian-volitaile, but that seems
oriented towards a very specific set of packages (like antivirus programs),
and not, for example, bugfixes.  Furthermore, has there been any interest in
working on such a project? If there is some interest, I would be interested
in helping with the effort (though IANADD).   I do vaguely remember this
being mentioned at some time somewhere by a Debian developer at some point
in time, so I figured I'd bring it up.

In my mind, many of the complaints that "Debian doesn't release often
enough" could be mitigated this way, and it would be nice to see at some
point.

Once again, thanks for making Debian what it is - I'm amazed by the 21,000+
packages, the beauty of apt, and the fact that it's a completely volunteer
effort.  Keep it up.

Tim

Re: Non-security updates between stable releases?

[Russ Allbery]

"Tim Hull" <[EMAIL PROTECTED]> writes:

> That said, there is a significant issue that I see with Debian and most
> distributions in general that I wanted to bring up.  The issue is that
> once a stable release is declared stable, that's it - there are no
> updates except for security holes.  This is good, except when you need a
> feature included in a newer version of software included in Debian (for
> example, if a newer kernel has a non-security bugfix in it that you
> need). Yes, you can compile from source (or, in some cases, use
> unofficial packages) but that is far from ideal.

> What I am wondering is - has there been any effort and/or interest in
> working on this area?  I know about debian-volitaile, but that seems
> oriented towards a very specific set of packages (like antivirus
> programs), and not, for example, bugfixes.

Are you aware of backports.org?  I use it extensively for cherry-picking
specific packages where I need a newer version for feature reasons while
keeping the rest of the system running stable.  That means there's only a
few packages I have to pay special attention to for security
vulnerabilities.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Non-security updates between stable releases?

[Tim Hull]

>
>
> Are you aware of backports.org?  I use it extensively for cherry-picking
> specific packages where I need a newer version for feature reasons while
> keeping the rest of the system running stable.  That means there's only a
> few packages I have to pay special attention to for security
> vulnerabilities.



I knew about that, though it's not actually an official Debian repository
(to my knowledge).It is missing a few things I need, though.  I may look in
to contributing over there, and it would be nice to see it as an official
part of the Debian project, as well as possibly some "point releases"
including backports.

Thanks for the quick response, though...

Re: Non-security updates between stable releases?

[Russ Allbery]

"Tim Hull" <[EMAIL PROTECTED]> writes:

> I knew about that, though it's not actually an official Debian
> repository (to my knowledge).It is missing a few things I need, though.
> I may look in to contributing over there, and it would be nice to see it
> as an official part of the Debian project, as well as possibly some
> "point releases" including backports.

I agree on wanting to see it as an official part of the project, just for
branding purposes if nothing else.  I think a lot of Debian users miss it
or don't think they can trust it just because it's not .debian.org and
therefore they can't make the same assumptions about how it's run
(although in practice if they knew how it's set up, they probably could).

I'm not at all sure on making it a point release; I think it works fairly
well as is, and I'd rather put the scarce release resources into
increasing at least the predictability and possibly the speed of
full-blown stable releases from testing.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: stupid dependencies on update-inetd

[Christian Perrier]

> It might be helpful if you could summarise what packages are supposed to
> be doing here - this may even affect enough packages to warrant a mail
> to debian-devel-announce.  I don't recall ever seeing an announcement
> about this and I imagine that even among those maintainers who read this
> list there will be some who have only scanned the threads about inetd
> since they tend to get a bit bogged down in the details.


It would even be more helpful if this could be summarized *and* filed
as bugs with a clear suggestion of what should be done. I'm maybe a
little bit not awaken enough but I fail to understand what we are
supposed to do (I'm concerned as one of the samba package
maintainersfor which the relevant change was made by one of my
estimated co-maintainers, who I usually blindly trust).

It would probably be more helpful than calling us stupid, indirectly
(cf "Subject").





signature.asc
Description: Digital signature

Re: stupid dependencies on update-inetd

[Steve Langasek]

On Sun, Jul 29, 2007 at 12:57:03AM +0200, Marco d'Itri wrote:
> I don't know exactly how it happened, but a large number of maintainers
> apparently ignored the discussions on this list and added to their
> packages a dependency on update-inetd.
> This is *TOTALLY WRONG* because the /usr/sbin/update-inetd interface is
> guaranteed to be provided by whatever implements the inet-superserver
> virtual package and not by the update-inetd package currently depended
> on by some inetd packages.
> Indeed, the update-inetd package does not depend on a daemon package nor
> it provides one itself.

> Some of these packages instead are only slightly less broken and depend
> both on inet-superserver and update-inetd, making impossible to install
> a future xinetd package providing its own /usr/sbin/update-inetd.

> For the same reason the dependency on netbase must be removed,
> especially now that it does not depend anymore on inet-superserver.
> (I know that in theory I should have waited for all packages to be fixed
> before removing the dependency, but realistically this would not have
> happened before lenny or lenny+1...)

The rationale for samba depending on update-inetd was that samba does *not*
depend on the availability of an inet superserver; it only depends on the
availability of the update-inetd interface, in order for its maintainer
scripts to run correctly.

The relationship with inet-superserver is therefore of a 'suggests' nature,
but the relationship with the update-inetd interface is a hard dependency.

I understand that the swat package doesn't have this excuse, since it does
depend on inet-superserver also.  That, I can only attribute to my own poor
memory for the previous discussion and -- as previously mentioned -- the
lack of prominent documentation.

But I would still like input on the use of this dependency for samba; I
rather expect we would get complaints if samba depended on inet-superserver
when it doesn't use it in the default configuration.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: stupid dependencies on update-inetd

[Russ Allbery]

Steve Langasek <[EMAIL PROTECTED]> writes:

> The rationale for samba depending on update-inetd was that samba does
> *not* depend on the availability of an inet superserver; it only depends
> on the availability of the update-inetd interface, in order for its
> maintainer scripts to run correctly.

> The relationship with inet-superserver is therefore of a 'suggests'
> nature, but the relationship with the update-inetd interface is a hard
> dependency.

Yeah, remctl-server is in a similar situation.  remctld can either run via
inetd or as a stand-alone daemon.  The Debian package ships inetd
configuration via maintainer scripts, since that's what I expect most
users will want, but the relationship to inet-superserver is really more
of a Recommends than a Depends.

I may do something like:

Depends: update-inetd | inet-superserver
Recommends: inet-superserver

for it, I guess, but that seems very strange too.

Couldn't any inet-superserver package that provides its own update-inetd
also Provide: update-inetd?  Wouldn't that fix the problem?  It has to
Conflict with update-inetd anyway.

I have no idea how to write this as a lintian check, though, and still
catch the cases that Marco is complaining about.  (I'm pretty sure the
long description of the current lintian tag is wrong, though, and I've
probably contributed to the problem because of that.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Bug#435058: ITP: smolt -- Fedora hardware profiler

[Mike Hommey]

On Sat, Jul 28, 2007 at 09:28:46PM -0400, Ricky Zhou <[EMAIL PROTECTED]> wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Ricky Zhou <[EMAIL PROTECTED]>
> 
> 
> * Package name: smolt
>   Version : 0.9.8.3
>   Upstream Author : Mike McGrath <[EMAIL PROTECTED]>
> * URL : https://hosted.fedoraproject.org/projects/smolt/
> * License : GPL
>   Programming Lang: Python
>   Description : Fedora hardware profiler
> 
> The Fedora hardware profiler is a server-client system that does a
> hardware scan against a machine and sends the results to a public Fedora
> Project turbogears server.  The sends are anonymous and should not
> contain any private information other than the physical hardware
> information and basic OS info.

What is the added value for Debian users of sending these informations
*to Fedora* ?

Mike


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