Re: [Debian Installer] General release plan for RC1

[Josselin Mouette]

Le mardi 10 octobre 2006 à 07:18 +0200, Tshepang Lekhonkhobe a écrit :
> On 10/8/06, Loïc Minier <[EMAIL PROTECTED]> wrote:
> > On Sun, Oct 08, 2006, Attilio Fiandrotti wrote:
> > > Just today mike emmel fixed the "boom" bug, it should technically
> > > possible switching to GTK+ 2.10.x.
> >
> >  Repeating this here for other readers: 2.10.6-2 in experimental was
> >  uploaded today with the fix.
> 
> So are getting GNOME 2.16 for Etch? Frans Pop scared me a bit saying
> we are stuck with 2.14 :-(

The current plan is to ship GNOME 2.14 in etch [1]. This was a hard
decision to make, but we prefer shipping a rock-solid and polished 2.14
version rather than a buggy 2.16 version with which Ubuntu is having
many issues. 

 [1] http://oskuro.net/blog/freesoftware/gnome-2.16-etch-2006-10-06-21-45
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Call for votes for "GR: : Handling source-less firmware in the Linux kernel"

[NIIBE Yutaka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> c2d43675-9efa-4809-a4aa-af042b62786e
> [ 1 ] Choice 1: Release Etch even with kernel firmware issues
> [ 3 ] Choice 2: Special exception to DFSG2 for firmware as long as
required [3:1]
> [ 2 ] Choice 3: Further discussion
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFKwukBB45r3HV9DoRAjwgAJ99yg1PEWTxnJvc0hrrfjzT72YztgCeL7fd
+9CocuQltueDRD+HhbBiW3k=
=FdGS
-END PGP SIGNATURE-


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

Re: [Debian Installer] General release plan for RC1

[Tshepang Lekhonkhobe]

On 10/8/06, Loïc Minier <[EMAIL PROTECTED]> wrote:

On Sun, Oct 08, 2006, Attilio Fiandrotti wrote:
> Just today mike emmel fixed the "boom" bug, it should technically
> possible switching to GTK+ 2.10.x.

 Repeating this here for other readers: 2.10.6-2 in experimental was
 uploaded today with the fix.


So are getting GNOME 2.16 for Etch? Frans Pop scared me a bit saying
we are stuck with 2.14 :-(

Re: Why weren't the GR voting mails sent to debian-devel-announce?

[Oleksandr Moskalenko]

* Oleksandr Moskalenko <[EMAIL PROTECTED]> [2006-10-09 12:56:03 -0600]:

> According to the chapter 3.3 of the Dev. reference the GR calls for votes
> should've been sent to the debian-devel-announce, but in reality they weren't.
> It seems that the only way to get those would be to subscribe to debian-vote
> or to trawl the debian-vote archives. Why is it so?
> 
> Regards,
> 
> Alex.


Thank you to all who responded. I have learned the error of my ways.

Regards,

Alex.


signature.asc
Description: Digital signature

Re: Why weren't the GR voting mails sent to debian-devel-announce?

[Henrique de Moraes Holschuh]

On Mon, 09 Oct 2006, Oleksandr Moskalenko wrote:
> According to the chapter 3.3 of the Dev. reference the GR calls for votes
> should've been sent to the debian-devel-announce, but in reality they weren't.

They *were* sent to the d-d-a mailinglist, check the archives.

-- 
  "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#391686: ITP: ipw3945-daemon -- Binary userspace regulatory daemon for Intel PRO/Wireless 3945ABG cards

[Jurij Smakov]

On Mon, Oct 09, 2006 at 02:43:55PM -0400, Jim Crilly wrote:
> On 10/09/06 08:38:46AM +0200, Reinhard Tartler wrote:
> > Jim Crilly <[EMAIL PROTECTED]> writes:
> > 
> > > Intel's daemon isn't as bad as the Atheros HAL or nVidia's blob
> > 
> > Could you please elaborat on that? why is ath_hal.ko or nvidia.ko worse
> > than intel's daemon? 
> > 
> > The only real difference is that intel's daemon doesn't run in
> > kernelspace. Why is is that better?
> > 
> 
> For that very reason, if nvidia.ko goes nuts it can scribble all over
> kernel memory and cause anything from random reboots to filesystem
> corruption. But since Intel's daemon runs in userspace if it goes nuts it'll
> just segfault, technically I guess it could open /dev/kmem or /dev/mem but
> the chances of that happening are virtually 0.

Actually, it can't do even that. According to installation 
instructions, it can be run without root privileges, as long as it has 
read/write access to a rather small subset of files in the /sys tree. 
That's how I plan to make it work in the package.

Best regards,

Jurij Smakov   [EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/  KeyID: C99E03CC


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

Re: how to tell people to dpkg-reconfigure exim4-_CONFIG_?

[James R. Van Zandt]

Marc Haber <[EMAIL PROTECTED]> wrote
>   On Mon, 09 Oct 2006 09:23:48 +0200, sean finney <[EMAIL PROTECTED]>
>   wrote:
>   >funny, i'd have said the ultimate solution was finding a way to make the
>   >users learn about looking at README.Debian :)

That is, "they should be paying more attention to this important
package".  The trouble is, the same user has installed 1900 other
packages, and their maintainers think they are important, too.

>   That is unrealistic. I expect our users to get more stupid instead of
>   less stupid.

No, but we have an attention economy, and we should expect our users
to get more distracted.  

The thing I really appreciated about Debian after I first installed it
was that someone else was paying attention (to where the configuration
files went, and what versions of what libraries it depended on, and
what the defaults were...) so that I didn't have to spend an hour
studying how to build and set up each package before I even started on
the user documentation.  In other words, I didn't have to pay as much
attention.

There are a few things we *do* want the user to pay attention to, like
passwords, firewall rules, backups, and what services to export.  We
should not demand that he pay close attention to all 1900 packages.
Or even the "important" ones.

I think that if we can figure out how to get

   dpkg-reconfigure exim4

to actually configure exim4, then we should.

- Jim Van Zandt


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

Re: gids assigned non-deterministically

[Roberto C. Sanchez]

On Mon, Oct 09, 2006 at 02:39:07PM -0500, Peter Samuelson wrote:
> 
> [Roberto C. Sanchez]
> > That is a problem if I want to server everything up out of LDAP.
> > There really should be a "reserved" range, maybe 100-499 of Debian
> > gids, where they are assigned in a predertmined way.
> 
> I don't think it's a good idea to put system users and groups into LDAP
> anyway.  They are specific to a system.  There is nothing wrong with
> having regular users and groups in LDAP and system users and groups in
> /etc/passwd.  This is, in fact, probably the common case.

I do want the system groups in /etc/group.  However, I would like to
"override" or supplement the group membership with information out of
LDAP.  For example, in /etc/group:

camera:x:120:foo

And then in LDAP, have a group cn=camera,ou=Group,dc=example,dc=org with
bar as a member.  Assuming that foo is a local user account on the
system in question and bar is in the directory, that should work out.  I
have already tested that and the system sees bar as a member of camera
if he logs in.  However, the real speed bump in this is that the gids
are assigned based on what order the packages are installed.  So, camera
has gid 120 on one system and 104 on the other.  I don't imagine that it
is generall a problem,  However, if any files are on shared storage and
end up bearing the gid of any of these groups where the gids are not
uniform across systems, then the user may or may not have access to them
based on which machines he is using at the moment.  All I am saying, is
that there should be some sort of uniformity to it.

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: anticipating the upstart migration

[Alex Pennace]

On Sun, Oct 08, 2006 at 10:16:51PM +0200, Hendrik Sattler wrote:
> I propose another solution. Introduce init-common with wrappers:
> * /sbin/init is a binary that
>   - reads a configuration file with the init system name  and
>   - creates a file /var/run/inittype (or whereever is can be stored at that 
> time) with the same value and

/var may be a seperate file system, unmounted at that stage of booting.


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

Re: Why weren't the GR voting mails sent to debian-devel-announce?

[Daniel Martin]

Oleksandr Moskalenko <[EMAIL PROTECTED]> writes:

> According to the chapter 3.3 of the Dev. reference the GR calls for votes
> should've been sent to the debian-devel-announce, but in reality they weren't.
> It seems that the only way to get those would be to subscribe to debian-vote
> or to trawl the debian-vote archives. Why is it so?

They weren't?  I got them, automatically filed in my
debian-devel-announce folder, and I'm not subscribed to debian-vote.

I suspect a local, rather than systemic, failure.


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

Re: Why weren't the GR voting mails sent to debian-devel-announce?

[Manoj Srivastava]

On Mon, 9 Oct 2006 12:56:03 -0600, Oleksandr Moskalenko <[EMAIL PROTECTED]> 
said: 

> According to the chapter 3.3 of the Dev. reference the GR calls for

The dev ref is not authoritative on voting procedure.

> votes should've been sent to the debian-devel-announce, but in
> reality they weren't.

Well, your reality differs from mine.  Perhaps you could ask
 the secretary in whatever reality you live in to resend things to
 d-d-a? It has already been done in my reality.


> It seems that the only way to get those would be to subscribe to
> debian-vote or to trawl the debian-vote archives. Why is it so?

I think such metaphysical questions of why phenomena differ
 between realities are interesting, but might be off topic for debian.

manoj
-- 
They don't make nostalgia like they used to.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Why weren't the GR voting mails sent to debian-devel-announce?

[Adam D. Barratt]

On Mon, 2006-10-09 at 12:56 -0600, Oleksandr Moskalenko wrote:
> According to the chapter 3.3 of the Dev. reference the GR calls for votes
> should've been sent to the debian-devel-announce, but in reality they weren't.
> It seems that the only way to get those would be to subscribe to debian-vote
> or to trawl the debian-vote archives. Why is it so?

They *were* sent to d-d-a. Each mail has

To: 
debian-devel-announce@lists.debian.org, debian-vote@lists.debian.org

and is archived at
http://lists.debian.org/debian-devel-announce/2006/10/ (or /09/ for the
earlier GRs).

The headers of my copies of each mail also confirm they were sent to a
tagged address subscribed only to d-d-a.

Adam


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

Re: Why weren't the GR voting mails sent to debian-devel-announce?

[Stephen Gran]

This one time, at band camp, Oleksandr Moskalenko said:
> According to the chapter 3.3 of the Dev. reference the GR calls for votes
> should've been sent to the debian-devel-announce, but in reality they weren't.
> It seems that the only way to get those would be to subscribe to debian-vote
> or to trawl the debian-vote archives. Why is it so?

http://lists.debian.org/debian-devel-announce/2006/10/msg{4,5,6,7}.html

I guess you just missed them?
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: gids assigned non-deterministically

[Roberto C. Sanchez]

On Mon, Oct 09, 2006 at 07:09:14PM +0200, Andreas Metzler wrote:
> Roberto C. Sanchez <[EMAIL PROTECTED]> wrote:
> > I have started working with transitioning a network to LDAP.  I am still
> > experimenting with this at home before implementing it "for real."  This
> > brings me to my concern.  It appears that many groups are added to the
> > system "willy-nilly."  By that I mean, I have one system where part of
> > the /etc/group file looks like this:
> 
> > gdm:x:101:
> > man:x:12:
> > sasl:x:45:
> > ssh:x:102:
> [...]
> 
> > On another system, it looks like this:
> 
> > gdm:x:101:
> > sword:x:102:
> [...]
> 
> > For instance, on one system the camera group has gid 111 and 113 on the
> > other.
> 
> See http://www.at.debian.org/doc/debian-policy/ch-opersys.html#s9.2.2
> 
I will take a look at this.

> > That is a problem if I want to server everything up out of LDAP.
> 
> Either install the packages which dynamically add system users on a master
> machine first and set them up and export them in LDAP (they won't be
> re-generated on the client machines if the user already is present) or do
> not keep system users in LDAP.

You mention users, but does the same work for groups?  If so, I can just
whip up a quick script using `find / -group $foo` for all the groups
whose gids I want to harmonize.  Once that finishes, I can just export
the groups via LDAP and remove them entirely from the local machines.

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: Stuff the installer does which isn't done on upgrade....

[Petter Reinholdtsen]

[Theodore Tso]
> The e2fsprogs-udeb package does include the mke2fs.conf file, so if
> the installer is using the latest e2fsprogs-udeb, it should be
> creating filesystems with the dir_index and resize_inode features.

Soon the etch installer is using the latest mkfs.ext3 to create the
file system.  debian-installer beta3 use libparted + tune2fs -j, and
this fail to enable both these features.

I really happy to know that d-i in sid now creates online re-sizable
file systems.

Friendly,
-- 
Petter Reinholdtsen


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

Re: ftp upload queue?

[Laszlo Boszormenyi]

On Sun, 2006-10-08 at 22:42 -0700, Thomas Bushnell BSG wrote:
> Aurélien GÉRÔME <[EMAIL PROTECTED]> writes:
> > As soon as I send a mail, the deamon restarts... Good news! ;)
> Yep.  Thanks magic elves!
 Then please help again elves! :-) The daemon is down again. :(

Cheers,
Laszlo/GCS


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

Re: gids assigned non-deterministically

[Peter Samuelson]

[Roberto C. Sanchez]
> That is a problem if I want to server everything up out of LDAP.
> There really should be a "reserved" range, maybe 100-499 of Debian
> gids, where they are assigned in a predertmined way.

I don't think it's a good idea to put system users and groups into LDAP
anyway.  They are specific to a system.  There is nothing wrong with
having regular users and groups in LDAP and system users and groups in
/etc/passwd.  This is, in fact, probably the common case.


signature.asc
Description: Digital signature

Debian arch and package survey update

[Petter Reinholdtsen]

The number of machines reporting to popcon.debian.org continues to
grow.  This is great.  There are now 17338 machines reporting their
statistics. The package usage stats are used to order the packages on
the CDs and DVDs, among other things.

This is the current architecture distribution:

  1   0.01% kfreebsd-amd64
  1   0.01% ppc64
  2   0.01% i486
  3   0.02% hurd-i386
 11   0.06% m68k
 11   0.06% kfreebsd-i386
 16   0.09% armeb
 17   0.10% mips
 19   0.11% s390
 23   0.13% mipsel
 31   0.18% ia64
 50   0.29% hppa
 57   0.33% alpha
135   0.79% sparc
265   1.55% powerpc
343   2.01% arm
   1595   9.35% amd64
  14480  84.88% i386
  17060 100.00% total (ignored 278 without arch info)

If you want more numbers, check out http://popcon.debian.org/>.
If you want to participate, please install the popularity-contest
package.  The Etch release scheduled for early December will be the
first release with popularity-contest participation being requested by
the default installer.  I look forward to see how that will affect the
number of submitters when Etch become stable. :)

