Re: On maintainers not responding to bugs

2007-03-07 Thread Matthias Julius
Roland Mas <[EMAIL PROTECTED]> writes:

> Matthias Julius, 2007-03-07 11:32:32 -0500 :
>
>> It's a matter of how someone arrives at the point where he wants to
>> help.  If he wakes up one morning and thinks "I want to help the KDE
>> team" he will probably contact the KDE maintainers.  If he thinks
>> "Since 3 years I am using Debian it's time for me to contribute." he
>> might look in more generic places to find out who requests help.
>
> In that case, I suppose http://www.debian.org/intro/help should be
> made a bit more helpful.  More visible, more readable, and so on.  I
> understand one of the DPL candidates intends to work (or get people to
> work) on the Debian website; I suggest this page could be considered
> during that endeavour.

I don't consider it to be too bad.  But it would be a good step
forward if it contained a reference to the RFH list.

Matthias


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



Re: On maintainers not responding to bugs

2007-03-07 Thread Kevin Mark
On Thu, Mar 08, 2007 at 12:37:39AM +0100, Pierre Habouzit wrote:
> On Wed, Mar 07, 2007 at 03:28:45PM +0100, cobaco (aka Bart Cornelis) wrote:
> > So maybe asking for help on debian-kde, where there's people around who 
> > might be convinced to pitch in a little time and effort once or twice would 
> > be more productive. I'm thinking something along the lines of:
> 
>   yadayadayada
> 
>   just consider mailing debian-kde _HAS FG BEEN DONE ALREADY_ and
> I'm tired giving the link again and again, ON THE KDE USER LIST where
> it's the most probable place to find users caring about KDE rignt ? I
> recall for the other here that debian-kde is a user list, the maintainer
> one is debian-qt-kde. The damn mail is here:
> 
>   http://lists.debian.org/debian-kde/2006/01/msg00215.html
> 
>   it gave 0 DAMN USER WNATED TO HELP.

From my perspective, it shows that the intended audience did not read
that list or that particular mail or subscribed after it was sent...
Also, how often do you view advertisements on TV for say food, movies or
other items? Once? no, often! Why? Advertising is something that has to
be done as an on going process to get maximum results. Getting your
message to its intended target is a hard thing. How about having 'text
ads' on the pages of the Debian site that showcase a 'request for help'
or similar?
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal |mysite.verizon.net/kevin.mark/|
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
|  my keyserver: subkeys.pgp.net | my NPO: cfsg.org |


signature.asc
Description: Digital signature


Re: On maintainers not responding to bugs

2007-03-07 Thread Pierre Habouzit
On Wed, Mar 07, 2007 at 03:28:45PM +0100, cobaco (aka Bart Cornelis) wrote:
> So maybe asking for help on debian-kde, where there's people around who 
> might be convinced to pitch in a little time and effort once or twice would 
> be more productive. I'm thinking something along the lines of:

  yadayadayada

  just consider mailing debian-kde _HAS FG BEEN DONE ALREADY_ and
I'm tired giving the link again and again, ON THE KDE USER LIST where
it's the most probable place to find users caring about KDE rignt ? I
recall for the other here that debian-kde is a user list, the maintainer
one is debian-qt-kde. The damn mail is here:

  http://lists.debian.org/debian-kde/2006/01/msg00215.html

  it gave 0 DAMN USER WNATED TO HELP.

  IS IT CLEAR ENOUGH OR SHOULD I USE SOM ASCII-CAPS-LOCK-TOILET-POWERED
MAIL ?

> > So Yes I wonder if it's not that it's just easier to pretend it's our
> > fault
> 
> Nobody is saying anybody is at fault, which doesn't mean there's no room for 
> improvement.

  This was answering to:

] ] > >   Again, I do not appreciate the latent criticism of the big teams
] ] > >   to
] ] > > hide their understaff problem. It's blatantly bogus hence iritating,
] ] > > almost insulting.
] ] >
] ] > Don't you wonder why it is perceived like that?

  Which do seem like a quite not very hidden accusation, so yes, somebody
is playing finger-pointing games here, and I'm tired of it.


-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpBs6tWWvcmz.pgp
Description: PGP signature


Re: VMware Player packages

2007-03-07 Thread Marc Haber
On Wed, Mar 07, 2007 at 06:46:18PM +0100, Hans Kratz wrote:
> Sure. I wasn't aware of that package. AFAICS that package handles only
> the VMware kernel modules right now.

