Maintainers

[Howard Young]

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.



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

Bug#413491: ITP: krecordmydesktop -- kde frontend to recordmydesktop

[Luca Bedogni]

Package: wnpp
Severity: wishlist
Owner: Luca Bedogni <[EMAIL PROTECTED]>

* Package name: krecordmydesktop
  Version : 0.1
  Upstream Author : Dusan Zatkovsky
* URL : http://sourceforge.net/projects/krecmydesktop/
* License : GPL
  Programming Lang: C++
  Description : kde frontend to recordmydesktop

krecordmydesktop adds an easily manageble interface to the kde kicker, to
imporve the usability of recordmydesktop.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.20.1
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

Re: xs-vcs-browser and friends

[Yaroslav Halchenko]

Hi Stefano,

If I got it right, XS-Vcs is to point to VC of a debian packaging, not
the original upstream sources. That would be useful to have both - links
to Debian packaging as well as to original upstream.  For instance
my VC keeps only debian-related changes and uses mergeWithUpstream
provided by svn-buildpackage.

Cheers
Yarik

On Fri, 23 Feb 2007, Stefano Zacchiroli wrote:
>   a couple of days ago Filippo Giunchedi (thanks a lot!) applied my
> patch which adds support for the XS-Vcs-Browser field in the web
> interface of the PTS.  Now you can happily use in your debian/control
> >...<
-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik


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

Re: racoon and bug 372665

[Milan P. Stanic]

On Sun, Mar 04, 2007 at 06:36:34PM +0530, Ganesan Rajagopal wrote:
> > Milan P Stanic <[EMAIL PROTECTED]> writes:
> 
> > I'd like to discuss problem with regards to bug #372665.
> > Why the racoon should be started in the rcS when even ssh is not?
> 
> The reasons should be fairly obvious from the bug. IPsec is at a much lower
> level than ssh. racoon needs to come up before other network dependent
> services get started.

README says that in the /etc/rcS.d/ should go scripts which are
executed once during boot. In debian policy manual rcS.d is
mentioned only once in section 9.3.4, but from short description it is
not clear could the daemons be started from scripts in that directory.

> > Yesterday I installed racoon but not configured it and on the next
> > reboot it blocked start-up process. I had to manually remove
> > /etc/rcS.d/S40racoon to boot machine.
> 
> This should not happen. What do you mean blocked the start-up process?

My mistake. I should say boot process. Sorry for inconvenience.

That was with racoon patched to work under runit (or other supervisor
software like daemontools). When I reinstalled racoon from testing
it doesn't block booting process. But that gives mi a hint. If some
daemon process could not be started (for whatever reason) it should
not block the booting.


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

Re: [EMAIL PROTECTED]: /usr/sbin/sshd: wrong DISPLAY is due to hijacking someone other's one...]

[Yaroslav Halchenko]

Now that I am aware about openssh bsd vs openssh portable ( ;-) ), I looked at
the CVS of portable SSH (following [1]) to see what/when it really happened -
so it wasn't a BSD specific patch, it was only adopted by bsd team in 2002 but
was in portable ssh since  1.2.2p1 (Mar 2000). I am not sure on either I
should ask for help from [EMAIL PROTECTED] or let openssh maintainer
to resolve the issue in the best way.

,-
| revision 1.17
| date: 2000/03/03 11:35:33;  author: damien;  state: Exp;  lines: +9 -1
|  - Don't permanently fail on bind() if getaddrinfo has more choices left for
|  us. Needed to work around messy IPv6 on Linux. Patch from Arkadiusz
|  Miskiewicz <[EMAIL PROTECTED]>
`---

So it IPv6 still messy? if not, then probably this patch indeed could be safely
deapplied I guess ;-)

,--
| RCS file: /cvs/openssh/channels.c,v
| retrieving revision 1.16
| retrieving revision 1.17
| diff -u -r1.16 -r1.17
| --- channels.c  17 Jan 2000 02:22:55 -  1.16
| +++ channels.c  3 Mar 2000 11:35:33 -   1.17
| @@ -16,7 +16,7 @@
|   */
|
|  #include "includes.h"
| -RCSID("$Id: channels.c,v 1.16 2000/01/17 02:22:55 damien Exp $");
| +RCSID("$Id: channels.c,v 1.17 2000/03/03 11:35:33 damien Exp $");
|
|  #include "ssh.h"
|  #include "packet.h"
| @@ -935,7 +935,11 @@
| /* Bind the socket to the address. */
| if (bind(sock, ai->ai_addr, ai->ai_addrlen) < 0) {
| /* address can be in use ipv6 address is already 
bound */
| -   verbose("bind: %.100s", strerror(errno));
| +   if (!ai->ai_next)
| +   error("bind: %.100s", strerror(errno));
| +   else
| +   verbose("bind: %.100s", strerror(errno));
| +
| close(sock);
| continue;
| }
| @@ -1199,6 +1203,10 @@
| debug("bind port %d: %.100s", port, 
strerror(errno));
| shutdown(sock, SHUT_RDWR);
| close(sock);
| +
| +   if (ai->ai_next)
| +   continue;
| +
| for (n = 0; n < num_socks; n++) {
| shutdown(socks[n], SHUT_RDWR);
| close(socks[n]);
|
|
`---


[1] http://www.openssh.com/portable.html

On Sat, 03 Mar 2007, Yaroslav Halchenko wrote:

> Hi Ben,

> Thank you for the help. FWIW, I confirm that it indeed fixes an issue on
> my box.

> 1.

> unfortunately it probably implies that I was wrong in my estimate of
> connection of this issue to original old #152250. It was reported
> on 1:3.4p1-0.0woody1, which came out on 26 Jun 2002 whenever the patch
> you've mention is from Oct 2002... Heh - now I need to go to snapshots
> to verify if that line wasn't there in debian's release.. I wish we had
> CVS for all the projects ;-)

