Work-needing packages report for Mar 2, 2007

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 357 (new: 6)
Total number of packages offered up for adoption: 87 (new: 5)
Total number of packages requested help for: 42 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   babygimp (#412626), orphaned 3 days ago
 Description: An icon editor in Perl-Tk
 Installations reported by Popcon: 61

   dvbstream (#412480), orphaned 3 days ago
 Description: Broadcast a DVB Transport stream over a LAN
 Installations reported by Popcon: 277

   dvbtune (#412476), orphaned 3 days ago
 Description: Simple tuning application for DVB cards
 Installations reported by Popcon: 313

   gtkeyboard (#412771), orphaned 2 days ago
 Description: A highly-configurable on-screen keyboard for
   mouse-typing
 Installations reported by Popcon: 72

   kvdr (#412469), orphaned 3 days ago
 Description: DVB (digital TV) Video Disk Recorder for KDE
 Installations reported by Popcon: 229

   mtoolsfm (#412770), orphaned 2 days ago
 Description: a graphical user interface for accessing dos formatted
   floppies
 Installations reported by Popcon: 147

351 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   binutils-m68hc1x (#412607), offered 3 days ago
 Description: binary utilities that support Motorola's 68HC11/12
   targets
 Reverse Depends: gcc-m68hc1x gdb-m68hc1x
 Installations reported by Popcon: 48

   gcc-m68hc1x (#412608), offered 3 days ago
 Description: GNU C compiler for the Motorola 68HC11/12 processors
 Reverse Depends: newlib-m68hc1x
 Installations reported by Popcon: 38

   gdb-m68hc1x (#412610), offered 3 days ago
 Description: GNU Debugger for the Motorola 68HC11/12 processors
 Installations reported by Popcon: 16

   hwinfo (#412637), offered 3 days ago
 Description: Hardware identification system
 Reverse Depends: hwinfo libhd13-dev xdebconfigurator
 Installations reported by Popcon: 1769

   newlib-m68hc1x (#412609), offered 3 days ago
 Description: newlib library built for Motorola's 68HC11/12 targets
 Installations reported by Popcon: 16

82 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   aboot (#315592), requested 616 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot aboot-cross dfsbuild ltsp-client
 Installations reported by Popcon: 56

   apt-build (#365427), requested 306 days ago
 Description: Need new developer(s)
 Installations reported by Popcon: 645

   apt-cacher (#403584), requested 73 days ago
 Description: caching proxy system for Debian package and source
   files
 Installations reported by Popcon: 270

   apt-show-versions (#382026), requested 205 days ago
 Description: lists available package versions with distribution
 Installations reported by Popcon: 2267

   athcool (#278442), requested 856 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 250

   audacity (#397166), requested 116 days ago
 Description: looking for co-maintainer
 Installations reported by Popcon: 2738

   cdw (#398252), requested 109 days ago
 Description: Tool for burning CD's - console version
 Reverse Depends: cdw gcdw
 Installations reported by Popcon: 241

   cvs (#354176), requested 371 days ago
 Description: Concurrent Versions System
 Reverse Depends: bonsai crossvc cvs-autoreleasedeb cvs-buildpackage
   cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta (17
   more omitted)
 Installations reported by Popcon: 12145

   docbook (#358522), requested 344 days ago
 Description: standard SGML representation system for technical
   documents
 Reverse Depends: alcovebook-sgml docbook-dsssl docbook-to-man
   sgmltools-lite
 Installations reported by Popcon: 3864

   docbook-xml (#358520), requested 344 days ago
 Description: standard XML documentation system, for software and
   systems
 Reverse Depends: dblatex docbook-dsssl docbook-ebnf
   docbook-html-forms docbook-jrefentry docbook-mathml docbook-simple
   docbook-slides docbook-website docbook-xsl-stylesheets-ko (6 more
   omitted)
 Installations reported by Popcon: 19160

   dpkg (#282283), 

Re: What is available at early userspace?

[Henrique de Moraes Holschuh]

On Fri, 02 Mar 2007, Nikita V. Youshchenko wrote:
> The issue I'm talking about (lots of error messages while udev init.d 
> script is running) happens in the current sequential boot procedure.

Udev runs at early userspace.

> It is caused by udev trying to resolve groups such as "fuse", that (a) are 
> definitly 'system' groups (so they likely should be either resolved 
> locally, or not resolved at all), and (b) may not be available 
> in /etc/groups if some [optional] packages are not installed.

Hmm... I should have read it completely (famous last words).  But part of my
point stands anyway, nothing nss should be trying to contact the network at
that stage.  The fact that it is is a bug in itself.  If udev is to look for
such stuff *later*, that means splitting the rules into early and late
rules, which also needs a proper early userspace definition.

OTOH, maybe one can just sidestep the issue entirely for now by:

1. punting all udev rules that refer to optional user/groups to the
packages that provide them.  It won't help if they end up being
added to some network database, though.

2. any users and groups that cannot be dealt with doing (1) need to
be made static.  This might not be feasible, I didn't check.

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


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

Re: Bug#412989: udev startup script prints a lot of errors when ldap is used

[Sylvain Le Gall]

On 01-03-2007, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 01, 2007 at 10:54:19PM +0300, Nikita V. Youshchenko wrote:
>
>> So a *fix* for this issue could be only inside udev package.
>> In all other places, only workarounds are possible.
>> And these workarounds do have the following drawbacks.
>> 
>> - if base-passwd will be used as workaround location, this will create a 
>> situation when changes to default udev configuration files, introducing 
>> references to new groups or removing references to old ones, will cause 
>> need of base-files update - which is increased complexity and will cause 
>> out-of-sync situations;
>
> My opinion is quite the opposite. Decisions like "all scanners should be
> owned by the 'scanner' group" are distro-wide policy, and udev is just
> one of the possible implementors of such policy. So the policy should
> not be in udev (anyone can write an udev replacement any day). In fact,
> MAKEDEV _should_ use the same group on a static /dev; how do you want to
> enforce that? (Yes, I realize that MAKEDEV does not have the same amount
> of information and therefore can not make such fine-grained decisions as
> udev).
>
> Also, on my system the udev configuration references 17 groups of which
> 12 is already present in /usr/share/base-passwd/group.master. I do not
> see any reason not to add the remaining 5 and be done with it.
>
>

I think it is a good idea to add all this group to standard groups. 

Don't forget to also add __user__ to these files (tss for example)

Regards,
Sylvain Le Gall


-- 
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]

I am sorry: it is me again with probably the final question: stracing revealed
the difference which I can't resolve myself due to lack of knowledge in socket
programming and IPv6

for port 6012 ssh fails to allocate DISPLAY since it is taken (so it is
normal):

,
| 31886 socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 8
| 31886 connect(8, {sa_family=AF_INET6, sin6_port=htons(6012), 
inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) 
= 0
| 31886 getsockname(8, {sa_family=AF_INET6, sin6_port=htons(58464), 
inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 
[28]) = 0
| 31886 close(8)  = 0
| 31886 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 8
| 31886 connect(8, {sa_family=AF_INET, sin_port=htons(6012), 
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
| 31886 getsockname(8, {sa_family=AF_INET, sin_port=htons(58464), 
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
| 31886 close(8)  = 0
| 31886 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 8
| 31886 setsockopt(8, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
| 31886 bind(8, {sa_family=AF_INET, sin_port=htons(6012), 
sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EADDRINUSE (Address already in use)
| 31886 write(2, "debug2: bind port 6012: Address "..., 48) = 48
| 31886 close(8)  = 0
`---

whenever for 6013 it succeeds using IPv6 (although I believe I never set
it up on that box)

,---
| 31886 socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 8
| 31886 connect(8, {sa_family=AF_INET6, sin6_port=htons(6013), 
inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) 
= 0
| 31886 getsockname(8, {sa_family=AF_INET6, sin6_port=htons(58464), 
inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 
[28]) = 0
| 31886 close(8)  = 0
| 31886 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 8
| 31886 connect(8, {sa_family=AF_INET, sin_port=htons(6013), 
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
| 31886 getsockname(8, {sa_family=AF_INET, sin_port=htons(58464), 
sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
| 31886 close(8)  = 0
| 31886 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 8
| 31886 setsockopt(8, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
| 31886 bind(8, {sa_family=AF_INET, sin_port=htons(6013), 
sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EADDRINUSE (Address already in use)
| 31886 write(2, "debug2: bind port 6013: Address "..., 48) = 48
| 31886 close(8)  = 0
| 31886 socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = 8
| 31886 setsockopt(8, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
| 31886 setsockopt(8, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
| 31886 bind(8, {sa_family=AF_INET6, sin6_port=htons(6013), inet_pton(AF_INET6, 
"::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
| 31886 listen(8, 128)= 0
| 31886 ioctl(8, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7ff10a50) = -1 EINVAL 
(Invalid argument)
| 31886 ioctl(8, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7ff10a50) = -1 EINVAL 
(Invalid argument)
| 31886 fcntl(8, F_GETFL) = 0x2 (flags O_RDWR)
| 31886 write(2, "debug2: fd 8 setting O_NONBLOCK\r"..., 33) = 33
| 31886 fcntl(8, F_SETFL, O_RDWR|O_NONBLOCK) = 0
| 31886 fcntl(8, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
| 31886 write(2, "debug3: fd 8 is O_NONBLOCK\r\n", 28) = 28
| 31886 write(2, "debug1: channel 1: new [X11 inet"..., 44) = 44
| 31886 uname({sys="Linux", node="ravana", ...}) = 0
| 31886 write(2, "debug1: server_input_channel_req"..., 88) = 88
| 31886 write(2, "debug1: session_by_channel: sess"..., 49) = 49
| 31886 write(2, "debug1: session_input_channel_re"..., 77) = 77
| ...
`---

Corresponding piece of code from sshd:

,
|
| for (display_number = x11_display_offset;
| display_number < MAX_DISPLAYS;
| display_number++) {
| port = 6000 + display_number;
| memset(&hints, 0, sizeof(hints));
| hints.ai_family = IPv4or6;
| hints.ai_flags = x11_use_localhost ? 0: AI_PASSIVE;
| hints.ai_socktype = SOCK_STREAM;
| snprintf(strport, sizeof strport, "%d", port);
| if ((gaierr = getaddrinfo(NULL, strport, &hints, &aitop)) != 
0) {
| error("getaddrinfo: %.100s", gai_strerror(gaierr));
| return -1;
| }
| for (ai = aitop; ai; ai = ai->ai_next) {
| if (ai->ai_family != AF_INET && ai->ai_family != 
AF_INET6)
| continue;
| sock = socket(ai->ai_family, ai->ai_socktype,
| ai->ai_protocol);
| if (sock < 0) {
| if ((errno != EINVAL) && (errno != 
EAFNOSUPPORT)
| #ifdef EPFNOSUPPORT
| && (errno != EPFNOSUPPORT)
| #endif
|

Re: Bug#412952: [Fwd: Bug#412952: file conflicts between afnix and aleph]

[Steve Langasek]

On Thu, Mar 01, 2007 at 09:14:42AM -, Paul Cager wrote:
> Could I have some advice about the best way to fix this one please? Here's
> a summary:

> * The obsolete package "aleph" is supserseded by "afnix".
> * I've requested the removal of aleph from unstable (bug #389163).
> * There is already another RC bug against "aleph", as it conflicts with
> tetex-bin.

> I didn't make afnix "Replaces:" aleph because aleph is scheduled for
> removal. I guess I should have done? What would be best - uploading a new
> version of  afnix, or marking this bug as blocked by 389163?

afnix should still conflict: and replace: aleph, because aleph shipped in
sarge and you want to provide a clean upgrade path for folks that had the
old aleph package installed.

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


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

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

[Yaroslav Halchenko]

Here you can see how it looks from client and server sides running in
verbose/debug modes. May be it would give a hint to a knowledgeable
person

http://www.onerussian.com/Linux/bugs/ssh.display/

-- 
  .-.
=--   /v\  =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko  /(   )\   ICQ#: 60653192
   Linux User^^-^^[17]



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

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

[Yaroslav Halchenko]

Dear Developers,

I think I've hit a really old bug (woody time) in ssh, and that
system is in the state when I could debug it a bit more to localize the
problem.

Please see my report below and original url to bug is of cause
http://bugs.debian.org/152250

Please advise on what to look for... for now I am going to check the
trace in channels.c:x11_create_display_inet which is the one handing out
DISPLAYs

- Forwarded message from Yaroslav Halchenko <[EMAIL PROTECTED]> -

Date: Thu, 01 Mar 2007 16:59:29 -0500
From: Yaroslav Halchenko <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: /usr/sbin/sshd: wrong DISPLAY is due to hijacking someone other's 
one...

Package: openssh-server
Version: 1:4.3p2-8
Followup-For: Bug #152250

It might be the same issue (just with 1 difference I will mention) or a
new one... I am not sure... 

today a user reported that forwarding X fails, ie she can't run X
application after being logged in.
sshd was assigning DISPLAY=localhost:13.0 whenever there is another user
using :13 in VNC:

cat  11990  0.0  0.2  32472 20836 ?SFeb12   0:27 Xvnc4 :13 
-desktop ravana:13 (cat) -auth /home/cat/.Xauthority -geometry 1200x900 -depth 
16 -rfbwait 3 -rfbauth /home/cat/.vnc/passwd -rfbport 5913 -pn -fp 
/usr/share/fonts/X11/Type1,/usr/lib/X11/fonts/Type1,/usr/lib/X11/fonts/Speedo,/usr/share/fonts/X11/misc,/usr/lib/X11/fonts/misc,/usr/share/fonts/X11/cyrillic,/usr/lib/X11/fonts/cyrillic,/usr/share/fonts/X11/100dpi,/usr/lib/X11/fonts/100dpi,/usr/share/fonts/X11/75dpi,/usr/lib/X11/fonts/75dpi
 -co /etc/X11/rgb

ok - so I had to leave that terminal opened (with :13) and  minimized so sshd
would not try to assign it to any other new connection.  Meanwhile I've
tried to debug it in gdb but unfortunately gdb asserted me away - now building
a backport from sid - may be it would help ;-)

*  a bit more details about PID 11990 (VNC with :13): it seems to be ok and has 
reported multiple attempt to abuse its display:

 AUDIT: Thu Mar  1 12:45:35 2007: 11990 Xvnc4: client 20 rejected from IP 
127.0.0.1 port 42522
  Auth name: MIT-MAGIC-COOKIE-1 ID: -1

* and bash which got :13 has environ:
USER=arielleLOGNAME=arielleHOME=/home/rumba/ariellePATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/gamesMAIL=/var/mail/arielleSHELL=/bin/bashSSH_CLIENT=192.168.22.23
 35385 22SSH_CONNECTION=192.168.22.23 35385 192.168.22.16 
22SSH_TTY=/dev/pts/53TERM=xtermDISPLAY=localhost:13.0LANG=en_US.UTF-8SSH_AUTH_SOCK=/tmp/ssh-VdHkb14243/agent.14243
  
as you can see both of them compete for the same DISPLAY:

$> lsof -i :6013
COMMAND   PIDUSER   FD   TYPEDEVICE SIZE NODE NAME
Xvnc4   11990 cat0u  IPv4 107557584   TCP *:6013 (LISTEN)
sshd14243 arielle   10u  IPv6 125115132   TCP ip6-localhost:6013 
(LISTEN)

I hope this would be of any help... if anyone requests rapidly for more 
information I would be glad to provide it

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

Versions of packages openssh-server depends on:
ii  adduser  3.102   Add and remove users and groups
ii  debconf  1.5.11  Debian configuration management sy
ii  dpkg 1.13.25 package maintenance system for Deb
ii  libc62.3.6.ds1-8 GNU C Library: Shared libraries
ii  libcomer 1.39+1.40-WIP-2006.11.14+dfsg-1 common error description library
ii  libkrb53 1.4.4-6 MIT Kerberos runtime libraries
ii  libpam-m 0.79-4  Pluggable Authentication Modules f
ii  libpam-r 0.79-4  Runtime support for the PAM librar
ii  libpam0g 0.79-4  Pluggable Authentication Modules l
ii  libselin 1.32-3  SELinux shared libraries
ii  libssl0. 0.9.8c-4SSL shared libraries
ii  libwrap0 7.6.dbs-12  Wietse Venema's TCP wrappers libra
ii  openssh- 1:4.3p2-8   Secure shell client, an rlogin/rsh
ii  zlib1g   1:1.2.3-13  compression library - runtime

openssh-server recommends no packages.

-- debconf information:
  ssh/insecure_rshd:
* ssh/insecure_telnetd:
  ssh/new_config: true
* ssh/use_old_init_script: true
  ssh/disable_cr_auth: false
  ssh/encrypted_host_key_but_no_keygen:


- End forwarded message -

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

Re: What is available at early userspace?

[Gabor Gombas]

On Fri, Mar 02, 2007 at 12:24:07AM +0300, Nikita V. Youshchenko wrote:

> The issue I'm talking about (lots of error messages while udev init.d 
> script is running) happens in the current sequential boot procedure.

If you're using a 2.6 kernel and udev then the boot procedure is _NOT_
sequential any more. There are some hacks in place to look more or less
like it was still sequential, but it fundamentally isn't. Even the
udevsettle call in /etc/init.d/udev is just "best effort".

Gabor

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


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

Re: Bug#412989: udev startup script prints a lot of errors when ldap is used

[Gabor Gombas]

On Thu, Mar 01, 2007 at 10:54:19PM +0300, Nikita V. Youshchenko wrote:

> So a *fix* for this issue could be only inside udev package.
> In all other places, only workarounds are possible.
> And these workarounds do have the following drawbacks.
> 
> - if base-passwd will be used as workaround location, this will create a 
> situation when changes to default udev configuration files, introducing 
> references to new groups or removing references to old ones, will cause 
> need of base-files update - which is increased complexity and will cause 
> out-of-sync situations;

My opinion is quite the opposite. Decisions like "all scanners should be
owned by the 'scanner' group" are distro-wide policy, and udev is just
one of the possible implementors of such policy. So the policy should
not be in udev (anyone can write an udev replacement any day). In fact,
MAKEDEV _should_ use the same group on a static /dev; how do you want to
enforce that? (Yes, I realize that MAKEDEV does not have the same amount
of information and therefore can not make such fine-grained decisions as
udev).

Also, on my system the udev configuration references 17 groups of which
12 is already present in /usr/share/base-passwd/group.master. I do not
see any reason not to add the remaining 5 and be done with it.

On the other hand, a rule like "the default udev configuration must not
reference any groups not provided by base-passwd" seems quite
reasonable.

> Also, it is unclear what udevd is going to do with non-resolved groups. 
> Likely it will create devices with invalid ownership. Won't that introduce 
> breakage at unexpected moments? E.g. if a package that actually uses 
> device (and creates a group if it does no exist) will be installed and 
> used before next reboot.

How is that different from MAKEDEV creating the node with bad ownership
on a static /dev?

> From the other hand, fix at udev level is relatively easy.
> It just should extract a list of referenced groups (and probably users) 
> from config files at build time (not at install time, because the talk is 
> only groups referenced in default configs), and add several lines to 
> postinst to create these groups if they don't exist.

That would be HORRIBLE. We should _NOT_ create any groups
unconditionally just because udev upstream likes them. New groups are
needed only if there are real users of them and udev is _not_ an user.
So udev must not be the entity deciding whether a group should be
created or not; it should first be discussed with the users, then added
to base-passwd and after that it can be used by udev. It's not like
we're going to add random new groups every other day...

Gabor

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


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

Re: [Fwd: Bug#412952: file conflicts between afnix and aleph]

[Paul Cager]

Frank Küster wrote:
> Michael Koch <[EMAIL PROTECTED]> wrote:
> 
>> Add this to afnix:
>>
>> Conflicts: aleph
>> Replaces: aleph
>>
>> This should make it possible to have always one of them installed and
>> make afnix replace aleph on dist-upgrades.
> 
> Isn't 
> 
> Provides: aleph
> 
> also needed?
> 
> Regards, Frank

I've had a look at the relevant sections of the Policy, and I can see
some advantages to having "Provides:". But, on balance, I think it is
probably best left out, letting the "Aleph" name wither and die:

*  It is a long time since Aleph became AFNIX (2003). I do not believe
too many people would still refer to it as Aleph, or attempt to install
it as "apt-get install aleph".
*  Upstream make very little reference to the old name; just one
mention, as far as I can see, in the "history" paragraph.
*  I believe the word "aleph" is probably more closely associated with
TeX, now.

I would be happy to change my mind if anyone has any counter-arguments
to the above! In the mean time I have uploaded a new package to
mentors.debian.net, and asked my mentor if he would consider sponsoring
an upload.

Thanks,
Paul


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

Re: On management

[Josselin Mouette]

First, please keep your bullshit about dunc-tank outside this otherwise
interesting discussion.

Le jeudi 01 mars 2007 à 16:18 -0500, Theodore Tso a écrit :
> The harder problem, though is that finding a really good project
> manager.  In my day job, I can tell you have as a technical architect,
> having a great project manager is like pure gold.  My project manager
> defers to me on technical issues, but helps to coordinate all of the
> other technical teams so that we can make all of the schedules line up
> and release a coherent solution to the customer.  Not to denigrate the
> efforts of the current release management team, but if we were to
> augment (NOT replace!) them with a good project manager, we could make
> them be far more effective.

That, I fully agree with. I also had the chance to see a good project
manager in action, and that makes a huge difference.

I'm not convinced at all that *funding* a manager would do any good to
the project. 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.

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


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

Re: On management

[Sune Vuorela]

On 2007-03-01, Theodore Tso <[EMAIL PROTECTED]> wrote:
> A third party organization, dunc-tank, which included a number of
> prominent Debian Developers, including AJ, did pay for two of the

How can it be a third party organization if it is launched by the DPL
_as_ DPL ?


(Source: AJs DPL review in his newest platform)


/Sune


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

Re: What is available at early userspace?

[Nikita V. Youshchenko]

> > And in the current situation, udev is *the* package that, by
> > installing it's default configuration files, injects references to
> > non-resolvable-locally users and groups into early stage of boot.
>
> Wrong.  Your expectations to what is allowed to be
> non-resolvable-locally are not in sync with what Debian currently
> supports.  Note: I am not telling you your expectations are
> unreasonable, but that they are more than what we can properly support
> right now.  And this is NOT just a bug in udev.

Athough I agree that there are issues with async userspace, I don't 
understand why you are talking about async userspace in this context.

The issue I'm talking about (lots of error messages while udev init.d 
script is running) happens in the current sequential boot procedure.
It is caused by udev trying to resolve groups such as "fuse", that (a) are 
definitly 'system' groups (so they likely should be either resolved 
locally, or not resolved at all), and (b) may not be available 
in /etc/groups if some [optional] packages are not installed.

Nikita


pgp1EWgIMuHSt.pgp
Description: PGP signature

Re: On management

[Theodore Tso]

On Thu, Mar 01, 2007 at 03:28:50PM +0100, Turbo Fredriksson wrote:
> Quoting Josselin Mouette <[EMAIL PROTECTED]>:
> 
> > As of now, I see it as a failure of the project. But this is also
> > nothing that can't be fixed. What do you people think could be done to
> > bring the skills we are lacking to the project, with its current
> > structure?
> 
> Since I agree (well, more than agree - I think it's absolutly vital :),
> how about actually PAYING them? Get one or two professionals and pay
> them (halftime perhaps)...
> 
> I have no idea how the economy looks, but would there be room for
> such a thing?

A third party organization, dunc-tank, which included a number of
prominent Debian Developers, including AJ, did pay for two of the
release managers to work full-time for approximately a month at a
time, at the end of 2006.  This was actually highly contentious with
some claiming that it delayed the release because it "demotivated
them".  I know of now hard evidence to prove that the net result was
negative, and certainly during the period when the two release
managers were paid, the RC bug count did decline quite significantly,
and you can see a significant difference in the slope and sign of the
derivitive of the RC bug count before and after that period where two
of the RM's were paid.  

Certainly the fact that we did pay them did cause a huge amount of
flaming on various debian mailing lists, which perhaps might have
delayed the release, but my personal opinion is that DD's being DD's,
there would have found some other topic to flame about, whether it was
license issues, or whether to expel a particular DD, or something
else  So I believe the paying RM's was a net positive, and there
are those who would disagree with me.  (And to be fair, I need to
disclose that I was one of the people who helped to organize
dunc-tank.)

The harder problem, though is that finding a really good project
manager.  In my day job, I can tell you have as a technical architect,
having a great project manager is like pure gold.  My project manager
defers to me on technical issues, but helps to coordinate all of the
other technical teams so that we can make all of the schedules line up
and release a coherent solution to the customer.  Not to denigrate the
efforts of the current release management team, but if we were to
augment (NOT replace!) them with a good project manager, we could make
them be far more effective.

- Ted


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

Bug#413049: ITP: pynifti -- Python interface to the NIfTI I/O libraries

[Michael Hanke]

Package: wnpp
Severity: wishlist
Owner: Michael Hanke <[EMAIL PROTECTED]>


* Package name: pynifti
  Version : 0.20070301.1
  Upstream Author : Michael Hanke <[EMAIL PROTECTED]> (that is me)
* URL : http://www.example.org/
* License : LGPL
  Programming Lang: Python
  Description : Python interface to the NIfTI I/O libraries

Using PyNIfTI one can easily read and write NIfTI and ANALYZE images from
within Python. The NiftiImage class provides Python-style access to the full
header information. Image data is made available via NumPy arrays.

http://apsy.gse.uni-magdeburg.de/main/index.psp?page=hanke/pynifti&lang=en

Cheers,

Michael


-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (600, 'testing'), (200, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-k7
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050


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

What is available at early userspace?

[Henrique de Moraes Holschuh]

On Thu, 01 Mar 2007, Nikita V. Youshchenko wrote:
> Sorry Marco, but it is not valid to close a bug report that describes an 
> existing issue only because you don't like the solution suggested by the 
> submitter.

Agreed, actually.  But this is bigger than udev, it probably belongs in
"general", and not just one or two packages.

> Udev startup script does operate in restricted environment, where not all 
> system services are already up and running. And it should be written as 
> such.

So far so good.  Udev really will have to somehow know when it is being run
at coldplug and very early userspace setup, and use a subset of the scripts.

> For ages, there was an agreement related to non-local auth services, that 
> everything that is referenced before network service is up, should be 
> resolvable by local data. 'Resolvable' here means that the result (being 
> it positive or negative) should be available locally, without attempts to 
> request data from not-yet-available service.

So far so good.  This is basic.

> And in the current situation, udev is *the* package that, by installing 
> it's default configuration files, injects references to 
> non-resolvable-locally users and groups into early stage of boot.

Wrong.  Your expectations to what is allowed to be non-resolvable-locally
are not in sync with what Debian currently supports.  Note: I am not telling
you your expectations are unreasonable, but that they are more than what we
can properly support right now.  And this is NOT just a bug in udev.

With async userspace, and more imporantly, async userspace boot, we need to
have things properly setup much earlier because we don't (currently) really
know when yhey will be needed.  Udev is just one of the things that are part
of it.  Dependency-based booting is another one.

The bottom line is that, until we define *exactly* what early userspace can
and cannot do, so that we can implement async userspace a lot more sanely,
any system which cannot work standalone until network is up and running is
going to break.  And udev cannot really be expected to do much more than
what it already does unless we define the early userspace.

> So a *fix* for this issue could be only inside udev package.

No.  In fact, a proper fix needs to be Debian-wide, a number of packages may
need to be changed to do it right.  Udev is probably one of them, but not
the only one.

> - if base-passwd will be used as workaround location, this will create a 
> situation when changes to default udev configuration files, introducing 
> references to new groups or removing references to old ones, will cause 
> need of base-files update - which is increased complexity and will cause 
> out-of-sync situations;

This will be fixed when we know what early userspace can and cannot do, and
thus udev will know to which groups it must restrict itself.  And probably
some way to defer rules from running while in early userspace could be
implemented, as well.

Note that we may end up defining that early userspace must restrict itself
to *static* system users and groups.  That likely will require an increase
in the number of static system users and groups.

> - workaround at libnss-* level is complex (see all that logic with files 
> noting boot process etc), needed in any libnss-* that references network, 

Whatever we do, there is no magic here.  Important system resources (users
and groups) that are needed at early userspace must *NOT* depend on anything
that is not provided by the initrd (or the kernel itself plus the root
partition), and that's it.  You can *override* them later, so that, e.g.,
you can add a lot more stuff to group "sound" when network comes up.

libnss-* modules that need something more than what the
kernel/initrd/intramfs/whatever provides must not be active until the
resources they need are available.  This is probably a big bad bug on most
of the libnss-* modules and their packaging, or maybe we should be swapping
/etc/nsswitch.conf around during boot.

> and generally misplaced - because, unlike udev init script, nss is not a 
> system designed for restricted environment, and it is not it's job to 

It has to be designed to work on restricted environments, because it is
running as soon as anything linked to libc needs it.  That doesn't mean we
are using it correctly.

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


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

Re: Bug#412989: udev startup script prints a lot of errors when ldap is used

[Nikita V. Youshchenko]

reopen 412989
thanks

> > I think that correct solution for the issue is to make udev package to
> > create (in local /etc/groups) all missing groups referenced in it's
> > default configuration files.
>
> I don't.
> If you believe that some users or groups need to be unconditionally
> created please discuss this with the base-passwd maintainer.
> (Or feel free to propose a different solution which does not involve the
> udev package creating users/groups which are used by different
> packages.)

Sorry Marco, but it is not valid to close a bug report that describes an 
existing issue only because you don't like the solution suggested by the 
submitter.

There could be different solutions for the issue.
- base-passwd could include all groups that udev references;
- libnss-ldap (and likely other network nss modules) could enhance 
it's 'early bootup' handling such that it will just fail silently if it 
can't connect to LDAP server;
- it is possible to make local admins to create these groups manually.

However, I think there are reasons to fix the issue inside udev package.
I will try to write my reasoning below.
If you don't agree, I believe we should ask people on -devel, and/or 
tech-ctte, to resolve this.


Udev startup script does operate in restricted environment, where not all 
system services are already up and running. And it should be written as 
such.

For ages, there was an agreement related to non-local auth services, that 
everything that is referenced before network service is up, should be 
resolvable by local data. 'Resolvable' here means that the result (being 
it positive or negative) should be available locally, without attempts to 
request data from not-yet-available service.

And in the current situation, udev is *the* package that, by installing 
it's default configuration files, injects references to 
non-resolvable-locally users and groups into early stage of boot.

So a *fix* for this issue could be only inside udev package.
In all other places, only workarounds are possible.
And these workarounds do have the following drawbacks.

- if base-passwd will be used as workaround location, this will create a 
situation when changes to default udev configuration files, introducing 
references to new groups or removing references to old ones, will cause 
need of base-files update - which is increased complexity and will cause 
out-of-sync situations;

- workaround at libnss-* level is complex (see all that logic with files 
noting boot process etc), needed in any libnss-* that references network, 
and generally misplaced - because, unlike udev init script, nss is not a 
system designed for restricted environment, and it is not it's job to 
guess at which points of boot process errors are ok, and at which they are 
errors;

- forcing local admins to manually workaround issue that could be fixed is 
against Debian quality standards.

Also, it is unclear what udevd is going to do with non-resolved groups. 
Likely it will create devices with invalid ownership. Won't that introduce 
breakage at unexpected moments? E.g. if a package that actually uses 
device (and creates a group if it does no exist) will be installed and 
used before next reboot.


From the other hand, fix at udev level is relatively easy.
It just should extract a list of referenced groups (and probably users) 
from config files at build time (not at install time, because the talk is 
only groups referenced in default configs), and add several lines to 
postinst to create these groups if they don't exist.


pgpHYHWcRNl9N.pgp
Description: PGP signature

Tumri.com: 25% Higher Commissions Through March

[Tumri.com: The Web's Leading Merchandising Network]

We are Tumri.com, the Next Generation of Performance Marketing.

>From now until April 1, earn 25% higher commissions for first $500 earned.

You can generate more revenue more frequently from your website through a truly 
innovative new offering called the Tumri CornerStore.

·   Sell merchandise from 2000+ merchants across 30+ categories.

·Earn more revenue from higher clicks and conversions.

·Receive more frequent payments than other revenue share programs - once 
every 15 days.

·Implement once and let automation refresh the latest and greatest relevant 
offers -   "Set It and Forget It."

·View real-time reports to measure performance.

·Receive superior, personal customer support.

To learn more, go to http://www.tumri.com/publishers/createowncornerstore.htm. 
Or to join the internet's leading Merchandising Network, sign up at 
http://publisher.tumri.net.

We look forward to hearing from you and discussing Tumri’s unique value 
proposition in detail. You can reach us via e-mail at [EMAIL PROTECTED] or by 
phone at 650-265-2260 x2001.

Sincerely,

The Publisher Development Team
Tumri, Inc., www.tumri.com
650-265-2260 x2001


If you do not wish to receive future advertising emails from Tumri.com, simply 
reply with this email to [EMAIL PROTECTED]

 
©2007 Tumri, Inc.® All rights reserved.
1975 West El Camino Real, Mountain View, CA 94040

Bug#413022: ITP: oflib -- OpenFirmware device-tree parsing library

[Julien BLACHE]

Package: wnpp
Severity: wishlist
Owner: Julien BLACHE <[EMAIL PROTECTED]>


* Package name: oflib
  Version : git snapshot of the day
  Upstream Author : Alastair Poole <[EMAIL PROTECTED]>
* URL : http://git.sipsolutions.net/of-lib.git/
* License : GPL
  Programming Lang: C
  Description : OpenFirmware device-tree parsing library

 oflib is a library designed to make the parsing of POWER and SPARC
 device-tree's (OpenFirmware) simple and fast.
 .
 It is useful for querying the hardware of the current system in applications
 for Apple, IBM and SUN machines.

JB.

-- 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.20
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

ITH: uclibc

[Simon Richter]

Hello,

I intend to hijack the uclibc package.

uclibc is a small libc that is primarily used in embedded systems. The
last upload was in 2005, the package currently has 4 RC bugs and is
unlikely to release with etch in the current shape (although it is used
by Ubuntu nearly unmodified as far as I can see).

I plan to make the package cross-buildable for all of Debian's official
plus a few unofficial architectures (armeb for example), split each
library into its own package in order to save space when installing on
an embedded system and change the SONAMEs so the package can be
installed in parallel with glibc.

Does anyone object?

   Simon


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

Bug#413017: ITP: haskell-hsh -- Library to mix shell scripting with Haskell programs

[John Goerzen]

Package: wnpp
Severity: wishlist
Owner: John Goerzen <[EMAIL PROTECTED]>

* Package name: haskell-hsh
  Version : 1.0.0
  Upstream Author : John Goerzen <[EMAIL PROTECTED]>
* URL : http://software.complete.org/hsh
* License : LGPL
  Programming Lang: Haskell
  Description : Library to mix shell scripting with Haskell programs

 HSH is designed to let you mix and match shell expressions with
 Haskell programs. With HSH, it is possible to easily run shell
 commands, capture their output or provide their input, and pipe them
 to/from other shell commands and arbitrary Haskell functions at will.

There are some examples posted on the website already.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-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: On maintainers not responding to bugs

[Eduard Bloch]

#include 
* Josselin Mouette [Thu, Mar 01 2007, 02:46:02PM]:
> Le jeudi 01 mars 2007 à 14:33 +0100, Eduard Bloch a écrit :
> > > I'm not the one who said maintainers don't admit they need help.
> > 
> > And I am not the one who said that Mozilla/KDE/GNOME have enough
> > manpower. 
> 
> Who said that?

Somebody in another subthread maybe. I don't care. It is not in
Message-ID: <[EMAIL PROTECTED]>
or in the other mails in that subthread, looking at References: <[EMAIL 
PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL 
PROTECTED]> <[EMAIL PROTECTED]>  <[EMAIL PROTECTED]>.

OTOH you answered to my message pretending that I have said that crap.
Maybe you refered to some of those stories and just picked my mail to
answer while being inspired by other rants. Whatever. It's your
problem if you cannot follow the discussion flow, not mine.

> > Don't put words into my mouth.
> 
> How about these words:
> And how do you help a maintainer that does not admit that he
> needs help?
> 
> Are they yours, or not? If not, you should consider signing your emails,
> as someone is trying to fake you on mailing lists.

Would you please copy the quoted part to restore the context and then
try to judge without emotions? Please. This part refers to the cases
where maintainers actually _refuses_ help and not the cases where help
is appreciated.

Eduard.

-- 
 *prust*
 #, fuzzy
 msgid "Failed"
 msgstr "Weiblich"


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

Re: On maintainers not responding to bugs

[cobaco (aka Bart Cornelis)]

On Thursday 01 March 2007, Pierre Habouzit wrote:
> On Thu, Mar 01, 2007 at 03:20:24PM +0100, cobaco (aka Bart Cornelis) 
wrote:
> > On Thursday 01 March 2007, Josselin Mouette wrote:
> > > Le jeudi 01 mars 2007 à 14:33 +0100, Eduard Bloch a écrit :
> > > > > I'm not the one who said maintainers don't admit they need help.
> > > >
> > > > And I am not the one who said that Mozilla/KDE/GNOME have enough
> > > > manpower.
> > >
> > > Who said that?
> > >
> > > > Don't put words into my mouth.
> > >
> > > How about these words:
> > > And how do you help a maintainer that does not admit that he
> > > needs help?
> > >
> > > Are they yours, or not? If not, you should consider signing your
> > > emails, as someone is trying to fake you on mailing lists.
> >
> > flaw in your logic:
> >
> > the quoted part does not say maintainers have enough manpower,
> > it only says that they haven't expressed the need for more manpower,or
> > at least not in a forum followed by the potential helper.
>
>   No it says that they refuse to acknowledge they need help, which they
> did many times. Maybe my english is flawed, but "to not admit sth"
> implicates active denial in my understanding. 

From gcide:

Admit \Ad*mit"\, v. t. [imp. & p. p. Admitted; p. pr. & vb. n.
   Admitting.] [OE. amitten, L. admittere, admissum; ad +
   mittere to send: cf. F. admettre, OF. admettre, OF. ametre.
   See Missile.]

   4. To concede as true; to acknowledge or assent to, as an
  allegation which it is impossible to deny; to own or
  confess; as, the argument or fact is admitted; he admitted
  his guilt.
  [1913 Webster]

or in other words an admission is an explissive confirmation of a fact. Not 
giving explissive confirmation (that he knows of) does not imply denial.

(it helps if you think of the word in a non-courtroom setting; 
 e.g. a reporter asks if it's true that X, if you reply 'no comment' you've
 not admitted X is true, but neither have you said X is false)

> As a member of such teams, and co-issuer of help requests statements on
> user lists (debian-kde@) I did felt quite itched by Eduard statement.

I can see how if you read it that way...

being an optimist, I choose to always interpret statements in the 
non-offensive interpretation even when that interpretation is non-obvious.
That way I both don't feel offended, and I avoid unnecessary bad feelings 
when no offense was intended.
On the other hand I find that when offense was intended, taking the positive 
interpretation, really annoys those trying to offend (and doing so without 
me having to descend to flaming back :)
-- 
Cheers, cobaco (aka Bart Cornelis)


pgpXtt2ZYOiot.pgp
Description: PGP signature

Re: On maintainers not responding to bugs

[Josselin Mouette]

Le jeudi 01 mars 2007 à 09:22 -0500, Greg Folkert a écrit :
> Lets all start the "Pile-On Joss" thing again and watch him explode.

Still talking to yourself?

> Hi Joss! How are you doing? Hope you are well!

Fine, I like clowns so much.

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

Re: On management

[Turbo Fredriksson]

Quoting Josselin Mouette <[EMAIL PROTECTED]>:

> As of now, I see it as a failure of the project. But this is also
> nothing that can't be fixed. What do you people think could be done to
> bring the skills we are lacking to the project, with its current
> structure?

Since I agree (well, more than agree - I think it's absolutly vital :),
how about actually PAYING them? Get one or two professionals and pay
them (halftime perhaps)...

I have no idea how the economy looks, but would there be room for
such a thing?


-- 
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 Thu, Mar 01, 2007 at 03:20:24PM +0100, cobaco (aka Bart Cornelis) wrote:
> On Thursday 01 March 2007, Josselin Mouette wrote:
> > Le jeudi 01 mars 2007 à 14:33 +0100, Eduard Bloch a écrit :
> > > > I'm not the one who said maintainers don't admit they need help.
> > >
> > > And I am not the one who said that Mozilla/KDE/GNOME have enough
> > > manpower.
> >
> > Who said that?
> >
> > > Don't put words into my mouth.
> >
> > How about these words:
> > And how do you help a maintainer that does not admit that he
> > needs help?
> >
> > Are they yours, or not? If not, you should consider signing your emails,
> > as someone is trying to fake you on mailing lists.
> 
> flaw in your logic:
> 
> the quoted part does not say maintainers have enough manpower, 
> it only says that they haven't expressed the need for more manpower,or at 
> least not in a forum followed by the potential helper.

  No it says that they refuse to acknowledge they need help, which they
did many times. Maybe my english is flawed, but "to not admit sth"
implicates active denial in my understanding.  As a member of such
teams, and co-issuer of help requests statements on user lists
(debian-kde@) I did felt quite itched by Eduard statement.

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


pgpnWteLu66vy.pgp
Description: PGP signature

Re: On maintainers not responding to bugs

[Greg Folkert]

On Thu, 2007-03-01 at 14:46 +0100, Josselin Mouette wrote:
> Le jeudi 01 mars 2007 à 14:33 +0100, Eduard Bloch a écrit :
> > > I'm not the one who said maintainers don't admit they need help.
> > 
> > And I am not the one who said that Mozilla/KDE/GNOME have enough
> > manpower. 
> 
> Who said that?
> 
> > Don't put words into my mouth.
> 
> How about these words:
> And how do you help a maintainer that does not admit that he
> needs help?
> 
> Are they yours, or not? If not, you should consider signing your emails,
> as someone is trying to fake you on mailing lists.

Lets all start the "Pile-On Joss" thing again and watch him explode.

Hi Joss! How are you doing? Hope you are well!
-- 
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

Re: On maintainers not responding to bugs

[cobaco (aka Bart Cornelis)]

On Thursday 01 March 2007, Josselin Mouette wrote:
> Le jeudi 01 mars 2007 à 14:33 +0100, Eduard Bloch a écrit :
> > > I'm not the one who said maintainers don't admit they need help.
> >
> > And I am not the one who said that Mozilla/KDE/GNOME have enough
> > manpower.
>
> Who said that?
>
> > Don't put words into my mouth.
>
> How about these words:
> And how do you help a maintainer that does not admit that he
> needs help?
>
> Are they yours, or not? If not, you should consider signing your emails,
> as someone is trying to fake you on mailing lists.

flaw in your logic:

the quoted part does not say maintainers have enough manpower, 
it only says that they haven't expressed the need for more manpower,or at 
least not in a forum followed by the potential helper.
-- 
Cheers, cobaco (aka Bart Cornelis)


pgpQBodoPlXwM.pgp
Description: PGP signature

Re: On maintainers not responding to bugs

[Eduard Bloch]

#include 
* Mike Hommey [Wed, Feb 28 2007, 07:52:44PM]:
> On Wed, Feb 28, 2007 at 07:26:24PM +0100, Josselin Mouette <[EMAIL 
> PROTECTED]> wrote:
> > Le mercredi 28 février 2007 à 18:00 +0100, Sam Hocevar a écrit :
> > > On Wed, Feb 28, 2007, Eduard Bloch wrote:
> > > > But it seems like you maintain only few simple packages.
> > > 
> > >Did you really just say that to Loïc Minier?

Well. Double looking on how Loïc, Josselin and me are related to each
other I guess I see the problem. The problem is: knowledge is result of
perception. You both are in the same team, you see the activity of each
other much more than outsiders, especially people like me who don't come
in touch with Gnome packaging regularly.

And I think more should try to imagine the perspective of other people
sometimes before joining a flame war. But I am not a prima donna either.

> > Hey, that's true. He maintains many complicated packages, but only few
> > simple ones.
> 
> I guess Eduard looked at
> http://qa.debian.org/developer.php?login=lool
> which implies he maintains only few simple packages and sponsor a lot,
> rather than
> http://qa.debian.org/[EMAIL PROTECTED]

You got it.

Eduard.

-- 
Frisch erhält sich nur eine Liebe, der auch ein bißchen Kühle
beigemischt ist.
-- Michèle Morgan (eig. Simone Roussel)


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

Re: On maintainers not responding to bugs

[Eduard Bloch]

#include 
* Josselin Mouette [Wed, Feb 28 2007, 09:08:42AM]:
> Le mercredi 28 février 2007 à 02:02 +0100, Eduard Bloch a écrit :
> > #include 
> > * Josselin Mouette [Tue, Feb 27 2007, 10:30:39AM]:
> > > Le mardi 27 février 2007 à 09:24 +0100, Eduard Bloch a écrit :
> > > > And how do you help a maintainer that does not admit that he needs help?
> > > 
> > > I can't believe people are thinking such crap.
> > > 
> > > Please show me where a current maintainer of Mozilla, KDE, GNOME, the
> > > glibc, the kernel, X.org or any such big group of packages said he
> > > didn't need help for them.
> 
> > > Who is not acknowledging such obvious things?
> > 
> > Dunno. I think you confused the subthreads when replying here.
> > As usual somebody needs to make the hands dirty and deal with the old
> > odd bug reports. And yes, I know that my talk here does not help but I
> > have no time to help either so I am stopping here.
> 
> I'm not the one who said maintainers don't admit they need help.

And I am not the one who said that Mozilla/KDE/GNOME have enough
manpower. Don't put words into my mouth.

Eduard.
-- 
 maxx: Testing hat den Anspruch, jederzeit im Release-Fertigen Zustand
zu sein.


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

Re: On maintainers not responding to bugs

[Josselin Mouette]

Le jeudi 01 mars 2007 à 14:33 +0100, Eduard Bloch a écrit :
> > I'm not the one who said maintainers don't admit they need help.
> 
> And I am not the one who said that Mozilla/KDE/GNOME have enough
> manpower. 

Who said that?

> Don't put words into my mouth.

How about these words:
And how do you help a maintainer that does not admit that he
needs help?

Are they yours, or not? If not, you should consider signing your emails,
as someone is trying to fake you on mailing lists.

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

Re: [Fwd: Bug#412952: file conflicts between afnix and aleph]

[Frank Küster]

Michael Koch <[EMAIL PROTECTED]> wrote:

> Add this to afnix:
>
> Conflicts: aleph
> Replaces: aleph
>
> This should make it possible to have always one of them installed and
> make afnix replace aleph on dist-upgrades.

Isn't 

Provides: aleph

also needed?

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

Bug#412969: ITP: xen-shell -- Console based Xen administration utility

[Radu Spineanu]

Package: wnpp
Severity: wishlist
Owner: Radu Spineanu <[EMAIL PROTECTED]>


* Package name: xen-shell
  Version : 0.9
  Upstream Author : Steve Kemp <[EMAIL PROTECTED]>
* URL : http://xen-tools.org/software/xen-shell/releases.html
* License : Perl: GPL/Artistic
  Description : Console based Xen administration utility

 Using the xen-shell a hosting company could easily allow their customers
 to fully manage inidividual Xen guest instances.
 .
 The shell allows users to start, stop, reboot, or connect to the serial
 console of their Xen guest isntance.
 .
 Homepage: http://xen-tools.org/software/xen-shell

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


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

Re: Thank you

[reeshma r]

**

*Are you searching for a Partner? / For you / your Son/ Daughter/ Sister/
Brother/ Relative / Friend / Neighbor?*



Forget all your troubles, Discard all your worries. Here is happy news for
you!



We welcome you to *m4me.com*. Let us introduce ourselves.



*m4me.com* is a private and confidential internet matchmaking website, which
is dedicated to help you in finding your ultimate match, especially for
keralites.



We specially welcome members of malayali origin from all around the world by
using the latest in technology.



*m4me.com* provides a suitable, easy, low-cost high-tech web technology
services for saving your time, money, energy which are valuable things in
life.



Marriage is opening a *NEW BOOK* in your life. For that



   [X] Stop *WASTING* more money towards finding a *PERFECT* partner

   [X] Stop *SPENDING* more time towards searching a *SUITABLE* partner

   [X] Stop *COLLECTING* unwanted information about a partner of your *
DREAMS*

   [X] Stop *SUFFERING* endless loneliness until you find a *RIGHT* partner

   [X] Stop *CORRESPONDING* endlessly for finding your *ULTIMATE* partner

   [X] Stop *WORRYING* about *MARRIAGE*



Join *m4me.com*!  Get married!   Open your *NEW BOOK* in life





*100% free Registration offer*

*HELP Line no:0480 3201978 [24 Hour Service]*





Please go through *m4me.com *for further details.







Visit us at: -* **www.m4me.com*

*Kerala's Ultimate Match Finder** ***

* *


*Thanking you,**  ***

[EMAIL PROTECTED]
***

Re: [Fwd: Bug#412952: file conflicts between afnix and aleph]

[Michael Koch]

On Thu, Mar 01, 2007 at 09:14:42AM -, Paul Cager wrote:
> Could I have some advice about the best way to fix this one please? Here's
> a summary:
> 
> * The obsolete package "aleph" is supserseded by "afnix".
> * I've requested the removal of aleph from unstable (bug #389163).
> * There is already another RC bug against "aleph", as it conflicts with
> tetex-bin.
> 
> I didn't make afnix "Replaces:" aleph because aleph is scheduled for
> removal. I guess I should have done? What would be best - uploading a new
> version of  afnix, or marking this bug as blocked by 389163?

Add this to afnix:

Conflicts: aleph
Replaces: aleph

This should make it possible to have always one of them installed and
make afnix replace aleph on dist-upgrades.


Cheers,
Michael
-- 
 .''`.  | Michael Koch <[EMAIL PROTECTED]>
: :' :  | Free Java Developer 
`. `'   |
  `-| 1024D/BAC5 4B28 D436 95E6 F2E0 BD11 5923 A008 2763 483B


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

[Fwd: Bug#412952: file conflicts between afnix and aleph]

[Paul Cager]

Could I have some advice about the best way to fix this one please? Here's
a summary:

* The obsolete package "aleph" is supserseded by "afnix".
* I've requested the removal of aleph from unstable (bug #389163).
* There is already another RC bug against "aleph", as it conflicts with
tetex-bin.

I didn't make afnix "Replaces:" aleph because aleph is scheduled for
removal. I guess I should have done? What would be best - uploading a new
version of  afnix, or marking this bug as blocked by 389163?

Thanks,
Paul

 Original Message 
Subject: Bug#412952: file conflicts between afnix and aleph
From:"Michael Ablassmeier" <[EMAIL PROTECTED]>
Date:Thu, March 1, 2007 8:00 am
To:  [EMAIL PROTECTED]
--

Package: afnix, aleph
Severity: serious
Justification: file conflicts between packages, policy violation

hi,

both afnix and aleph do ship several files of eachother but do not
conflict or add a diversion, thus fail to be installed on the same
environment:

 Unpacking aleph (from .../aleph_0.9.0-3_amd64.deb) ...
 dpkg: error processing /var/cache/apt/archives/aleph_0.9.0-3_amd64.deb
(--unpack):
  trying to overwrite `/usr/bin/axc', which is also in package afnix
 dpkg-deb: subprocess paste killed by signal (Broken pipe)
 Errors were encountered while processing:
 /var/cache/apt/archives/aleph_0.9.0-3_amd64.deb
 E: Sub-process /usr/bin/dpkg returned an error code (1)

full list of files conflicting:

 'usr/share/man/man1/axc.1.gz'
 'usr/share/man/man1/axl.1.gz'
 'usr/bin/axc'
 'usr/bin/axd'
 'usr/bin/axl'

bye,
- michael



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