Friendly,
-- 
Petter Reinholdtsen


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

Why weren't the GR voting mails sent to debian-devel-announce?

[Oleksandr Moskalenko]

According to the chapter 3.3 of the Dev. reference the GR calls for votes
should've been sent to the debian-devel-announce, but in reality they weren't.
It seems that the only way to get those would be to subscribe to debian-vote
or to trawl the debian-vote archives. Why is it so?

Regards,

Alex.


signature.asc
Description: Digital signature

Re: Allowing @ in user names?

[Christian Perrier]

Quoting Marc Haber ([EMAIL PROTECTED]):

> After having this discussed here, I am now inclined to allow @ in user
> names if --force-badname was given or NAME_REGEX was configured
> appropriately.
> 
> I'll make that change thursday evening unless some new arguments were
> shown here.
> 


I've just checked that this is supported in useradd (which you
probably did also) so you can
probably go ahead.

Christian, with his shadow (thus passwd, thus useradd) hat ON.




signature.asc
Description: Digital signature

Re: Bug#391686: ITP: ipw3945-daemon -- Binary userspace regulatory daemon for Intel PRO/Wireless 3945ABG cards

[Jim Crilly]

On 10/09/06 08:38:46AM +0200, Reinhard Tartler wrote:
> Jim Crilly <[EMAIL PROTECTED]> writes:
> 
> > Intel's daemon isn't as bad as the Atheros HAL or nVidia's blob
> 
> Could you please elaborat on that? why is ath_hal.ko or nvidia.ko worse
> than intel's daemon? 
> 
> The only real difference is that intel's daemon doesn't run in
> kernelspace. Why is is that better?
> 