> hm - got
> 459c1d0262e939d6432f193c7a4ba8a8  openssh_3.4p1.orig.tar.gz
> and that one has already that condition in:
> and Changelog states release of 20020626

> so I don't get it... may be there was some custom patch to
> openssh_3.4p1.orig.tar.gz from debian? (not in diff.gz?) which later on
> was applied upstream in 1.183

> so where am I wrong or am I right?

> 2.

> ok - looking sober look at the list of occupied ports now I see why the
> heck it happened at the first place here.

> VNC occupied localhost:6013 but left ip6-localhost:6013 free. There was
> one other VNC running on port 10 (so the one which could interfere with
> sshd), BUT there was already one victim who ran ssh with forwarded X,
> but probably never used any X app to discover that he can't ;-) :

> ,---
> | sshd 4566   kuzey8u  IPv6 121986047   TCP ip6-localhost:6010 
> (LISTEN)
> | Xvnc4   11957bart0u  IPv4 110812220   TCP *:6010 (LISTEN)
> `---

> and the next VNC was on :13, so whenever less salient user hit a but,
> she reported it to me, so I became investigating the issue. 

> Meanwhile I was running main sshd with -4, so all new connections occupy
> only localhost:60XX, while old ones go for both {ip6-,}localhost:

> ,---
> | sshd27484 yoh8u  IPv4 125284718   TCP localhost:6020 
> (LISTEN)
> | sshd27484 yoh9u  IPv6 125284719   TCP ip6-localhost:6020 
> (LISTEN)
> | sshd21917 arielle8u  IPv4 127502258   TCP localhost:6021 
> (LISTEN)
> `---

> without the problems-giving break, sshd allowed to ipv6 also occupies
> both (reporting FWIW)