No, it can build vmware-player .debs as well. I'll fix the wrong
description in svn.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


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



Re: VMware Player packages

2007-03-07 Thread Hans Kratz

Hi!


 HK> After repeatedly seeing interest in VMware Player packages for
 HK> Debian I decided to post my work on packaging VMware Player. It
 HK> should work fine on sarge and sid. Currently only i386 is
 HK> supported, support for x86-64 is on my TODO list.


That was supposed to read *etch* and sid. Just that nobody gets the
wrong idea... ;-)


You'd probably like to join efforts with Marc Haber who maintains
vmware-package package in experimental :)


Sure. I wasn't aware of that package. AFAICS that package handles only
the VMware kernel modules right now. It could probably merged with the
VMware Player parts of my package. I am not sure though that the
vmware-any-any patch it is based upon buys us anything at least for
the modules shipped with VMware Player. The VMware Player modules as
packaged by me seem to work just fine with the stock 2.6.18 kernels of
etch/sid.


Best regards,


Hans


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



Re: On maintainers not responding to bugs

2007-03-07 Thread Roland Mas
Matthias Julius, 2007-03-07 11:32:32 -0500 :

> It's a matter of how someone arrives at the point where he wants to
> help.  If he wakes up one morning and thinks "I want to help the KDE
> team" he will probably contact the KDE maintainers.  If he thinks
> "Since 3 years I am using Debian it's time for me to contribute." he
> might look in more generic places to find out who requests help.

In that case, I suppose http://www.debian.org/intro/help should be
made a bit more helpful.  More visible, more readable, and so on.  I
understand one of the DPL candidates intends to work (or get people to
work) on the Debian website; I suggest this page could be considered
during that endeavour.

Roland.
-- 
Roland Mas

With the arrest of Dimitry Sklyarov it has become apparent that it is not
safe for non US software engineers to visit the United States. - Alan Cox


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



Re: racoon and bug 372665

2007-03-07 Thread Milan P. Stanic
On Wed, Mar 07, 2007 at 07:17:00AM +0530, Ganesan Rajagopal wrote:
> > "Milan" == Milan P Stanic <[EMAIL PROTECTED]> writes:
> > I don't think so (except maybe udev, but servers can happily work without
> > udev). What is the reason to start nfs from "one time initialization"
> > subsystem? Portmap and nfs can be started in runlevel 2 to 5.
> 
> That's debatable. However current Debian policy as per /etc/rcS.d/README is 
> 
> =
> The following sequence points are defined at this time:
> 
> * After the S40 scripts have executed, all local file systems are mounted
>   and networking is available. All device drivers have been initialized.
> 
> * After the S60 scripts have executed, the system clock has been set, NFS
>   filesystems have been mounted (unless the system depends on the automounter,
>   which is started later) and the filesystems have been cleaned.
> =

Yes, it is true. But is also says that:
=
The scripts in this directory whose names begin with an 'S' are executed
once when booting the system, even when booting directly into single
user mode.
=

Look at "are executed once". Daemons could be executed once when booting
the system but also could be stopped, started and restarted during normal
server (or workstation) operation.

> Besides NFS, if your entire access to the network requires IPsec, you cannot
> even ssh outside the box unless racoon sets up a tunnel. It's really a
> critical service in that sense.

So could be other VPN subsystems (OpenVPN, VPNC, SSH etc).

I would think that mountnfs.sh should be moved somewhere else
(/etc/rc{2-5}.d/) where portmap have symlinks already. If we mount
remote filesystems so early why samba is not started from /etc/rcS.d/ ?

Policy is ambiguous (at least) here, IMO.


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



Account Refill

2007-03-07 Thread Carmella Boehm
Friendly Reminder; Get your desired products still on sale up to 80 Percent off.

Point your browser towards this website www.ropina . com to ensure that your 
orders have been discounted.

Removal Reminder also processed from the above website.

Regards,
Dr.O'Connell



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



Re: On maintainers not responding to bugs

2007-03-07 Thread Matthias Julius
Pierre Habouzit <[EMAIL PROTECTED]> writes:

> On Tue, Mar 06, 2007 at 12:49:56PM -0500, Matthias Julius wrote:
>> Pierre Habouzit <[EMAIL PROTECTED]> writes:
>>
>> Do you expect potential helpers to search various list archives or
>> mail maintainers to ask whether they need help?  I would guess only
>
>   no I expect them to contact the teams, and entry points are obvious.
> Hiding behind the fact that entry points are not waved under their nose
> and that because of that they can't help is, well, Ubuesque.