For that very reason, if nvidia.ko goes nuts it can scribble all over
kernel memory and cause anything from random reboots to filesystem
corruption. But since Intel's daemon runs in userspace if it goes nuts it'll
just segfault, technically I guess it could open /dev/kmem or /dev/mem but
the chances of that happening are virtually 0.

Jim.


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

Re: gids assigned non-deterministically

[Andreas Metzler]

Roberto C. Sanchez <[EMAIL PROTECTED]> wrote:
> I have started working with transitioning a network to LDAP.  I am still
> experimenting with this at home before implementing it "for real."  This
> brings me to my concern.  It appears that many groups are added to the
> system "willy-nilly."  By that I mean, I have one system where part of
> the /etc/group file looks like this:

> gdm:x:101:
> man:x:12:
> sasl:x:45:
> ssh:x:102:
[...]

> On another system, it looks like this:

> gdm:x:101:
> sword:x:102:
[...]

> For instance, on one system the camera group has gid 111 and 113 on the
> other.

See http://www.at.debian.org/doc/debian-policy/ch-opersys.html#s9.2.2

> That is a problem if I want to server everything up out of LDAP.

Either install the packages which dynamically add system users on a master
machine first and set them up and export them in LDAP (they won't be
re-generated on the client machines if the user already is present) or do
not keep system users in LDAP.
cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.(c) Jasper Ffforde


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