> ,--
> | $> sudo lsof -i :6024
> | COMMAND PID USER   FD   TYPEDEVICE SIZE NODE NAME
> | sshd441  yoh8u  IPv4 127627340   TCP localhost:6024 (LISTEN)
> | sshd441  yoh9u  IPv6 127627341   TCP ip6-localhost:6024 (LISTEN)
> `---


> On Fri, 02 Mar 2007, B

Re: Custom repository and "WARNING: The following packages cannot be authenticated!"

[Michelle Konzack]

Hello Michael,

I have simpel signed my /debian/duats/etch/Release file with
an external signature /debian/duats/etch/Release.gpg and
imported the public key I have used for it.

So whats the problem?

Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: On maintainers not responding to bugs

[Jon Dowland]

On Sun, Feb 25, 2007 at 07:27:29PM -0500, David Nusinow
wrote:
> Simply replying to a bug won't get it fixed any sooner or
> decrease the impact it has on the user. In addition, it
> distracts us from doing what is potentially far more
> productive work.

Writing a mail to a bug along the lines of "I've read the
bug, it's valid, thanks" takes seconds if anything. What
really takes the time is reading the bug, and determining if
it is valid. Until you've done that, how can you know how
important the bug is, and whether it is a lower priority
than the productive work that you think sending such a mail
would distract you from?


-- 
Jon Dowland


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

Re: Maintainers

[Greg Folkert]

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?
-- 
greg, [EMAIL PROTECTED]

Novell's Directory Services is a competitive product to Microsoft's
Active Directory in much the same way that the Saturn V is a competitive
product to those dinky little model rockets that kids light off down at
the playfield. -- Thane Walkup


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

Maintianers

[Howard Young]

My earlier message was very over the top it would appear.

I had a look while on lunch and tracked down some statistics.
http://www.dfes.gov.uk/rsgateway/DB/SBU/b000266/154-t17a.htm

See the line for GNVQ Advanced IT.
If this line is accurate then the number of people completing the course 
year by year is substantially lower than I had been expecting. Indeed 
looking at the other pages the number of people completing courses 
overall is lower. On that point however the statistic does only apply to 
a certain age group. I would rather have a number for total AGNVQ IT 
completions in a year. This should be higher than one might think at 
first because there are a large number of students who while not 'mature 
students' still have a year gap between secondary school and college for 
various reasons not forgetting re sits.


In any case, to explain.

While in college I took among other things two IT qualifications.
AGNVQ IT and A Level Computer Science. At the same time.

GNVQ IT runs by a specialist book written specifically for the course. 
So specific students will follow menu item by menu item click for click 
instructions.


A Level Computer Science was for me somewhat different. We touched on a 
broader ranger of IT subjects and the level of depth was (in the case of 
our class) governed by everyone's ability to keep up and take more in 
for each subject. The course ran from several books which were only 
fixed when the teacher wanted us to have a specific piece of information 
that was specific to that book. Or in other words it was possible to 
avoid the book the teacher used if one really wanted to and just look 
over someone else's shoulder (at their book not their work) or demand a 
photocopy hand out when something 'book specific' was being studied... 
or most commonly use a rental version from the library.


GNVQ qualifications (for people not of the UK or not aware) have good 
and bad points. So I do not completely agree or disagree with them. For 
example their design allows for people with very lacking organisation 
skills to be aided in achieving a qualification and learning 
organisational skills by which they can then operate in a work environment.
A Level had the potential to be more than GNVQ because the elective 
modules for GNVQ (that is extras) are limited in number. With A Level it 
is probably just down to you and your lecturer.


So you are all quite bored by now reading this.
Here is the horrific part.

GNVQ (when I attended) was not computer science.
or in other words. The click by click books are "THE OTHER OPERATING 
SYSTEM" only. And "THE OTHER OFFICE PACKAGE" almost entirely, as I 
vaguely recall opening something to do with Lotus for some reason, then 
closing and wondering why I had opened it.


Why bring you this depressing news...

To ask if there is anyone else who thinks that an alternative GNVQ book 
set or work sheet set for Linux would not greatly aid the uptake and as 
a result the number of maintainers.


If I am right in thinking that GNVQ is almost never performed with 
anything but "THE OTHER OPERATING SYSTEM" and its "EXPENSIVE APPS" then 
the absence of such a book is not even merely a lacking, it is a loss 
because all but those people who for some reason choose of natural 
course to dislike "THE OTHER OPERATING SYSTEM" will be trained to use 
"THE OTHER OPERATING SYSTEM" when it makes as much sense to me that they 
choose fairly by a piece of information at the beginning of their course.


Lastly, not all of the AGNVQ relies on the OS for instance some things 
like setting up a null modem connection used terminal but terminal is 
similar but better on Linux.


Howard


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

Re: On maintainers not responding to bugs

[Jon Dowland]

On Mon, Feb 26, 2007 at 10:57:46AM +0100, Pierre Habouzit
wrote:
>   And I think the list can grow larger just by looking at
>   the reality, and not dreaming stupid ideas and trying to
>   defend them.
snip
>   Just _look_ at that: [0]. I mean _look_, not pretend to.
>   Instead of answering to that thread, arrogantly
>   explaining to us how bad we suck,
snip

Even if you do think it's a crazy idea you should not be
angered or offended by the suggestion and debate of such an
idea.  That's what an open operating system should
encourage.


-- 
Jon Dowland


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

Re: On maintainers not responding to bugs

[Jon Dowland]

On Mon, Feb 26, 2007 at 07:07:33PM +0100, Mike Hommey wrote:
> Now, the iceape case is interesting: *you* (as in, the one
> complaining about rotting bugs) are also allowed to help
> the maintainers instead of whining.

One very positive thing from this thread is the number of
packages / teams that are openly admitting that there is a
manpower problem.

I think that there is an untapped pool of people who could
help a lot with the triage work, but the question is, where
do they start? How do they know that they are welcome to
start responding to a given packages bugs with some kind of
analysis?

One way is the existing wnpp system.
 lists
packages which have RFH filed. This list is very short and
doesn't seem to include the examples which have been put
forward in this thread at all.

For such packages, where triage would be needed, would it
not make sense to file an RFH bug to that effect?


-- 
Jon Dowland


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

Re: edit patches in dpkg configuration file dialog

[Bastian Venthur]

Nico Golde schrieb:
> what about the following idea.
> If a configuration file is marked as conffile in a package 
> you have the possibility to select between:
> 
> - Install the new version of the configuration file from the 
>   package
> - Keep your current installed version of the file
> - View the differences

[...]

> What about the possibility to view the patch, edit it with 
> your favorite editor and the just apply the patch?
> This way you don't have to do all the manual stuff after 
> installing the packages and you don't miss new configuration 
> flags.

[...]

> What do you think?

I haven't tested your patch, but I like the general idea.

A good example is exim4. Where I have greylistd installed and configured
it to allow SSL connections. Every once in a while exim gets an update
with some changes in it's config. I'd like to take this changes but
still want to keep my own settings.

So I support your Idea and hope it will make it's way into dpkg.


Cheers,

Bastian

-- 
Bastian Venthur  http://venthur.de
Debian Developer venthur at debian org


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

Re: On maintainers not responding to bugs

[Loïc Minier]

On Mon, Mar 05, 2007, Jon Dowland wrote:
> I think that there is an untapped pool of people who could
> help a lot with the triage work, but the question is, where
> do they start? How do they know that they are welcome to
> start responding to a given packages bugs with some kind of
> analysis?

 I think you missed the "0-day bug forwarding and bug patching on *
 bugs" mails:
  

-- 
Loïc Minier <[EMAIL PROTECTED]>


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

Re: edit patches in dpkg configuration file dialog

[sean finney]

just to throw in my $0.02,

On Mon, 2007-03-05 at 18:43 +0100, Bastian Venthur wrote:
> I haven't tested your patch, but I like the general idea.
> 
> A good example is exim4. Where I have greylistd installed and configured
> it to allow SSL connections. Every once in a while exim gets an update
> with some changes in it's config. I'd like to take this changes but
> still want to keep my own settings.
> 
> So I support your Idea and hope it will make it's way into dpkg.

i think what would be even easier to implement (and perhaps as useful)
would be to see the differences between the new maintainer conffile and
the previous version of the maintainer conffile.

to implement this, one would simply need to keep a copy of
dpkg-installed conffiles in some directory hierarchy under /var/lib/dpkg
and provide a new option to diff this old version against the
newly-unpacked-but-not-installed version of the conffile.


sean


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

Re: [EMAIL PROTECTED]: /usr/sbin/sshd: wrong DISPLAY is due to hijacking someone other's one...]

[Russ Allbery]

Yaroslav Halchenko <[EMAIL PROTECTED]> writes:

> ,-
> | revision 1.17
> | date: 2000/03/03 11:35:33;  author: damien;  state: Exp;  lines: +9 -1
> |  - Don't permanently fail on bind() if getaddrinfo has more choices left for
> |  us. Needed to work around messy IPv6 on Linux. Patch from Arkadiusz
> |  Miskiewicz <[EMAIL PROTECTED]>
> `---

> So it IPv6 still messy? if not, then probably this patch indeed could be
> safely deapplied I guess ;-)

This is probably referring to binding an IPv6 :: socket and getting IPv4
for free, so that a subsequent bind to an IPv4 0.0.0.0 address fails.  So
far as I know, this is still the Linux IPv6 behavior.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Bug#1927: no /usr/include/linux/errno.h

[Karen.Schmidtman]

 

 

Karen Schmidtman
Logistics Analyst

SPARTA
Satellite Control Network Contract

719-637-5601

 

I am NOT an authorized purchasing agent, I am only authorized to gather
information regarding a part(s), availability,location, and budgetary
data such as cost and lead time.