It's a matter of how someone arrives at the point where he wants to
help.  If he wakes up one morning and thinks "I want to help the KDE
team" he will probably contact the KDE maintainers.  If he thinks
"Since 3 years I am using Debian it's time for me to contribute." he
might look in more generic places to find out who requests help.

>> 
>> What does it hurt to file a RFH bug?  At least it is a centralized
>> platform where potential helpers can find out about who need help.
>> And it is a logical place for that.  And the list is posted weekly on
>> -devel.
>
>   because that's not one, but 1500, and that would not be very useful to
> flood RFH that are often specific needs for technicals matters. Here
> it's manpower missing, RFH seems inapropriate to me.

Does a RFH need to be that specific?  I think those 0-day NMU mails
from last week might be well suited for RFH.  I think it is beneficial
if the help request is permanently visible compared to being burried
in some list archive.

If you wanted to request help for a specific bug you would tag it
'help'.  Am I correct?

>
>> >   Again, I do not appreciate the latent criticism of the big teams to
>> > hide their understaff problem. It's blatantly bogus hence iritating,
>> > almost insulting.
>>
>> Don't you wonder why it is perceived like that?
>
>   Yes I do, especially given that in that thread those teams have
> claimed many times they need help, and that people continue to pretend
> like it never happened. So Yes I wonder if it's not that it's just
> easier to pretend it's our fault, than to question onself "wtf didn't I
> helped before already ?"

Well, of course, it is always easier to blame everybody else.  I just
think an argument like "We have a RFH out since one year and nobody
cared." will work better for you than "We sent a request to -kde a year
ago and nobody responded."


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



Re: On maintainers not responding to bugs

2007-03-07 Thread Andrei Popescu
"cobaco (aka Bart Cornelis)" <[EMAIL PROTECTED]> wrote:

[snip]

> So maybe asking for help on debian-kde, where there's people around
> who might be convinced to pitch in a little time and effort once or
> twice would be more productive. I'm thinking something along the
> lines of:

This might have even bigger impact on debian-user.

Regards,
Andrei
-- 
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)


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



Bug#413857: ITP: isomaster -- A graphical ISO image editor

2007-03-07 Thread David Johnson
Package: wnpp
Severity: wishlist
Owner: David Johnson <[EMAIL PROTECTED]>


* Package name: isomaster
  Version : 0.8
  Upstream Author : Andrew Smith <[EMAIL PROTECTED]>
* URL : http://littlesvr.ca/isomaster/
* License : GPL
  Programming Lang: C
  Description : A graphical ISO image editor

ISO Master is a GTK-based graphical CD image editor for reading, writing and
modifying ISO images.

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)


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



Re: Maintainers

2007-03-07 Thread Howard Young

Thanks to the people in the library at the college I attended.
I believe this is the same as or very similar to the one I used:

Title: Information technology: GNVQ Advanced
Names: Knott, Geoffrey  (Author); Waites, Nick  (Author)
Publisher: Business Education Publications
Date: 1997
ISBN: 1901888010

or else mine was similar to:

Title: GNVQ Advanced information technology
Names: Hodson, Peter(Editor)
Date: 1995
Publisher: DP Publications
ISBN: 1858051118

or

Title: GNVQ Advanced Information Technology
Names: Doyle, Stephen   (Author)
Publisher: Stanley Thornes
Date: 1997
ISBN: 0748728902


I will try to locate a a copy of the first one in order to find out what 
the book was based on.


Howard


Jon Stearn wrote:

Hi Howard

This is an outstanding idea - i'd be very happy to work with you on
pushing it forward. I have long experience with linux and in delivering
training and producing course materials. Do uyou have a copy of the
material that you used? Or a book title or ISBN that you could give me?

cheers

Jon

On Mon, Mar 05, 2007 at 06:29:49PM +, Howard Young wrote:
  
See the email I sent after wards. It has the same subject (and sorry, it 
is quite long).


In short I suppose the material answer to your question would be:
A set of books and for quick sale of the proposal possibly having a few 
people run localized linux terminal servers that allow colleges to have 
dumb terminals and no need to reinstall network with Linux or install 
servers if they just want to try one term.