gids assigned non-deterministically

[Roberto C. Sanchez]

I have started working with transitioning a network to LDAP.  I am still
experimenting with this at home before implementing it "for real."  This
brings me to my concern.  It appears that many groups are added to the
system "willy-nilly."  By that I mean, I have one system where part of
the /etc/group file looks like this:

gdm:x:101:
man:x:12:
sasl:x:45:
ssh:x:102:
crontab:x:104:
xfntserv:x:103:
postfix:x:105:
Debian-exim:x:106:
uml-net:x:107:
messagebus:x:109:
logcheck:x:108:
lpadmin:x:110:
plugdev:*:46:
camera:x:111:
postdrop:x:112:
scanner:x:113:
saned:x:114:
sword:x:115:

On another system, it looks like this:

gdm:x:101:
sword:x:102:
man:x:12:
sasl:x:45:
ssh:x:103:
crontab:x:105:
xfntserv:x:104:
postfix:x:106:
Debian-exim:x:107:
messagebus:x:109:
logcheck:x:108:
lpadmin:x:110:
plugdev:*:46:
uml-net:x:112:
camera:x:113:
postdrop:x:114:

For instance, on one system the camera group has gid 111 and 113 on the
other.  That is a problem if I want to server everything up out of LDAP.
There really should be a "reserved" range, maybe 100-499 of Debian gids,
where they are assigned in a predertmined way.  For example, of package
foo wants to create a system group, it would need to first be assigned a
gid out of this range.  That way, the order in which packages are
assigned does not make a difference, as for instance, group camera will
always be assigned gid 117, for instance.