NOTICE: This communication, including any attachment, contains
information that may be confidential or privileged, and is intended
solely for the entity or individual to whom it is addressed. If you are
not the intended recipient, please notify the sender at once, and you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this message is strictly prohibited.

 

Re: edit patches in dpkg configuration file dialog

[Nico Golde]

Hi,
* sean finney <[EMAIL PROTECTED]> [2007-03-05 19:07]:
> just to throw in my $0.02,
> 
> On Mon, 2007-03-05 at 18:43 +0100, Bastian Venthur wrote:
> > I haven't tested your patch, but I like the general idea.
> > 
> > A good example is exim4. Where I have greylistd installed and configured
> > it to allow SSL connections. Every once in a while exim gets an update
> > with some changes in it's config. I'd like to take this changes but
> > still want to keep my own settings.
> > 
> > So I support your Idea and hope it will make it's way into dpkg.
> 
> i think what would be even easier to implement (and perhaps as useful)

The implementation was not really difficult, the patch file 
itself is 200 lines alltogether.

> would be to see the differences between the new maintainer conffile and
> the previous version of the maintainer conffile.
> 
> to implement this, one would simply need to keep a copy of
> dpkg-installed conffiles in some directory hierarchy under /var/lib/dpkg
> and provide a new option to diff this old version against the
> newly-unpacked-but-not-installed version of the conffile.

I am not sure if I get your idea 100% correctly but what 
about the user changes if you just look at the old and the 
new maintainer version of the config file?
Kind regards
Nico
-- 
Nico Golde - http://www.ngolde.de
JAB: [EMAIL PROTECTED] - GPG: 0x73647CFF
Forget about that mouse with 3/4/5 buttons,
gimme a keyboard with 103/104/105 keys!


pgpOzaha0Hapg.pgp
Description: PGP signature

Re: edit patches in dpkg configuration file dialog

[sean finney]

On Mon, 2007-03-05 at 19:23 +0100, Nico Golde wrote:
> 
> The implementation was not really difficult, the patch file 
> itself is 200 lines alltogether.

not bad :) i have to admit i haven't looked at the patch.

> > would be to see the differences between the new maintainer conffile and
> > the previous version of the maintainer conffile.
> > 
> > to implement this, one would simply need to keep a copy of
> > dpkg-installed conffiles in some directory hierarchy under /var/lib/dpkg
> > and provide a new option to diff this old version against the
> > newly-unpacked-but-not-installed version of the conffile.
> 
> I am not sure if I get your idea 100% correctly but what 
> about the user changes if you just look at the old and the 
> new maintainer version of the config file?

this wouldn't be for merging or anything, simply seing what the cause of
the prompt was in the first place.  say i've made 500 different changes
to my apache.conf, and then in the next version the maintainer makes
some random change to the conffile.  it'd be nice to be able to see the
what the change was isolated by itself, without all the noise from my
local changes.

anyway, good luck waking up the sleeping dpkg monster.


sean


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

Re: [EMAIL PROTECTED]: /usr/sbin/sshd: wrong DISPLAY is due to hijacking someone other's one...]

[Yaroslav Halchenko]

> > So it IPv6 still messy? if not, then probably this patch indeed could be
> > safely deapplied I guess ;-)
> This is probably referring to binding an IPv6 :: socket and getting IPv4
> for free
and if socket on IPv4 is taken already? this is what lead to the
original issue.

So should that "continue" should then be taken only if ai->ai_family == 
AF_INET6 ?

> so that a subsequent bind to an IPv4 0.0.0.0 address fails.  So
> far as I know, this is still the Linux IPv6 behavior.
-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik


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

Re: On maintainers not responding to bugs

[Pierre Habouzit]

On Mon, Mar 05, 2007 at 05:35:43PM +, Jon Dowland wrote:
> On Mon, Feb 26, 2007 at 07:07:33PM +0100, Mike Hommey wrote:
> > Now, the iceape case is interesting: *you* (as in, the one
> > complaining about rotting bugs) are also allowed to help
> > the maintainers instead of whining.
> 
> One very positive thing from this thread is the number of
> packages / teams that are openly admitting that there is a
> manpower problem.

  wow, I'm really amazed. For the KDE and Gnome teams (and I'm sure
others did it as well) there was mails requesting help to triage bugs
and so on (from january 2006). Reading this thread could let people
believe that those teams neved did that, and always denied they needed
help. Well, sorry if I don't like the sound of that, but I really don't
because it's at the antipodes of the reality.

> I think that there is an untapped pool of people who could
> help a lot with the triage work, but the question is, where
> do they start?

  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_.

> How do they know that they are welcome to
> start responding to a given packages bugs with some kind of
> analysis?

  Well, you don't need to be a developer neither a regular contributor
to do that, don't hide behind false excuses.

> One way is the existing wnpp system.
>  lists
> packages which have RFH filed. This list is very short and
> doesn't seem to include the examples which have been put
> forward in this thread at all.
> 
> For such packages, where triage would be needed, would it
> not make sense to file an RFH bug to that effect?

  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.


  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.

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


pgpDl4u7GFVqs.pgp
Description: PGP signature

Re: Maintainers

[Howard Young]

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]

Re: [EMAIL PROTECTED]: /usr/sbin/sshd: wrong DISPLAY is due to hijacking someone other's one...]

[Russ Allbery]

Yaroslav Halchenko <[EMAIL PROTECTED]> writes:

> and if socket on IPv4 is taken already? this is what lead to the
> original issue.

> So should that "continue" should then be taken only if ai->ai_family ==
> AF_INET6 ?

Maybe.  I don't know that part of the code well.  Looking at INN, we ran
into the problem with listen() rather than bind(), so maybe this is a
different issue.

/* Walk the list of file descriptors, listen on each, and create new
   channels for each.  Some IPv6 systems already listening on the IPv6
   wildcard address will return EADDRINUSE when trying to listen to the
   IPv4 socket; just ignore that error. */