In England courses often funded by being run to comply with certain 
criteria i.e. SHOWS THE USER HOW TO OPERATE A MOUSE and so on (but less 
specific).


If the book and software covers the criteria I suspect it would be 
possible to have it approved so that the government give whatever 
approval they can to the book. This is speculation of course as I am not 
sure if the present books are 'approved'?


After reading the other email does this make sense?
If the books are GPL then people will be able to study for the 
qualification by downloading a PDF.
As the course is in UNITS it is not really necessary for someone to 
write an entire book. Individuals can conform to a standard based on the 
aforementioned criteria and government accessibility requirements...



Greg Folkert wrote:


On Mon, 2007-03-05 at 10:33 +, Howard Young wrote:
 
  
I know of a way that maintainers could be increased substantially (I 
expect hundreds to many thousands a year).
I am not sure of the specifics but I have little doubt that in the end 
it would work.
It will likely take more than four years to implement and only work in 
England.
   


Exactly what are you proposing?
 
  

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



  



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



Re: On maintainers not responding to bugs

2007-03-07 Thread cobaco (aka Bart Cornelis)
On Wednesday 07 March 2007, Pierre Habouzit wrote:
> On Tue, Mar 06, 2007 at 12:49:56PM -0500, Matthias Julius wrote:
> > Pierre Habouzit <[EMAIL PROTECTED]> writes:
> > >   Like every packaging team in debian, mailing the [EMAIL PROTECTED]
> > > or [EMAIL PROTECTED] depending on how old the team is. Usually that
> > > list is in the Maintainer or Uploaders field of the control file.
> > > #debian-$team is also a good place to look. Those things are
> > > _obvious_.
> >
> > Do you expect potential helpers to search various list archives or
> > mail maintainers to ask whether they need help?  I would guess only
>
>   no I expect them to contact the teams, and entry points are obvious.
> Hiding behind the fact that entry points are not waved under their nose
> and that because of that they can't help is, well, Ubuesque.

You're missing a couple of points here:
1) That only gets you the help of those that are actively seeking to get
   involved (and that's a small minority of potential helpers)
2) Those actively seeking to get involved with Debian will tend to look jump
   in in areas that both interest them AND obviously need help (or at least
   they'll jump in there first.

To give an anecdotal example:

I first got actively involved with Debian, because I saw a message asking 
for translations of the debian-edu install questions, that stated a 
translation would only take 10-15 minutes. I figured "I can do that", and 
got more and more involved from there (and I wasn't the only one to help 
out in reaction to that mail)

From what I've observed that's a quite common patern

-> asking for help, and taking care where and how to ask, can make a huge
   difference in the amount of help you receive.

> > >   Again, I do not appreciate the latent criticism of the big teams to
> > > hide their understaff problem. It's blatantly bogus hence iritating,
> > > almost insulting.
> >
> > Don't you wonder why it is perceived like that?
>
>   Yes I do, especially given that in that thread those teams have
> claimed many times they need help, and that people continue to pretend
> like it never happened.

There's been a couple of blogs about the fact that in response to this 
thread somebody jumped in and started working on antiquated KDE-bugs.

-> seems like asking for help had some effect in this case doesn't it?

Secondly debian-devel is probably not the best forum for getting help with 
triaging old bugs why not? Because most people on the list are already 
heavily involved with Debian, and busy working on their own little 
problems.

So maybe asking for help on debian-kde, where there's people around who 
might be convinced to pitch in a little time and effort once or twice would 
be more productive. I'm thinking something along the lines of:

  Subject: Adopt a bug community drive

  Hi all, greetings from the KDE-team

  First for the good news: we're currently managing to keep up with new
  bugs and quality of the KDE packages is good and improving :)
  
  However we have a lot of old antiquated bugs on kdebase that pre-date the 
  formation of the kde-team, and we need your help to clean those up.

  We'd like each of you to pick out just 1 old bug and help update the
  information in it (you're of course welcome to do more then 1 :). 
  Mostly this is a question of doing what people on this list are always
  doing, namely aks the submitter for the necessary information to get at
  the cause of the bug, and checking if the bug has been reported in the KDE 
  bugzilla, and so on.

  To make helping even easier here is a step by step instruction on cleaning
  up old bugs in the Debian BTS:
  1) point your browser to the list of kdebase bugs at [1] 
  2) pick a bug (send a reply to this message on list to avoid multiple
 people picking the same bug)
  3) check the upstream BTS to see if the same bug is reported there, if so
  ... 