I'm not sure if such a thing would be feasible or even possible.
However, it is a rather significant annoyance to come up with a solution
for this that wouldn't take a long time to implement.

I guess that if the deployment were on a new network, it would be easier
to affect how the gids are assigned, since you would be looking for
issues like that.  However, for an existing network, this can be more of
a problem.

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: Help with menu (Was: Bug#389932: wish: gnumed --debug should open terminal window)

[Andreas Tille]

On Mon, 9 Oct 2006, Bill Allombert wrote:


W: gnumed-client-debug: menu-command-not-in-package
/usr/share/menu/gnumed-client-debug:5 x-terminal-emulator

Shouldn't a

 Depends: xterm | x-terminal-emulator

be enough here?  I admit that it might be hard to define a lintian rule
to verify the contents of dependant packages but I wonder whether I should
simply go with a lintian override or file either a wishlist bug against
lintian or perhaps menu-policy?


This is a well-known lintian limitation. This warning is to protect
against typos in command name: say
/usr/lib/menu/xteddy:
?(xteddy): need="x11" section="Games/Toys" title="XTeddy" command="xtedddy"
Lintian will warn you xtedddy is an error


Surely this makes sense.  But if Package depends from an *other*
package that contains /usr/bin/xtedddy this should be overriden,
because lintian would have to use apt-file or whatever to find this
out.  The idea was to educate lintian about the contents of the
virtual package list and keep it silent if the dependencies of
a package contain an executable that is provided by the virtual
package.


Just ignore it or add an override.


It would be so great if we would get some help when #109642 would
be fixed ...
There are so many valid reasons to use overrides.


 Depends: xterm | x-terminal-emulator


Either that or provides two menu entries:

?package(gnumed):needs="X11" section="Apps/Tools" \
 title="GNUmed" command="/usr/bin/gnumed" \
 icon="/usr/share/gnumed/bitmaps/gnumed.xpm" \
?package(gnumed,xterm):needs="X11" section="Apps/Tools" \
 title="GNUmed (Debug)" command="xterm -hold -e gnumed" \
 icon="/usr/share/gnumed/bitmaps/gnumed.xpm" \

The second one will alway be displayed if xterm is installed.


Yea, but we agreed not to depend from a certain package that
provides x-terminal-emulator.

Kind regards

Andreas.
--
http://fam-tille.de


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

Re: Help with menu (Was: Bug#389932: wish: gnumed --debug should open terminal window)

[Bill Allombert]

On Mon, Oct 09, 2006 at 01:33:03PM +0200, Andreas Tille wrote:
> The solution that was suggested by you and Philipp Benner seems to be not
> aware to lintian
> 
> W: gnumed-client-debug: menu-command-not-in-package 
> /usr/share/menu/gnumed-client-debug:5 x-terminal-emulator
> 
> Shouldn't a
> 
>  Depends: xterm | x-terminal-emulator
> 
> be enough here?  I admit that it might be hard to define a lintian rule
> to verify the contents of dependant packages but I wonder whether I should
> simply go with a lintian override or file either a wishlist bug against
> lintian or perhaps menu-policy?

This is a well-known lintian limitation. This warning is to protect
against typos in command name: say
/usr/lib/menu/xteddy:
?(xteddy): need="x11" section="Games/Toys" title="XTeddy" command="xtedddy"
Lintian will warn you xtedddy is an error

Just ignore it or add an override.

>  Depends: xterm | x-terminal-emulator

Either that or provides two menu entries:

?package(gnumed):needs="X11" section="Apps/Tools" \
  title="GNUmed" command="/usr/bin/gnumed" \
  icon="/usr/share/gnumed/bitmaps/gnumed.xpm" \
?package(gnumed,xterm):needs="X11" section="Apps/Tools" \
  title="GNUmed (Debug)" command="xterm -hold -e gnumed" \
  icon="/usr/share/gnumed/bitmaps/gnumed.xpm" \

The second one will alway be displayed if xterm is installed.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#391905: ITP: qt4-qtruby -- ruby bindings for the Qt4 GUI library

[Vincent Fourmond]

Package: wnpp
Severity: wishlist
Owner: Vincent Fourmond <[EMAIL PROTECTED]>

* Package name: qt4-qtruby
  Version : 1.4.6
  Upstream Author : Richard Dale <[EMAIL PROTECTED]>
* URL : http://rubyforge.org/projects/korundum/
* License : GPL
  Programming Lang: C++, Ruby
  Description : ruby bindings for the Qt4 GUI library

Qt4-qtruby provides the ruby bindings for the Qt4 library, along with many 
examples and 
the converted tutorials of Qt4. 

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) (ignored: LC_ALL set to 
en_GB)


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

Vote page locations on the recent call for votes

[Manoj Srivastava]

Hi,

The call for votes sent our recently had a URL for the full
 text that we missing a path segment -- namely, the year. So, the
 correct URL's would be:
 http://vote.debian.org/2006/vote_005
 http://vote.debian.org/2006/vote_006
 http://vote.debian.org/2006/vote_007

A visit to http://vote.debian.org/, or indeed, any pages of
 previous vote, show a navigation bar that highlights current votes;
 so this should not have been hard to find.

manoj
-- 
A newspaper is a circulating library with high blood pressure. Arthure
"Bugs" Baer
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Replacement Superintendent

[Bryan Milton]

How are you,

Would you like to make 1.5K to 3.5K a day just for returning phone calls?
If you have a telephone and can return calls you are fully qualified.

Get in contact with us : 800-845-0218

Respects,
Bryan Milton



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

Re: anticipating the upstart migration

[Henrique de Moraes Holschuh]

On Mon, 09 Oct 2006, Gabor Gombas wrote:
> On Sun, Oct 08, 2006 at 10:53:39PM -0300, Henrique de Moraes Holschuh wrote:
> > No wrappers for the single most critical binary in a Unix system after the
> > libc.  Sorry.
> 
> Right. How about upstart not providing a /sbin/init binary at all, but
> instead using an "init=/sbin/upstart" boot parameter? The other binaries

That may be ugly, but it is safe if done right.  I would have little
against it as a stopgap measure for Etch/Etch+1.

-- 
  "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: Help with menu

[Frank Küster]

Andreas Tille <[EMAIL PROTECTED]> wrote:

> On Fri, 29 Sep 2006, Bill Allombert wrote:
>
>> I suggest a simpler route (untested):
>>
>> command="x-terminal-emulator -e /bin/sh -c \"gnumed;echo press any key to 
>> continue;read foo\""
>>
>> Note that it does not really solve the dependency on xterm: it merely
>> replaces it on a depdendency on any terminal-emulator.
>
> The solution that was suggested by you and Philipp Benner seems to be not
> aware to lintian
>
> W: gnumed-client-debug: menu-command-not-in-package 
> /usr/share/menu/gnumed-client-debug:5 x-terminal-emulator
>
> Shouldn't a
>
>  Depends: xterm | x-terminal-emulator
>
> be enough here?  I admit that it might be hard to define a lintian rule
> to verify the contents of dependant packages but I wonder whether I should
> simply go with a lintian override or file either a wishlist bug against
> lintian or perhaps menu-policy?

I think it wouldn't be too much to hope that lintian knows about the
main executables that are provided by virtual packages, so I'd suggest a
lintian bug.

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

Unidentified subject!

[James Richardson]

unsubscribe


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

MIA: Masayuki Hatta

[[EMAIL PROTECTED]]

Is Masayuki Hatta <[EMAIL PROTECTED]> MIA?
I have sent him an email like one week ago and he does not reply to:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377933



Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, rápido, fiable.

Re: Help with menu (Was: Bug#389932: wish: gnumed --debug should open terminal window)

[Andreas Tille]

On Fri, 29 Sep 2006, Bill Allombert wrote:


I suggest a simpler route (untested):

command="x-terminal-emulator -e /bin/sh -c \"gnumed;echo press any key to continue;read 
foo\""

Note that it does not really solve the dependency on xterm: it merely
replaces it on a depdendency on any terminal-emulator.


The solution that was suggested by you and Philipp Benner seems to be not
aware to lintian

W: gnumed-client-debug: menu-command-not-in-package 
/usr/share/menu/gnumed-client-debug:5 x-terminal-emulator

Shouldn't a

 Depends: xterm | x-terminal-emulator

be enough here?  I admit that it might be hard to define a lintian rule
to verify the contents of dependant packages but I wonder whether I should
simply go with a lintian override or file either a wishlist bug against
lintian or perhaps menu-policy?

Kind regards

 Andreas.

--
http://fam-tille.de


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

Re: Allowing @ in user names?

[Marc Haber]

On Sun, 8 Oct 2006 00:45:08 +0100, Stephen Gran <[EMAIL PROTECTED]>
wrote:
>I'm not sure any of the suspicions have any bearing on question #2,
>however: should adduser be allowed to add usernames of this format, when
>told to with suitable --force flags?

After having this discussed here, I am now inclined to allow @ in user
names if --force-badname was given or NAME_REGEX was configured
appropriately.

I'll make that change thursday evening unless some new arguments were
shown here.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: anticipating the upstart migration

[Gabor Gombas]

On Mon, Oct 09, 2006 at 01:44:00AM +0200, Michael Biebl wrote:

> We don't really need the ability to install *multiple* init systems in
> parallel imho

Yes we do, for the same reason we allow multiple kernel images to be
installed simultaneously: if the new one does not work, there should be
a way to boot with the old version to fix things up. Especially if you
want testers. There's no way I'm personally going to try upstart if I
see no easy way ('easy' means adding a kernel parameter in the grub
menu, but definitely no rescue CD or such) to go back to sysvinit in
case the system fails to boot.

Gabor

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

Re: how to tell people to dpkg-reconfigure exim4-_CONFIG_?

[Magnus Holmgren]

On Monday 09 October 2006 11:32, Marc Haber took the opportunity to say:
> On Mon, 09 Oct 2006 09:23:48 +0200, sean finney <[EMAIL PROTECTED]>
>
> wrote:
> >On Mon, 2006-10-09 at 09:08 +0200, Marc Haber wrote:
> >> >The ultimate solution would be it dpkg-reconfigure magically knew that
> >> > when configuring exim4, it must actually configure exim4-config.
> >
> >funny, i'd have said the ultimate solution was finding a way to make the
> >users learn about looking at README.Debian :)
>
> That is unrealistic. I expect our users to get more stupid instead of
> less stupid.

Still, teaching users that whenever they install a nontrivial package, the one 
thing they should do first is read /usr/share/doc/$PACKAGE/README.Debian (if 
it exists), shouldn't be impossible, especially not if it's available from 
packages.d.o, alongside the changelog and copyright files, and accessible 
through aptitude, synaptic et al.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgp2KqLoIfUAs.pgp
Description: PGP signature

Re: how to tell people to dpkg-reconfigure exim4-_CONFIG_?

[Marc Haber]

On Mon, 09 Oct 2006 09:23:48 +0200, sean finney <[EMAIL PROTECTED]>
wrote:
>On Mon, 2006-10-09 at 09:08 +0200, Marc Haber wrote:
>> >The ultimate solution would be it dpkg-reconfigure magically knew that when 
>> >configuring exim4, it must actually configure exim4-config.
>
>funny, i'd have said the ultimate solution was finding a way to make the
>users learn about looking at README.Debian :)