okay = false;
for (i = 0; i < count; i++) {
if (fds[i] < 0)
continue;
if (listen(fds[i], MAXLISTEN) < 0) {
if (i != 0 && errno == EADDRINUSE)
continue;
syswarn("SERVER cant listen to socket");
}
rc = CHANcreate(fds[i], CTremconn, CSwaiting, RCreader, RCwritedone);
notice("%s rcsetup %s", LogName, CHANname(rc));
RCHANadd(rc);
RCchan[start + i] = rc;
okay = true;
}

However, I seem to recall seeing errors with bind as well that we're
currently just ignoring, so I probably don't have a complete fix in INN
either.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: xs-vcs-browser and friends

[Stefano Zacchiroli]

On Mon, Mar 05, 2007 at 10:02:29AM -0500, Yaroslav Halchenko wrote:
> If I got it right, XS-Vcs is to point to VC of a debian packaging, not
> the original upstream sources. That would be useful to have both - links

XS-Vcs point to the repository used by the maintainer to version its
work. If he is a good maintainer he either have an automatic (or at
least documented) way of accessing upstream sources from its repository,
or upstream sources are directly in the same repository of the
debian-specific stuff.

So I don't see the need of explicitly specify where upstream sources are
with an additional field.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

[RFR] po-debconf://lam (6 strings)

[cobaco (aka Bart Cornelis)]

-- 
Cheers, cobaco (aka Bart Cornelis)


lam_7.1.2-1_nl.po
Description: application/gettext


pgpbmhdoEnZ5U.pgp
Description: PGP signature

[RFR] po-debconf://rkhunter (4 strings)

[cobaco (aka Bart Cornelis)]

-- 
Cheers, cobaco (aka Bart Cornelis)


rkhunter_1.2.9-3_nl.po
Description: application/gettext


pgp2kKqVB7eNX.pgp
Description: PGP signature

Re: edit patches in dpkg configuration file dialog

[Nico Golde]

Hey,
* sean finney <[EMAIL PROTECTED]> [2007-03-05 20:00]:
> On Mon, 2007-03-05 at 19:23 +0100, Nico Golde wrote:
> > > would be to see the differences between the new maintainer conffile and
> > > the previous version of the maintainer conffile.
> > > 
> > > to implement this, one would simply need to keep a copy of
> > > dpkg-installed conffiles in some directory hierarchy under /var/lib/dpkg
> > > and provide a new option to diff this old version against the
> > > newly-unpacked-but-not-installed version of the conffile.
> > 
> > I am not sure if I get your idea 100% correctly but what 
> > about the user changes if you just look at the old and the 
> > new maintainer version of the config file?
> 
> this wouldn't be for merging or anything, simply seing what the cause of
> the prompt was in the first place.  say i've made 500 different changes
> to my apache.conf, and then in the next version the maintainer makes
> some random change to the conffile.  it'd be nice to be able to see the
> what the change was isolated by itself, without all the noise from my
> local changes.

Ah I get your point. Yes also another nice idea even if this 
would not fix my problem then :)

> anyway, good luck waking up the sleeping dpkg monster.

Sleeping is good, the first bug mentioning the need of a 
merge functionality is 8 years old...
I can not really understand this since we build up on tools 
like dpkg in apt, aptitude etc.

Also one of the arguments for debian was always it's package 
system and during some conversation at CLT 2007 about this 
feature I heard that gentoo and freebsd support some similar 
features since some time.
Kind regards
Nico
-- 
Nico Golde - http://www.ngolde.de
JAB: [EMAIL PROTECTED] - GPG: 0x73647CFF
Forget about that mouse with 3/4/5 buttons,
gimme a keyboard with 103/104/105 keys!


pgpLJoieOUGiM.pgp
Description: PGP signature

Re: [EMAIL PROTECTED]: /usr/sbin/sshd: wrong DISPLAY is due to hijacking someone other's one...]

[Hendrik Sattler]

Am Montag 05 März 2007 19:59 schrieb Russ Allbery:
> Yaroslav Halchenko <[EMAIL PROTECTED]> writes:
> > and if socket on IPv4 is taken already? this is what lead to the
> > original issue.
> >
> > So should that "continue" should then be taken only if ai->ai_family ==
> > AF_INET6 ?
>
> Maybe.  I don't know that part of the code well.  Looking at INN, we ran
> into the problem with listen() rather than bind(), so maybe this is a
> different issue.
>
> /* Walk the list of file descriptors, listen on each, and create new
>channels for each.  Some IPv6 systems already listening on the IPv6
>wildcard address will return EADDRINUSE when trying to listen to the
>IPv4 socket; just ignore that error. */

Well, you _could_ use the socket option to disable IPv4-mapped addresses, too.
However, from the logs it looks as if ssh is already doing that so that 
problem should not appear.

HS

State of the slimserver package.

[Simon Kelley]

I'm in a quandary about the future of the slimserver package.

There's a problem with upstream: it contains a significant amount of 
non-free stuff, which had to be ripped out of the software before it 
went into Debian. This means that the Debian package is missing some 
functionality, and that the process of going from an upstream download 
to a Debian package is a huge amount of work. The non-free stuff is 
firmware images, graphics, fonts and HTML for the web interface.


At the time I put slimserver into Debian, there was no upstream .deb 
available, and there was a significant possibility that the restrictions 
on what could go into the official Debian package would be relaxed. 
Neither of these facts is still true.


Upstream now makes available a repository with complete .debs and 
dependencies: installing the lastest release means adding the 
slim-devices package repository to sources.list and running apt. The 
packages seem to be of good quality, but probably not a completely 
seamless upgrade to the current debian package. The packages are not 
DFSG-compliant: they contain the whole of the software, with nothing 
removed, but the non-free stuff (missing in the official .debs)  is not 
re-distributable. Source packages are not provided. The packages were 
based on at least some of my packaging work, but they have diverged 
considerably.