NOTE: point 2 is opportunity for a bit of bit of social engineering: 
  if everybody in the team picks 1 antiquated bug to follow up on and
  sends a reply to the list, people will have the impression that
  something good is happening, mostly the'll go "well, I can do that",
  and will thus be more likely to jump in.

Important points here are:
1) you ask for help
2) you do so in a forum where people are interested in KDE, and a lot of
   people won't be heaviliy involved yet
3) you point out that helping out does not require special skills or major
   effort (thus lowering the barrier to entry)
4) you give a step by step instruction of how to get involved (again
   lowering the barrier to entry)

> So Yes I wonder if it's not that it's just easier to pretend it's our
> fault

Nobody is saying anybody is at fault, which doesn't mean there's no room for 
improvement.
-- 
Cheers, cobaco (aka Bart Cornelis)


pgpWIPSilGjgg.pgp
Description: PGP signature


Re: On maintainers not responding to bugs

2007-03-07 Thread Pierre Habouzit
On Wed, Mar 07, 2007 at 10:47:09PM +0900, Charles Plessy wrote:
> Le Wed, Mar 07, 2007 at 02:19:17PM +0100, Pierre Habouzit a écrit :
> 
> >   The mail you are answering to was against forums, not really against
> >   the BTS btw.
> 
> Bonsoir Pierre,
> 
> I have lurked a bit on the ubuntu forums, and found "intersting"
> threads. For instance, some persons wrote about doing a sort of medical
> Ubuntu project, and then realised that debian-med was alive, and wrote
> at the end of the thread that being less people with less experience,
> they could not do better than us.
> 
> The conclusion I took after reading this is that there are people (often
> young) eager to find a niche in which they can be leaders (this is also
> how I interpreted one of your previous email). The question is wether we

  My point was not becoming a local leader, but having a place in the
team where my opinion matters. No need to be a leader for that, at all.
E.g. I've  never ever felt beeing in the place of a leader in the KDE
team, there even was nothing like a leader in it. And I shall say, it
was, and think still is a very nice team to work with, I enjoyed the
people in it a lot.

> should try to attract them, and if yes, where and how. Maybe having a
> way to quantitatively evaluate bug triaging and giving conditional
> access to some reward could for instance motivate untrained persons to
> contribute ? The reward can be as simple as using the score to provide
> some social status on communauty websites. For instance, in the forums
> of Ubuntu, people have more or less brown coffee grains (to suggest that
> they are stronger ?).
> 
> I have tried a few fishing experiments when Google brought me on places
> dealing with free medical or bioinformatical software, and I have to
> admit that for the moment my fish basket is empty. But if it is in
> forums and other platforms which we deem sub-optimal there that people
> who have energy to spend are, isn't it where Debian should go if it
> wants to increase its manpower ? I will continue to do opportunistic
> fishing for a while...

  Any kind of help is welcomed IMHO. Point is, if we _have_ to invest
time to fish contributors like you say, those will have to be worth the
investment, hence meaning that they should have a high probability to
become regular contributors.

  Youngs people are often enthusiastic, a lot, but I'm not sure this is
the kind of people that gets things done either. Note that I don't say
it's not worth trying, it's just that I would not do that myself, I
_think_ it's too time consuming when you balance it with the gain for
debian. I may be wrong.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpoaqwKo0iKO.pgp
Description: PGP signature


Re: On maintainers not responding to bugs

2007-03-07 Thread Charles Plessy
Le Wed, Mar 07, 2007 at 02:19:17PM +0100, Pierre Habouzit a écrit :

>   The mail you are answering to was against forums, not really against
>   the BTS btw.

Bonsoir Pierre,

I have lurked a bit on the ubuntu forums, and found "intersting"
threads. For instance, some persons wrote about doing a sort of medical
Ubuntu project, and then realised that debian-med was alive, and wrote
at the end of the thread that being less people with less experience,
they could not do better than us.

The conclusion I took after reading this is that there are people (often
young) eager to find a niche in which they can be leaders (this is also
how I interpreted one of your previous email). The question is wether we
should try to attract them, and if yes, where and how. Maybe having a
way to quantitatively evaluate bug triaging and giving conditional
access to some reward could for instance motivate untrained persons to
contribute ? The reward can be as simple as using the score to provide
some social status on communauty websites. For instance, in the forums
of Ubuntu, people have more or less brown coffee grains (to suggest that
they are stronger ?).

