[not replying off-list because that seems counterproductive and arrogant]
On Fri, Jul 24, 2009 at 03:49:15PM +, brian m. carlson wrote:
> Actually, if it's invoked as /bin/sh, it is supposed to be
> Bourne-compatible. That's my experience with the current version:
Not much effort is put into
Akanni's B-Day Jam - presented in the new location: Michelberger Hotel
feat. live on stage:
- Akanni LIVE
- a special performance on the grand piano by Mic Donet - one of the
best Soul singers in Germany,
- Dana Shanti singing some of her new songs on the piano,
- Wynton Kelly Stevenson fro
Package: wnpp
Owner: Youhei SASAKI
Severity: wishlist
* Package name: rttool
Version : 1.0.3
Upstream Author : rubikitch(rubikitch At ruby-lang Dot org )
* URL or Web page :
http://www.rubyist.net/~rubikitch/computer/rttool/index.en.html
* License : Ruby's
Description
Hi everybody,
Timur Birsh brought it to my attention that my package ddclient provides
a virtual package "dyndns-client" that is not on the official virtual
package list at
http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
It seems that I have missed the requirement to r
On Fri, Jul 24 2009, Lars Wirzenius wrote:
> pe, 2009-07-24 kello 10:44 -0500, Manoj Srivastava kirjoitti:
>> On Fri, Jul 24 2009, Lars Wirzenius wrote:
>>
>>
>> > * Failed tests may _optionally_ also write dumps of the virtual
>> > environment (chroot, eventually maybe kvm images) so things m
Peter Samuelson writes:
>> Steve Langasek writes:
>> > What's the advantage of having it be zsh? Is zsh faster than dash? Or is
>> > the only savings the elimination of the 84k dash binary from /bin?
>
> [Goswin von Brederlow]
>> Plus the libaries dash depends on (if they differ from posh)
>
>
> Peter, do you have any hope to resume working on it ?
>
> Or should I look for a volunteer to take it over ?
Dominique, I don't think I'm going to have much time to continue work on
this in the near future. It might be better to try to find someone else to
adopt it.
Regards,
Peter
--
To UNSU
> Steve Langasek writes:
> > What's the advantage of having it be zsh? Is zsh faster than dash? Or is
> > the only savings the elimination of the 84k dash binary from /bin?
[Goswin von Brederlow]
> Plus the libaries dash depends on (if they differ from posh)
NEEDED libc.so.6
Oh well,
On 2009-07-24 15:49:15 +, brian m. carlson wrote:
> On Fri, Jul 24, 2009 at 08:31:55AM -0700, Russ Allbery wrote:
> > zsh has also historically been fairly buggy in corner cases as
> > /bin/sh and requires explicit commands to make it
> > Bourne-compatible. Autoconf has had to add a bunch of wo
Manoj Srivastava writes:
> On Fri, Jul 24 2009, Steve Langasek wrote:
>> If the goal is to make *bash* removable, then I can understand why
>> that would be helpful to some people since it's the heavier shell by
>> far.
>
> Right.
>
>> None of what you're talking about in this subthread
Goswin von Brederlow wrote:
Giacomo Catenazzi writes:
Raphael Geissert wrote:
Hello everybody,
This is a follow up to my previous thread, with a slightly different proposal.
What actually needs to be done is:
* Make dash essential, make it divert the current /bin/sh symlink by
default, make
Gabor Gombas writes:
> Hi,
>
> On Fri, Jul 24, 2009 at 09:31:04AM -0500, Manoj Srivastava wrote:
>
>> I think you are not going far enough. Why should I have dash on
>> the system when my default shell is posh? or (gasp) zsh?
>
> posh (or "strict POSIX" in general) is simply not practica
Steve Langasek writes:
> On Fri, Jul 24, 2009 at 09:31:04AM -0500, Manoj Srivastava wrote:
>
>> I think you are not going far enough. Why should I have dash on
>> the system when my default shell is posh? or (gasp) zsh?
>
> Why would you set your default shell to posh? It's only margina
Dear all,
first of all I would like to wish a nice conference to all Debconf
participants. I see a lot of enthousiasm on the mailing lists and
planet.debian.org and it really looks exciting to be there.
I am not attending Debconf, but I hope that it is the good timing to send this
email on my tho
Steve Langasek writes:
> On Fri, Jul 24, 2009 at 12:31:09PM +0200, Goswin von Brederlow wrote:
>> >> Are you saying that your objection to engineering a solution where
>> >> dash doesn't need to be essential is that it's not worth the effort?
>> >> I *think* that was the point of your message but
Hi Ian,
Ian Jackson wrote:
> Raphael Geissert writes ("Switching /bin/sh to dash (part two)"):
>> * Make dash essential, make it divert the current /bin/sh symlink by
>> default, make another essential package depend on dash. Prompt the
>> user before diverting on interactive upgrades.
>
> This
Giacomo Catenazzi writes:
> Raphael Geissert wrote:
>> Hello everybody,
>>
>> This is a follow up to my previous thread, with a slightly different
>> proposal.
>>
>> What actually needs to be done is:
>> * Make dash essential, make it divert the current /bin/sh symlink by
>> default, make anothe
pe, 2009-07-24 kello 10:44 -0500, Manoj Srivastava kirjoitti:
> On Fri, Jul 24 2009, Lars Wirzenius wrote:
>
>
> > * Failed tests may _optionally_ also write dumps of the virtual
> > environment (chroot, eventually maybe kvm images) so things may
> > be debugged.
>
> This is somewhat
Gabor Gombas wrote:
Hi,
On Fri, Jul 24, 2009 at 09:31:04AM -0500, Manoj Srivastava wrote:
I think you are not going far enough. Why should I have dash on
the system when my default shell is posh? or (gasp) zsh?
posh (or "strict POSIX" in general) is simply not practical, and zsh is
On Fri, Jul 24 2009, Lars Wirzenius wrote:
> * Failed tests may _optionally_ also write dumps of the virtual
> environment (chroot, eventually maybe kvm images) so things may
> be debugged.
This is somewhat off topic, but is there a way to run piuparts
in a kvm instance? I already r
On Fri, Jul 24 2009, Steve Langasek wrote:
> On Fri, Jul 24, 2009 at 09:31:04AM -0500, Manoj Srivastava wrote:
>
>> I think you are not going far enough. Why should I have dash on
>> the system when my default shell is posh? or (gasp) zsh?
>
> Why would you set your default shell to posh?
On Fri, Jul 24, 2009 at 08:31:55AM -0700, Russ Allbery wrote:
> zsh has also historically been fairly buggy in corner cases as /bin/sh and
> requires explicit commands to make it Bourne-compatible. Autoconf has had
> to add a bunch of workarounds for zsh as sh that I'm sure most of our
> shell scr
On Fri, Jul 24 2009, Laurent Léonard wrote:
> Virt-what is more accurate than Imvirt, version 1.0 can tell the
> difference between Xen Dom0 and DomU. The new version (1.1, released
> on 23 july 2009) can tell the difference between QEMU and KVM, and can
> tell if you are running inside a Xen full
Steve Langasek writes:
> What's the advantage of having it be zsh? Is zsh faster than dash? Or
> is the only savings the elimination of the 84k dash binary from /bin?
zsh has also historically been fairly buggy in corner cases as /bin/sh and
requires explicit commands to make it Bourne-compati
Hi,
On Fri, Jul 24, 2009 at 09:31:04AM -0500, Manoj Srivastava wrote:
> I think you are not going far enough. Why should I have dash on
> the system when my default shell is posh? or (gasp) zsh?
posh (or "strict POSIX" in general) is simply not practical, and zsh is
even more bloated th
On Fri, Jul 24, 2009 at 09:31:04AM -0500, Manoj Srivastava wrote:
> I think you are not going far enough. Why should I have dash on
> the system when my default shell is posh? or (gasp) zsh?
Why would you set your default shell to posh? It's only marginally smaller
than dash, and my und
On Fri, Jul 24 2009, Charles Plessy wrote:
> Le Thu, Jul 23, 2009 at 11:04:46PM -0500, Manoj Srivastava a écrit :
>>
>> I do not see an increase of accuracy in going from:
>>a set of RFC-2822 compliant fields
>> to
>>a set of fields similar to the ones used in RFC-2822.
>
>
On Fri, Jul 24 2009, Steve Langasek wrote:
> On Thu, Jul 23, 2009 at 04:04:03PM -0500, Manoj Srivastava wrote:
>
>> >> If the answer is that we really do want it everywhere independent of
>> >> what /bin/sh is, that's fine. However, that's not obvious to me.
>
>> > As long as /bin/sh refuses exte
On Fri, Jul 24 2009, Steve Langasek wrote:
> On Thu, Jul 23, 2009 at 08:20:05PM -0500, Manoj Srivastava wrote:
>> > But well, one of the ideas is to avoid having such extra stuff deeply
>> > tied to the core system, i.e. essential.
>
>> That's it? The time to try to reduce the set of Essen
On Fri, Jul 24 2009, Steve Langasek wrote:
> On Thu, Jul 23, 2009 at 04:10:54PM -0500, Manoj Srivastava wrote:
>> > We want everyone to use dash by default.
>
>> Who is we? Why is the sysadmin not the one making the decision?
>> Why is the Vendor making this decision for the user?
>
> Bec
On Fri, Jul 24 2009, Steve Langasek wrote:
> On Fri, Jul 24, 2009 at 04:33:21AM -0400, Sam Hartman wrote:
>> Steve, let's take a step back and calm down.
>
>> Are you saying that your objection to engineering a solution where
>> dash doesn't need to be essential is that it's not worth the effort?
Clint Adams writes:
> -idl=$(ls /etc/init.d/${service} 2> /dev/null | head -n 1)
> +idl="/etc/init.d/${service}"
> if [ -n "$idl" ] && [ -x $idl ]; then
You might as well remove the -n test if you do this. There's not much
chance of hitting it anymore...
Bjørn
--
T
On Fri, Jul 24, 2009 at 01:50:02PM +0100, Neil McGovern wrote:
> Just to re-iterate from a release team PoV, this could really do with
> fixing.
> (for d-d readers, this is a awesome bug, where dbus upgrades kill X)
>
> This is holding up xcb-util, which is holding up python-visual, which is
> pre
On Fri, Jul 24, 2009 at 03:43:47PM +0200, Steve Langasek wrote:
> Patches will be considered.
The second hunk isn't relevant to bash, but it seems a waste to
call ls and head for no reason.
--- debian/libpam0g.postinst.orig 2009-07-24 08:59:07.0 -0500
+++ debian/libpam0g.postinst
Raphael Hertzog (23/07/2009):
> > In case a maintainer of a shared lib never did this, I strongly
> > advise playing around with a simple combo of diff, find, and nm, in
> > order to have a look at what symbols are becoming between two
> > releases.
>
> Why is that better than comparing both symb
On Fri, Jul 24, 2009 at 01:09:59PM +, Clint Adams wrote:
> On Tue, Jul 21, 2009 at 04:18:07PM -0700, Steve Langasek wrote:
> > Why?
> Because:
> On Fri, Jul 24, 2009 at 09:38:01AM +0200, Steve Langasek wrote:
> > If the goal is to make *bash* removable, then I can understand why that
> > woul
Hi all,
Just to re-iterate from a release team PoV, this could really do with
fixing.
(for d-d readers, this is a awesome bug, where dbus upgrades kill X)
This is holding up xcb-util, which is holding up python-visual, which is
preventing the removal (finally!) of GTK 1
Thanks,
Neil
--
hermanr
Le vendredi 24 juillet 2009 04:34:23, Aaron M. Ucko a écrit :
> Laurent Léonard writes:
> > Description: detect if we are running in a virtual machine
>
> What does it offer over the existing imvirt package?
Virt-what is more accurate than Imvirt, version 1.0 can tell the difference
between
On Tue, Jul 21, 2009 at 04:18:07PM -0700, Steve Langasek wrote:
> Why?
Because:
On Fri, Jul 24, 2009 at 09:38:01AM +0200, Steve Langasek wrote:
> If the goal is to make *bash* removable, then I can understand why that
> would be helpful to some people since it's the heavier shell by far. None
>
Raphael Geissert writes ("Switching /bin/sh to dash (part two)"):
> * Make dash essential, make it divert the current /bin/sh symlink by
> default, make another essential package depend on dash. Prompt the
> user before diverting on interactive upgrades.
This needs to be done with great care to en
Jon Dowland writes ("Re: Considering the removal of ntpdate"):
> On Fri, Apr 24, 2009 at 12:30:36AM +0200, José Luis Tallón wrote:
> > - For Squeeze+1: just drop it
Why would we ever need to drop it ?
> At some point, sqwalk on STDERR on invocation about its
> deprecated-ness? or is that a st
> "Steve" == Steve Langasek writes:
Steve> On Fri, Jul 24, 2009 at 04:33:21AM -0400, Sam Hartman wrote:
>> Steve, let's take a step back and calm down.
>> Are you saying that your objection to engineering a solution
>> where dash doesn't need to be essential is that it's not
Steve Langasek wrote:
On Fri, Jul 24, 2009 at 04:33:21AM -0400, Sam Hartman wrote:
Steve, let's take a step back and calm down.
Are you saying that your objection to engineering a solution where
dash doesn't need to be essential is that it's not worth the effort?
I *think* that was the point
Hello Gaurav Gupta gauravguptashimla,
We are pleased to welcome you to the UNYK service.
Act now and take advantage of everything UNYK has to offer!
Your e-mail: debian-devel@lists.debian.org
Your Password Is: 230383
Build your smart address book
Add all your email contacts (Outlook, Hotmail,
I propose the following as the new output format of piuparts:
* Standard output will report tests that have been run, and their
results. This output will be similar to the lintian output. This
output should usually be pretty short, and to the point.
* Additionally, a log file will be written,
Le Thu, Jul 23, 2009 at 11:04:46PM -0500, Manoj Srivastava a écrit :
>
> I do not see an increase of accuracy in going from:
>a set of RFC-2822 compliant fields
> to
>a set of fields similar to the ones used in RFC-2822.
RFC-2822 specifies:
the header field:
Manoj Srivastava wrote:
On Wed, Jul 22 2009, Giacomo A. Catenazzi wrote:
If we remove the essential flag, we have a nice feature:
the packages who needs bash need to be documented (via Depends).
Can you tell me how long did it take to move from /usr/doc to
/usr/share/doc?
I don't
On Fri, 24 Jul 2009, Jon Dowland wrote:
> I suppose a system could be put together that stored all of the patch review
> data inside of itself.
Indeed... because updating headers in patch is not so immediate unless the
reviewer is part of the regular maintenance team.
There are many meta-informat
Steve Langasek wrote:
> On Fri, Jul 24, 2009 at 04:33:21AM -0400, Sam Hartman wrote:
>> Steve, let's take a step back and calm down.
>
>> Are you saying that your objection to engineering a solution where
>> dash doesn't need to be essential is that it's not worth the effort?
>> I *think* that was
On Fri, Jul 24, 2009 at 12:31:09PM +0200, Goswin von Brederlow wrote:
> >> Are you saying that your objection to engineering a solution where
> >> dash doesn't need to be essential is that it's not worth the effort?
> >> I *think* that was the point of your message but am not entirely sure.
> > Ye
Raphael Geissert wrote:
Hello everybody,
This is a follow up to my previous thread, with a slightly different proposal.
What actually needs to be done is:
* Make dash essential, make it divert the current /bin/sh symlink by default,
make another essential package depend on dash. Prompt the use
On Thu, Jul 23, 2009 at 04:04:03PM -0500, Manoj Srivastava wrote:
> >> If the answer is that we really do want it everywhere independent of
> >> what /bin/sh is, that's fine. However, that's not obvious to me.
> > As long as /bin/sh refuses extensions to posix I agree with you, but
> > bashism h
Steve Langasek writes:
> On Fri, Jul 24, 2009 at 04:33:21AM -0400, Sam Hartman wrote:
>> Steve, let's take a step back and calm down.
>
>> Are you saying that your objection to engineering a solution where
>> dash doesn't need to be essential is that it's not worth the effort?
>> I *think* that w
On Fri, Apr 24, 2009 at 12:30:36AM +0200, José Luis Tallón wrote:
> >From what was said in this thread, a quite feasible solution could be:
> - For Squeeze: a package "ntpdate" which depends on rdate and
> provides a wrapper script, used to emulate ntpdate's main functionality
> (set the syste
On Thu, Jul 23, 2009 at 08:20:05PM -0500, Manoj Srivastava wrote:
> > But well, one of the ideas is to avoid having such extra stuff deeply
> > tied to the core system, i.e. essential.
> That's it? The time to try to reduce the set of Essential
> packages is to deny entry to new items (l
On Wed, Jul 15, 2009 at 06:06:38PM -0400, Lucas Nussbaum wrote:
> I think that this information should be stored outside of the patch (in the
> history of a VCS, for example).
Can you explain how you envisage such a thing working, outside of the patch?
Not all packages are maintained inside a VCS.
On Fri, Jul 24, 2009 at 04:33:21AM -0400, Sam Hartman wrote:
> Steve, let's take a step back and calm down.
> Are you saying that your objection to engineering a solution where
> dash doesn't need to be essential is that it's not worth the effort?
> I *think* that was the point of your message but
Steve, let's take a step back and calm down.
Are you saying that your objection to engineering a solution where
dash doesn't need to be essential is that it's not worth the effort?
I *think* that was the point of your message but am not entirely sure.
--
To UNSUBSCRIBE, email to debian-devel-re
Siggy Brentrup wrote:
>> Folks, there was a longish discussion on IRC starting about an hour
>> ago about dash and bash.
>
> These discussions are extremely long standing :) The move away from
> bash has been aimed at long before I vanished from the project in 2004.
> I'm really upset that 5 yea
Ben Finney writes:
> Goswin von Brederlow writes:
>
>> Frans Pop writes:
>>
>> > Manoj Srivastava wrote:
>> >> I think we can engineer a system where Debian suggests various
>> >> shells as the default shell, and the user selects one. And only the
>> >> selected default shell is one that can't
On Thu, Jul 23, 2009 at 04:10:54PM -0500, Manoj Srivastava wrote:
> > We want everyone to use dash by default.
> Who is we? Why is the sysadmin not the one making the decision?
> Why is the Vendor making this decision for the user?
Because there's no reason for an end user to care about
Goswin von Brederlow writes:
> Frans Pop writes:
>
> > Manoj Srivastava wrote:
> >> I think we can engineer a system where Debian suggests various
> >> shells as the default shell, and the user selects one. And only the
> >> selected default shell is one that can't be removed from the
> >> syst
62 matches
Mail list logo