SlimDevices was bought, last year, by Logitech. I understand that there 
is now no real chance of more of slimserver becoming DFSG-free.


The package in unstable is now signifcantly out of date, so I need to 
decide if I should put considerable effort into making new packages. 
I've already done enough work to determine that this will not be 
trivial. Given that Squeezebox users can now get Slimserver, packaged 
for Debian, directly from SlimDevices, I'm not particularly motivated to 
do this.


It's a pity that an un-crippled SlimServer package can't go into Debian, 
but that seems to be case, for the forseeable future.


So the question is, what should I do? Should I try and maintain a 
parallel and not-as-good package in Debian? Should I orphan the package 
in case anyone else wants to try? Should the package be removed from 
Etch+1? If so, how can we tell users to go direct to SlimDevices instead?



Cheers,

Simon.


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

Re: edit patches in dpkg configuration file dialog

[Vincent Danjean]

Nico Golde a écrit :
> * sean finney <[EMAIL PROTECTED]> [2007-03-05 20:00]:
>> anyway, good luck waking up the sleeping dpkg monster.
> 
> Sleeping is good, the first bug mentioning the need of a 
> merge functionality is 8 years old...
> I can not really understand this since we build up on tools 
> like dpkg in apt, aptitude etc.

Do you look at ucf (and the --three-way option ?). It is not as
full featured as what you propose, but this is already an
improvement over what dpkg can do. I think it will be easiest
to improved ucf that to modify dpkg.

  Vincent


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

Re: On management

[Turbo Fredriksson]

Quoting Josselin Mouette <[EMAIL PROTECTED]>:

> I'm not convinced at all that *funding* a manager would do any good to
> the project.

If we already had a _good_ project manager in our ranks, don't you think
they/he/she would have stepped up already? THAT'S why I think paying for
one might help...

> Which is why I'm wondering if there are ways to attract a
> few people with such profiles in the project. We have attracted many
> developers, sysadmins, translators, and everything we need to run the
> project; there must be a way to do the same for other profiles.