I have tried a few fishing experiments when Google brought me on places
dealing with free medical or bioinformatical software, and I have to
admit that for the moment my fish basket is empty. But if it is in
forums and other platforms which we deem sub-optimal there that people
who have energy to spend are, isn't it where Debian should go if it
wants to increase its manpower ? I will continue to do opportunistic
fishing for a while...

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wako, Saitama, Japan


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



Bug#413842: ITP: ogdi -- A library which implements an API for OGDI, a network-enabled protocol to access raster and vector GIS data respositories

2007-03-07 Thread Francesco Paolo Lovergine
Package: wnpp
Severity: wishlist
Owner: Francesco Paolo Lovergine <[EMAIL PROTECTED]>

* Package name: ogdi
  Version : 3.1.5
  Upstream Author : Frank Warmerdam et al
* URL : http://ogdi.sourceforge.net/
* License : BSD-like
  Programming Lang: C
  Description : A library which implements an API for OGDI, a 
network-enabled protocol to access raster and vector GIS data respositories

OGDI is the Open Geographic Datastore Interface. OGDI is an application
programming interface (API) that uses a standardized access methods to
work in conjunction with GIS software packages (the application) and
various geospatial data products. OGDI uses a client/server architecture
to facilitate the dissemination of geospatial data products over any
TCP/IP network, and a driver-oriented approach to facilitate access to
several geospatial data products/formats.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686
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: edit patches in dpkg configuration file dialog

2007-03-07 Thread Matthias Julius
Jean-Christophe Dubacq <[EMAIL PROTECTED]> writes:

> On Tue, Mar 06, 2007 at 08:53:00PM +0100, Alexander Schmehl wrote:
>> > Although this clutters up /etc they could be saved as *.dpkg-last or
>> > so.  New packages' conffiles can be saved as *.dpkg-new just like dpkg
>> > currently does if one chooses not to install the new file.  Before a
>> > new version is installed *.dpkg-new would be renamed to *.dpkg-last.
>> 
>> ... and they will probably deleted my many admins thinking they are not
>> needed.  I don't think you can count on leaving them in /etc and finding
>> them again.

Everyone is free to break his own system. ;-)

The consequence would be minimal.  dpkg would just fall back to the
current behavior.

>
> And why shouldn't they. If anything, this should belong to
> /var/lib/dpkg/

You are right.  This is the logical place.

Matthias


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



Re: On maintainers not responding to bugs

2007-03-07 Thread Pierre Habouzit
On Tue, Mar 06, 2007 at 11:39:16AM -0800, Don Armstrong wrote:
> On Tue, 06 Mar 2007, Pierre Habouzit wrote:
> > And if your point is that the current BTS UI sucks, then well, yes I
> > believe it, and it seems one of our DPL candidates thinks the same
> 
> As I've indicated to the DPL candidate who has mentioned this, and
> I'll say again:
> 
> If there are specific things about the BTS which you do not like, file
> wishlist bugs or clarify existing wishlist bugs for them. One does not
> need to be running for DPL to do that. Just complaining about it is
> pointless.

  I know, and I'm not making any reproaches, only stating a fact. I've
no time right now to think of a better interface yet. I don't like the
lookup interface of our BTS, though I do not like any query interface of
any bug tracking system I know. So it's not just making suggestions it's
also defining something new, and I've no time for that.

  The mail you are answering to was against forums, not really against
the BTS btw.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpTLKdFLvBR5.pgp
Description: PGP signature


Re: On maintainers not responding to bugs

2007-03-07 Thread Pierre Habouzit
On Tue, Mar 06, 2007 at 12:49:56PM -0500, Matthias Julius wrote:
> Pierre Habouzit <[EMAIL PROTECTED]> writes:
> >   Like every packaging team in debian, mailing the [EMAIL PROTECTED] or
> > [EMAIL PROTECTED] depending on how old the team is. Usually that list
> > is in the Maintainer or Uploaders field of the control file.
> > #debian-$team is also a good place to look. Those things are _obvious_.
> 
> Do you expect potential helpers to search various list archives or
> mail maintainers to ask whether they need help?  I would guess only

  no I expect them to contact the teams, and entry points are obvious.
Hiding behind the fact that entry points are not waved under their nose
and that because of that they can't help is, well, Ubuesque.