That is unrealistic. I expect our users to get more stupid instead of
less stupid.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Call for votes for "GR: Recall the project leader"

[Lars Wirzenius]

On la, 2006-10-07 at 18:55 -0500, Debian Project Secretary wrote:
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> 49a98df6-2bd4-40c8-a559-7e15212dbd26
> [ 2 ] Choice 1: Recall the project leader
> [ 1 ] Choice 2: Further discussion
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-



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

Re: anticipating the upstart migration

[Gabor Gombas]

On Sun, Oct 08, 2006 at 10:53:39PM -0300, Henrique de Moraes Holschuh wrote:

> No wrappers for the single most critical binary in a Unix system after the
> libc.  Sorry.

Right. How about upstart not providing a /sbin/init binary at all, but
instead using an "init=/sbin/upstart" boot parameter? The other binaries
are less critical, so they can be diverted, and upstart can fall back
to sysvinit-provided binaries if it detects sysvinit is running (a'la
module-init-tools, as was already proposed)?

update-grub and friends could check the presence & value of the
"init=..." boot parameter and could warn the user if he/she is trying to
do something stupid.

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: ftp upload queue?

[Adam D. Barratt]

On Monday, October 09, 2006 6:42 AM, Thomas Bushnell BSG <[EMAIL PROTECTED]>
wrote:

> Aurélien GÉRÔME <[EMAIL PROTECTED]> writes:
>
>> As soon as I send a mail, the deamon restarts... Good news! ;)
>
> Yep.  Thanks magic elves!

I've never really pictured aj as an elf... ;-)

Adam


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

Superintendent Backup

[Salvatore Davison]

Hello,

Would you like to make at least 1.5K to 3.5K a day just for returning phone
calls?
If you have a telephone and can return calls you are fully qualified.

Talk with us - 800-513-3876

Respects,
Salvatore Davison



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

Re: how to tell people to dpkg-reconfigure exim4-_CONFIG_?

[sean finney]

hey marc,

On Mon, 2006-10-09 at 09:08 +0200, Marc Haber wrote:
> >The ultimate solution would be it dpkg-reconfigure magically knew that when 
> >configuring exim4, it must actually configure exim4-config.

funny, i'd have said the ultimate solution was finding a way to make the
users learn about looking at README.Debian :)

> Definetely. Is this possible to do without breaking things? And
> without replicating code throughout all exim4 packages?

i'd be really, really wary of doing something like this.  imho packages
should never touch/reference/know-about anything under /var/lib/dpkg.  

i'm also not convinced that this couldn't break something, somehow, in
some wierd corner case.  but my concerns have more to do with the
previous issue, and the fact that this could later be used to set
a precedent in other packages where the packagers are both more
ambitious and less careful.