Those are all technical (exept maybe translators, but they don't do
it for the project, they do it for them selfs - which is a GOOD
thing! It's easier to attract technical (hard?) skills than 'soft'...

-- 
South Africa subway iodine Rule Psix CIA quiche supercomputer Uzi
congress radar nitrate Semtex Soviet arrangements jihad
[See http://www.aclu.org/echelonwatch/index.html for more about this]
[Or http://www.europarl.eu.int/tempcom/echelon/pdf/rapport_echelon_en.pdf]
If neither of these works, try http://www.aclu.org and search for echelon.
Note. This is a real, not fiction.
http://www.theregister.co.uk/2001/09/06/eu_releases_echelon_spying_report/
http://www.aclu.org/safefree/nsaspying/23989res20060131.html#echelon


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

Re: Bug#413353: debian-policy: New virtual package: dict-freedict

[Tatsuya Kinoshita]

clone 413353 -1
retitle -1 debian-policy: New virtual package: dictd-dictionary
thanks

I'm cloning this bug for "dictd-dictionary".

On March 5, 2007 at 2:14AM +0900,
tats (at vega.ocn.ne.jp) wrote:

> > BTW, I recommend to add a virtual package for a dictionary package
> > which provides /usr/share/dictd/{*.index,*.dict*}, such as
> > dict-freedict*, dict-gcide, dict-wn, dict-jargon, dict-foldoc,
> > dict-vera, and so on.
[...]
>  dictd-dictionarya dictionary for the dictd dictionary server

Thanks,
--
Tatsuya Kinoshita


pgpACNC2hMeIq.pgp
Description: PGP signature

debian-devel@lists.debian.org offering telemarketing sales lead generation & appointment setting based on perfomance pay as you use

[adi]

debian-devel@lists.debian.org

 Based in India ,We are offering a telemarketing program for generating
sales  leads-and appointment setting, order procurement on performance basis
We can also arrange outsourcing  for any job/assigmnent at about 20% of your
current American costs, like software development, web site development and
website management,and customer support,answering machine, follow up  from
various clients,suppliers,buyers and whatever more you want us to do

.
   We are willing to work according to your suggestions also and mutually we
can succeed and at lowest possible costs .on a sustainable basis and expand
according to demand. and also help you by working from India for your
business in any way you desire at low costs

   Please contact me with your suggestions
   Thanks
  Adi

   347 468 8646(linked to me at Bangalore,India)
   Indian phone Numbers 9180/28457026/32961798,mobile 919343206482
 Email
[EMAIL PROTECTED]
  Fax # 801 904 8325(USA)



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

[OFFTOPIC] Announcement of accounting program TXbook

[Claus Fischer]

Dear Debian developers,


I would like to announce TXbook, a GPL
accounting program for small businesses.

It has successfully done my balance sheet and P&L
for an Austrian small "Limited" (Ges.m.b.H.).
With some work it should serve users in the EU region
well; I don't know enough about the accounting systems
of other areas to make a meaningful statement.

Features:
- Full integer arithmetics, no doubles used.
- Country-specific rules for common business cases.
- No external database, everything in one file.
- All state changes available per commandline.
- Automatic balance sheets, P&L and closing of year.
- Operation continues over multiple business years.


The goal is that, in its final form, the user should not
need to know anything about accounting, and there should
be rules for every situation.


Many areas need work:
o No GUI yet!
  Presently it is only for die-hard commandline fans.
  Persons who want to do a QT, GTK, Curses, WTL, or
  other GUI frontend are very welcome.
o No countries other than Austria yet.
  Due to its rule-based nature, it will eventually be
  very supportive to non-accountants. However, that
  requires careful planning of account structure and
  financial reports.
  Persons willing to contribute that structure for
  other countries are very welcome. Note that you should
  have good experience in accouting, or be willing to
  spend a lot of time studying it.
o No Debian package yet :-)
o Areas of the engine that need polish:
  * More output formats (currently .txt, .cxv, .tex).
  * Better handling of aperiodic expenses.
  * More rules.
  * More complete command set.
  * Storage, undo/redo of commands.



Download and more information:
**


  http://www.txware.com/txbook



Mailing list:
*

Please send questions of any kind to:

  txbook-devel   AT  lists.txware.com

The list is moderated for non-subscribers.
Archives with e-mail addresses suppressed
will be at:

  http://lists.txware.com/txbook-devel


Best regards,

Claus

-- 
Claus Fischer <[EMAIL PROTECTED]>
http://www.clausfischer.com/


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

Re: On management

[cobaco (aka Bart Cornelis)]

On Monday 05 March 2007, Turbo Fredriksson wrote:
> (exept maybe translators, but they don't do it for the project, they do it
> for them selfs - which is a GOOD thing! 

The mere fact that you're able to translate kinda excludes you needing the 
translation in the first place (e.g. I translate cause I want to make 
Debian accessible to those whose english isn't good enough, and because I 
saw a niche to be filled there. On a purely personal level I prefer to run 
my software in English).

There's also people like Clytie (vietnamese translator, very active) who 
don't even use Debian themselves.

So saying translators do it purely, or even mainly, for themselves is doing 
debian translators in general a disservice IMHO
-- 
Cheers, cobaco (aka Bart Cornelis)


pgppUkgFuugFW.pgp
Description: PGP signature

The GIMP plugins for refocussing blurred images

[Bernd Zeimetz]

Hello,

since I'm not only a geek but also a photographer and GIMP user I've
decided to have a look at wnpp bug #398765 [1] and package the plugin
[2]. While packaging gimp-refocus I came across the refocus-it plugin,
which uses a different algorithm and also supports to refocus motion
blur, so I've decided to package it, too [3]. It seems to be much
slower, though - but it provides a command-line version which works
totally independent of The GIMP, it only depends on libc6.
I've commented and described the issues of  both plugins at the given
urls, testing and comments would be very appreciated.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=398765
[2] http://bzed.de/debian/packages/gimp-refocus
[3] http://bzed.de/debian/packages/gimp-refocus-it


Thanks a lot,

Bernd Zeimetz


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

Re: [EMAIL PROTECTED]: /usr/sbin/sshd: wrong DISPLAY is due to hijacking someone other's one...]

[Marco d'Itri]

On Mar 05, Russ Allbery <[EMAIL PROTECTED]> wrote:

> This is probably referring to binding an IPv6 :: socket and getting IPv4
> for free, so that a subsequent bind to an IPv4 0.0.0.0 address fails.  So
> far as I know, this is still the Linux IPv6 behavior.
Yes, but it can be controlled with code like this (and every program
which binds a listening socket should do it, because the system could be
configured both ways!):


#ifndef IPV6_V6ONLY
#define IPV6_V6ONLY 26
#endif
#ifndef IPPROTO_IPV6
#define IPPROTO_IPV6 41
#endif

fd = socket(AF_INET6, SOCK_STREAM, IPPROTO_IP);
if (fd < 0) {
printf("ERROR (socket) %d: %s", errno, strerror(errno));
return 1;
}

if (setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, &opt, sizeof(opt)) < 0) {
/* ignore failures */
}

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: On maintainers not responding to bugs

[Charles Plessy]

Le Mon, Mar 05, 2007 at 07:48:01PM +0100, Pierre Habouzit a écrit :
> 
>   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_.

Hi all,

I sometimes look over the fence to see how our neighbour does, and it
seems to me that the way they recruit helpful people is through
communication channels which does not require ab-initio knowkedge of
their internal organisation. There are forums and mailing lists, and
also they have a welcome gift for people who start to contribute, a
shiny @ubuntu.com email alias.

I have witnessed a period of activity on ubuntu-science, and clearly
there are pros and cons on getting the help of newcommers. One one hand
the work is done, but on the other, you can not expect its quality to be
the same as what a DD with 10 years of experience would do. For
instance, many .desktop files were created, icons were added, and
licence of icons were not checked.

So to generalise, it seems that there is the choice between seeing
repetitive work done imperfectly by beginners, or never done by
experienced people who are busy doing something else. Definitely the way
the contributors are supervised can raise the quality strongly.

In the end, there has been a lot of talk to judge wether some teams
accept or refuse help, but in my opinion, a more relevant question is
why the help is not coming to those who ask for it. Obvously, one answer
can be that help is not asked the most efficient way. For instance, irc
is an very unfriendly communication channel, and even mailing-lists are
somewhat unpopular among a broad category of internauts, who prefer
forums.

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]

Re: [EMAIL PROTECTED]: /usr/sbin/sshd: wrong DISPLAY is due to hijacking someone other's one...]

[Ben Hutchings]

On Mon, 2007-03-05 at 11:25 -0500, Yaroslav Halchenko wrote:
> Now that I am aware about openssh bsd vs openssh portable ( ;-) ), I looked at
> the CVS of portable SSH

Sorry, the OpenBSD version was the only version web-browseable and I
forgot to refer to the portable version before citing a commit.

>  (following [1]) to see what/when it really happened -
> so it wasn't a BSD specific patch, it was only adopted by bsd team in 2002 but
> was in portable ssh since  1.2.2p1 (Mar 2000). I am not sure on either I
> should ask for help from [EMAIL PROTECTED] or let openssh maintainer
> to resolve the issue in the best way.
> 
> ,-
> | revision 1.17
> | date: 2000/03/03 11:35:33;  author: damien;  state: Exp;  lines: +9 -1
> |  - Don't permanently fail on bind() if getaddrinfo has more choices left for
> |  us. Needed to work around messy IPv6 on Linux. Patch from Arkadiusz
> |  Miskiewicz <[EMAIL PROTECTED]>
> `---
> 
> So it IPv6 still messy?

As Russ pointed out this probably refers to the behaviour of binding
AF_INET6 sockets to both IPv6 and IPv4 ports by default.  This was later
dealt with properly:

revision 1.145
date: 2002/06/04 20:52:19;  author: stevesk;  state: Exp;  lines: +13 -1
 - (stevesk) [channels.c] bug #164 patch from YOSHIFUJI Hideaki (changed
   setsockopt from debug to error for now).

diff -u -r1.144 -r1.145
--- channels.c  23 Apr 2002 11:09:46 -  1.144
+++ channels.c  4 Jun 2002 20:52:19 -   1.145
@@ -2374,6 +2374,13 @@
continue;
}
}
+#ifdef IPV6_V6ONLY
+   if (ai->ai_family == AF_INET6) {
+   int on = 1;
+   if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY, 
&on, sizeof(on)) < 0)
+   error("setsockopt IPV6_V6ONLY: %.100s", 
strerror(errno));
+   }
+#endif
if (bind(sock, ai->ai_addr, ai->ai_addrlen) < 0) {
debug("bind port %d: %.100s", port, 
strerror(errno));
close(sock);
@@ -2392,7 +2399,12 @@
if (num_socks == NUM_SOCKS)
break;
 #else
-   break;
+   if (x11_use_localhost) {
+   if (num_socks == NUM_SOCKS)
+   break;
+   } else {
+   break;
+   }
 #endif
}
freeaddrinfo(aitop);
-- END --

> if not, then probably this patch indeed could be safely
> deapplied I guess ;-)

It might be better to do:

--- channels.c~ 2007-03-04 21:01:58.0 +
+++ channels.c  2007-03-06 01:34:03.0 +
@@ -2807,8 +2807,10 @@
debug2("bind port %d: %.100s", port, 
strerror(errno));
close(sock);
 
+#ifndef IPV6_V6ONLY
if (ai->ai_next)
continue;
+#endif
 
for (n = 0; n < num_socks; n++) {
close(socks[n]);
-- END --

I expect this would be acceptable to upstream too.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow Lindberg


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

Bug#413605: ITP: qfits -- Library offering easy access to FITS files

[Aurelien Jarno]

Package: wnpp
Severity: wishlist
Owner: Aurelien Jarno <[EMAIL PROTECTED]>

* Package name: qfits
  Version : 6.2.0
  Upstream Author : Yves Jung <[EMAIL PROTECTED]>
* URL : ftp://ftp.hq.eso.org/pub/qfits/
* License : GPL
  Programming Lang: C
  Description : Library offering easy access to FITS files

 FITS (Flexible Image Transport System) is a data format most used in
 astronomy.
 .
 qfits is a stand-alone library written in C to interact with files
 complying with the FITS format. It is fast and portable over any
 kind of POSIX-compliant platform. Functionalities offered by this
 library are:
  * Header queries (get keywords, values).
  * Header manipulation (load/modify/save).
  * Header/data offset queries.
  * Pixel loading/saving to memory.
  * Support for files of any dimension (NAXIS).
  * Support for FITS extensions, including ASCII and binary tables.
 .
  Homepage: http://www.eso.org/projects/aot/qfits/

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


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

Re: Bug#412919: ITP: predictive -- Text completion package for Emacs

[Jan Michael C. Alonzo]

Stefano Zacchiroli <[EMAIL PROTECTED]> writes:

Zack,


>
> The main point of IntelliSense [1] is not about the actual completion
> which type the word after you started typing it, is more about where to
> find the possible completions and, in particular to find them via some
> kind of representation of a codebase (e.g. the list of all methods
> belonging to the class of the instance named to the left of a '.').
>
> So, I ask you: either this is what "predictive" does for Emacs, maybe in
> some programmable way (and would be like Vim's omnicompletion feature)
> or it "just" complete in a single way using the word in the current
> buffer (as plain Vim's autocompletion) and then it would be better do
> describe it as "autocompletion".
>

Thank you for your comments about the predictive package. I already removed
the comparison to Intellisense to avoid confusion as well as emailed the
author regarding the matter. I also added "autocompletion" in the package
description. 

Thank you for your suggestions. Have a nice day.

Cheers,

jan

--
A meeting is an event at which the minutes are kept and the hours are lost.


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

Re: racoon and bug 372665

[Ganesan Rajagopal]

> "Milan" == Milan P Stanic <[EMAIL PROTECTED]> writes:

> README says that in the /etc/rcS.d/ should go scripts which are
> executed once during boot. In debian policy manual rcS.d is
> mentioned only once in section 9.3.4, but from short description it is
> not clear could the daemons be started from scripts in that directory.

Some daemons _need_ to be started from /etc/rcS.d (udev for
example). Another good example is portmap for nfs. If you're mounting nfs
volumes over IPsec then, racoon needs to start to setup the IPsec tunnel.

>> > Yesterday I installed racoon but not configured it and on the next
>> > reboot it blocked start-up process. I had to manually remove
>> > /etc/rcS.d/S40racoon to boot machine.
>> 
>> This should not happen. What do you mean blocked the start-up process?

> My mistake. I should say boot process. Sorry for inconvenience.

I understood that. I am still not clear why it would interfere with the boot
process. 

> That was with racoon patched to work under runit (or other supervisor
> software like daemontools). When I reinstalled racoon from testing
> it doesn't block booting process. But that gives mi a hint. If some
> daemon process could not be started (for whatever reason) it should
> not block the booting.

racoon should come up just fine even if it fails to negotiate any
tunnels. Any way, the default policy does not even setup any tunnels. Let me
know if you're still stuck; I can try your patches in a test setup with
runit when I find some time.

Ganesan

-- 
Ganesan Rajagopal


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