> >   The mails I alluded to earlier (to seek for help) have seen (at least
> > for the KDE guys, I'll let the Gnome guys tell you how it worked for
> > them) 0 answer. My experience is that RFH bugs works well when Norbert
> > put it on vim to ask for co-maitenance or such very interesting software
> > to package. But when the job is to deal with KDE bugs, there is really
> > less people eager to do the job.
> 
> What does it hurt to file a RFH bug?  At least it is a centralized
> platform where potential helpers can find out about who need help.
> And it is a logical place for that.  And the list is posted weekly on
> -devel.

  because that's not one, but 1500, and that would not be very useful to
flood RFH that are often specific needs for technicals matters. Here
it's manpower missing, RFH seems inapropriate to me.


> >   Again, I do not appreciate the latent criticism of the big teams to
> > hide their understaff problem. It's blatantly bogus hence iritating,
> > almost insulting.
>
> Don't you wonder why it is perceived like that?

  Yes I do, especially given that in that thread those teams have
claimed many times they need help, and that people continue to pretend
like it never happened. So Yes I wonder if it's not that it's just
easier to pretend it's our fault, than to question onself "wtf didn't I
helped before already ?"

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp7NlVHTQFZ8.pgp
Description: PGP signature


Bug#413835: ITP: haskell-zlib -- Haskell library for using gzip and zlib formats

2007-03-07 Thread Kari Pahula
Package: wnpp
Severity: wishlist
Owner: Kari Pahula <[EMAIL PROTECTED]>


* Package name: haskell-zlib
  Version : 0.3
  Upstream Author : Duncan Coutts <[EMAIL PROTECTED]>
* URL : 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/zlib-0.3
* License : revised BSD
  Programming Lang: Haskell
  Description : Haskell library for using gzip and zlib formats

 This library provides support for compression and decompression in the
 gzip and zlib formats, using ByteStrings.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.17-1-k7
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)


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



Bug#413833: ITP: haskell-binary -- Haskell library for binary serialisation using lazy ByteStrings

2007-03-07 Thread Kari Pahula
Package: wnpp
Severity: wishlist
Owner: Kari Pahula <[EMAIL PROTECTED]>


* Package name: haskell-binary
  Version : 0.2
  Upstream Author : Lennart Kolmodin <[EMAIL PROTECTED]>
* URL : 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-0.2
* License : revised BSD
  Programming Lang: Haskell
  Description : Haskell library for binary serialisation using lazy 
ByteStrings

 The 'binary' package provides Data.Binary, containing the Binary class,
 and associated methods, for serialising values to and from lazy
 ByteStrings. 
 .
 A key feature of 'binary' is that the interface is both pure, and efficient.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.17-1-k7
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)


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



Bug#413827: ITP: hal-info -- device information for HAL

2007-03-07 Thread Michael Biebl
Package: wnpp
Severity: wishlist
Owner: Michael Biebl <[EMAIL PROTECTED]>

* Package name: hal-info
  Version : 20070304
  Upstream Author : David Zeuthen <[EMAIL PROTECTED]>
* URL : git://anongit.freedesktop.org/git/hal-info
* License : GPL
  Description : device information for HAL

  hal-info will be a requirement of hal-0.5.9 and is maintained within the
  pkg-utopia team.

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


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



Bug#413820: ITP: libpam-krb5-migrate -- pluggable authentication module for migrating to Kerberos

2007-03-07 Thread Jelmer Vernooij
Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij <[EMAIL PROTECTED]>


* Package name: libpam-krb5-migrate
  Version : 0.0.5
  Upstream Author : Steve Langasek <[EMAIL PROTECTED]>
Jelmer Vernooij <[EMAIL PROTECTED]>
* License : GPL
  Description : pluggable authentication module for migrating to Kerberos

pam_krb5_migrate is a stackable authentication module that takes a
username and password from an earlier module in the stack and attempts
to transparently add the user to a Kerberos realm using the Kerberos 5
kadmin service. The module can be used to ease the administrative
burdens of migrating a large installed userbase from pre-existing
authentication methods to a Kerberos-based setup. 

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-3-k7
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#413822: ITP: samba-gtk -- Set of GTK+ frontends for Samba

2007-03-07 Thread Jelmer Vernooij
Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij <[EMAIL PROTECTED]>


* Package name: samba-gtk
  Version : 0.0.1
  Upstream Author : Jelmer Vernooij <[EMAIL PROTECTED]>