sean


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

Re: Call for votes for "GR: Re-affirm support to the Debian Project Leader"

[Eduard Bloch]

#include 
* Debian Project Secretary [Sat, Oct 07 2006, 06:53:35PM]:
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> a65763d3-b1e2-4530-8ff8-aa5915274eb4
> [ 2  ] Choice 1: Re-affirm DPL, wish success to unofficial Dunc Tank
> [ 1  ] Choice 2: Re-affirm DPL, do not endorse nor support his other projects
> [ 3  ] Choice 3: Further discussion
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

-- 
 cat /dev/urandom > /dev/dsp
 zobel: das nennt sich "metal"
 oder "techno", je nachdem


signature.asc
Description: Digital signature

Re: how to tell people to dpkg-reconfigure exim4-_CONFIG_?

[Marc Haber]

On Sun, 8 Oct 2006 23:22:05 +0200, Hendrik Sattler
<[EMAIL PROTECTED]> wrote:
>Am Sonntag 08 Oktober 2006 22:58 schrieb James Westby:
>> The default level when doing dpkg-reconfigure is low, so that it wont be
>> seen on installation, but if the user tries to reconfigure exim4 they
>> will be directed to the correct package.
>
>The ultimate solution would be it dpkg-reconfigure magically knew that when 
>configuring exim4, it must actually configure exim4-config.

Definetely. Is this possible to do without breaking things? And
without replicating code throughout all exim4 packages?

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: how to tell people to dpkg-reconfigure exim4-_CONFIG_?

[Marc Haber]

On Sun, 8 Oct 2006 22:47:44 +0200, Hendrik Sattler
<[EMAIL PROTECTED]> wrote:
>/usr/share/doc/exim4/README.Debian.gz:

That is one of the most ignored files on any Debian system.

Users are so incredibly stupid!

Did you miss that exim4 is my package, and that you are pointing me
towards documentation I wrote myself? And that _I_ know that it's
exim4-config to be reconfigured?

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834