* URL : http://wiki.samba.org/index.php/SambaGtk
* License : GPL
  Description : Set of GTK+ frontends for Samba

A set of GTK+ applications that allow use of SMB- and related protocols.
Current tools include a registry editor (local files and remote),
DCE/RPC endpoint profiler, remote job planner (at/cron equivalent) and
remote service manager.

Also contains a shared library with custom GTK+ widgets.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-3-k7
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: VMware Player packages

2007-03-07 Thread Mikhail Gusarov

Twas brillig at 12:27:07 when Hans Kratz did gyre and gimble:

 HK> After repeatedly seeing interest in VMware Player packages for
 HK> Debian I decided to post my work on packaging VMware Player. It
 HK> should work fine on sarge and sid. Currently only i386 is
 HK> supported, support for x86-64 is on my TODO list.

You'd probably like to join efforts with Marc Haber who maintains
vmware-package package in experimental :)

-- 


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



Bug#413826: ITP: haskell-hlist -- Haskell library for strongly typed heterogeneous collections

2007-03-07 Thread Kari Pahula
Package: wnpp
Severity: wishlist
Owner: Kari Pahula <[EMAIL PROTECTED]>


* Package name: haskell-hlist
  Version : 2.0+darcs20070207
  Upstream Author : Oleg Kiselyov, Ralf Lämmel, and Keean Schupke
* URL : http://homepages.cwi.nl/~ralf/HList/
* License : MIT/X
  Programming Lang: Haskell
  Description : Haskell library for strongly typed heterogeneous collections

 A heterogeneous collection is a datatype that is capable of storing
 data of different types, while providing operations for look-up,
 update, iteration, and others. There are various kinds of
 heterogeneous collections, differing in representation, invariants,
 and access operations.
 .
 HList is a Haskell library providing strongly typed heterogeneous
 collections including extensible records.

Mainly packaging this because HAppS 0.8.8 depends on this.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.17-1-k7
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)




VMware Player packages

2007-03-07 Thread Hans Kratz

Hi!

After repeatedly seeing interest in VMware Player packages for Debian
I decided to post my work on packaging VMware Player. It should work
fine on sarge and sid. Currently only i386 is supported, support for
x86-64 is on my TODO list.

Licensing and distribution:

The VMware Player EULA does not allow redistribution. I hope that an
agreement can be worked out with VMware Inc. for inclusion in non-free
just as for Java.

The Debian packaging (in the attached .tar.gz file) is placed under the GPL.

Installation:

1) Save the attached archive into a directory of your choice.

2) Download VMware-player-1.0.3-34682.tar.gz from
http://www.vmware.com/download/player/ and save it into this
directory.

3) In this directory do:
tar xzf VMware-player-1.0.3-34682.tar.gz
cd vmware-player-distrib
tar xzf ../vmware-player-1.0.3.34682-debian.tar.gz
dpkg-buildpackage -b -rfakeroot

4) In the parent directory of this directory do as root:
dpkg -i vmware-player-kernel-source_1.0.3.34682-1_i386.deb
module-assistant auto-install vmware-player-kernel
dpkg -i vmware-player_1.0.3.34682-1_i386.deb

5) Accept the EULA and configure networking.

6) Run vmplayer

TODO:
- Make VMware Player work on x86-64 systems.
- Include more documentation (module-assistant instructions, man pages, etc.)
- Set up a publicly accessible VCS repository
- Package the free (as in beer) VMware Server and related packages


Comments welcome!



Best regards


Hans


vmware-player-1.0.3.34682-debian.tar.gz
Description: GNU Zip compressed data


Re: edit patches in dpkg configuration file dialog

2007-03-07 Thread Jean-Christophe Dubacq
On Tue, Mar 06, 2007 at 08:53:00PM +0100, Alexander Schmehl wrote:
> > Although this clutters up /etc they could be saved as *.dpkg-last or
> > so.  New packages' conffiles can be saved as *.dpkg-new just like dpkg
> > currently does if one chooses not to install the new file.  Before a
> > new version is installed *.dpkg-new would be renamed to *.dpkg-last.
> 
> ... and they will probably deleted my many admins thinking they are not
> needed.  I don't think you can count on leaving them in /etc and finding
> them again.

And why shouldn't they. If anything, this should belong to
/var/lib/dpkg/

-- 
Jean-Christophe Dubacq


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