Marco d'Itri wrote:
I think because depmod --quick is supposed to be about as fast as find.
YM as fast as test -nt? Doesn't seem to be on a dry cache.
--
see shy jo
signature.asc
Description: Digital signature
Ron wrote:
Drew Parsons wrote:
I am correct in understanding that this means bytecode (*.class) generated
using
gcj -C is not permitted by this licence to be run using the Sun JVM?
Probably so.
Given the imperfect compatibility between gcj Sun Java 1.5, can
you say whether the
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: 287 (new: 1)
Total number of packages offered up for adoption: 78 (new: 0)
Total number of packages
Hello Aurelien,
On 06-May-19 04:15, Aurelien Jarno wrote:
[Ccing: amd64 and dpkg developers as they are concerned by this subject]
Currently the (/usr)/lib64 - /lib symlink is shipped in the libc6
package. Goswin von Brederlow asked for this link to be created in the
postinst instead, so
Quoting =?UTF-8?B?Sm9zw6kgTHVpcyBUYWxsw7Nu?= [EMAIL PROTECTED]:
John Goerzen wrote:
JLTI was reprehended by Turbo Fredriksson due to the amount of
CPU wasted. He cared to contribute some patches which, after being
integrated and enhanced --as much as i could-- by me, form the current
build
On Thu, May 18, 2006, Margarita Manterola wrote:
During some tests I've performed, I've found that making the init
scripts run with dash as default shell instead of bash makes the boot
time a 10% faster (6 seconds in a 60 second boot).
[...]
2. Change #!/bin/sh for #!/bin/dash in the scripts
On May 19, David Weinehall [EMAIL PROTECTED] wrote:
That would mean having 2 shells since some scripts need bash. What a
waste on small systems.
Well, most of those scripts can be fixed quite easily, some require
a bit more work. I hereby promise to help fixing them to the extent
of my
On May 19, Joey Hess [EMAIL PROTECTED] wrote:
Marco d'Itri wrote:
I think because depmod --quick is supposed to be about as fast as find.
YM as fast as test -nt? Doesn't seem to be on a dry cache.
No, I really meant as fast as find. Which other test do you suggest?
--
ciao,
Marco
Margarita Manterola wrote:
Option (1) implies making dash base and Essential: yes (currently dash
is optional), and that would imply that until no Essential package
depends on bash, we would have two shells in Essential.
Since initramfs-tools, yaird, and initrd-tools all depend on dash
anyway,
Olaf van der Spek wrote:
Can't you only change the symlink if/when dash is installed?
Yes, dash manages /bin/sh in a sensible manner.
dpkg-reconfigure dash to switch the symlink to it.
--
see shy jo
signature.asc
Description: Digital signature
Jeroen van Wolffelaar wrote:
Of course, all the packages in question must then depend on dash, but
that's not really a problem IMHO. The only problem I do see is that dash
currently asks a question upon installation, which I think it should
simply stop doing so, administrators who want this
[Margarita Manterola]
During some tests I've performed, I've found that making the init
scripts run with dash as default shell instead of bash makes the boot
time a 10% faster (6 seconds in a 60 second boot).
I saw (parts of) your talk at debconf on this topic, and was happy to
see the
Hi
On Fri, 19 May 2006 10:12:57 +0200
Petter Reinholdtsen [EMAIL PROTECTED] wrote:
I believe this is a fairly safe thing to do, but believe it should be
done shortly after etch releases, and not just a few months before we
freeze for etch. There are other things we can manage before etch
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
On Fri, 19 May 2006, Goswin von Brederlow wrote:
Alternatives are more suited for cases where one binary is provided by
multiple packages. Currently we have bash, dash, sash, posh. Anything
else?
Are you prepared to put your life on the
Le jeudi 18 mai 2006 à 09:50 -0500, Anthony Towns a écrit :
As a final note, did anyone from Debian who usually examines licences
actually examine this one?
Yes.
At the election time, I hoped you could improve regarding communication
skills, at least enough to become a project leader.
Aurelien Jarno [EMAIL PROTECTED] writes:
Currently the (/usr)/lib64 - /lib symlink is shipped in the libc6
package. Goswin von Brederlow asked for this link to be created in the
postinst instead, so that packages could install files in both
(/usr)/lib and (/usr)/lib64 directories.
I have
Andreas Jochens [EMAIL PROTECTED] writes:
Hello Aurelien,
On 06-May-19 04:15, Aurelien Jarno wrote:
[Ccing: amd64 and dpkg developers as they are concerned by this subject]
Currently the (/usr)/lib64 - /lib symlink is shipped in the libc6
package. Goswin von Brederlow asked for this link
Hi Anthony,
On Thu, May 18, 2006 at 09:50:10AM -0500, Anthony Towns wrote:
On Wed, May 17, 2006 at 11:09:30PM -0700, Don Armstrong wrote:
As a final note, did anyone from Debian who usually examines licences
actually examine this one?
Yes.
What did he/she think about the following
On Thu, May 18, 2006 at 09:50:10AM -0500, Anthony Towns wrote:
On Wed, May 17, 2006 at 11:09:30PM -0700, Don Armstrong wrote:
First off, I'm going to completely ignore the FAQ as the FAQ and the
license both specifies that the FAQ does not have any legal validity.
Repeating frequently
On 06-May-19 11:02, Goswin von Brederlow wrote:
Andreas Jochens [EMAIL PROTECTED] writes:
Anything which makes it easier to violate this simple policy
will lead to a mixed usage of /usr/lib and /usr/lib64 and consequently
to problems which could be difficult to disentangle later.
The
* Goswin von Brederlow [EMAIL PROTECTED] [060518 21:20]:
Better to just remove the sections from override altogether. Just keep
what the package says.
Doesn't the current setup also ensure no package from non-free or
contrib accidentially end up in main when the section is wrong?
Bernhard R. Link [EMAIL PROTECTED] writes:
* Goswin von Brederlow [EMAIL PROTECTED] [060518 21:20]:
Better to just remove the sections from override altogether. Just keep
what the package says.
Doesn't the current setup also ensure no package from non-free or
contrib accidentially end up in
However, another solution would be just place these JPGs and PNGs flat
on the server and have apt just download them and save them
Yes, a public repository where people download the picture when they need it.
i have an Internet access (dialup or broadband)
1) I set a remote repository URL with
Scripsit Ron Johnson [EMAIL PROTECTED]
On Wed, 2006-05-17 at 11:35 +0200, Adam Borowski wrote:
Except, this is _doubling_ a question that was already asked somewhere else,
ie, a bug. The UNIX way of configuring the mail is setting up a binary that
knows how to deliver it as
Hi Michael,
On Friday, 19 May 2006, you wrote:
As a final note, did anyone from Debian who usually examines licences
actually examine this one?
Yes.
I take it you were too busy to elaborate on this when you wrote this
email. So you will probably give us the name of this person
* Turbo Fredriksson ([EMAIL PROTECTED]) wrote:
But regarding the build system, I REALLY object to any major changes! Fixes
yes,
but not REPLACEMENT!!
Uhh, or, not... Sorry, but the build system was terrible and is
certainly something which should not be encouraged.
I'd encourage you to look
* Aurelien Jarno ([EMAIL PROTECTED]) wrote:
The FHS is actually not very clear, as it says 64-bit libraries should
be in (/usr)/lib64, whereas system libraries should be in (/usr)/lib.
This is a contradiction for a pure 64-bit system.
The FHS is very clear about the path to the 64bit linker,
Quoting Stephen Frost [EMAIL PROTECTED]:
* Turbo Fredriksson ([EMAIL PROTECTED]) wrote:
But regarding the build system, I REALLY object to any major changes! Fixes
yes,
but not REPLACEMENT!!
Uhh, or, not... Sorry, but the build system was terrible and is
certainly something which should
* Turbo Fredriksson ([EMAIL PROTECTED]) wrote:
Quoting Stephen Frost [EMAIL PROTECTED]:
* Turbo Fredriksson ([EMAIL PROTECTED]) wrote:
But regarding the build system, I REALLY object to any major changes!
Fixes yes,
but not REPLACEMENT!!
Uhh, or, not... Sorry, but the build system
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Henning Makholm wrote:
Scripsit Ron Johnson [EMAIL PROTECTED]
On Wed, 2006-05-17 at 11:35 +0200, Adam Borowski wrote:
Except, this is _doubling_ a question that was already asked somewhere else,
ie, a bug. The UNIX way of configuring the mail
Hi,
Today, after upgrading my system, suddenly mcedit became the default
editor, rather than vim as I expected it. Investigating showed that some
funny guy decided that mcedit could use a priority of 100, whereas vim
had fallen back to 60 since the latest upgrade.
Fixing this wasn't very hard,
At 1148052328 past the epoch, Wouter Verhelst wrote:
Using popcon would ensure that the applications which most people
prefer would be the default; this is a fair and objective criterion.
Thoughts?
Interesting idea, but by my reckoning that would make ed the default
editor for most people,
At 1148048910 past the epoch, Jon Dowland wrote:
Interesting idea, but by my reckoning that would make ed the default
editor for most people, which I don't think is a good idea:
http://popcon.debian.org/main/editors/by_inst
Eek. Of course if you go by vote, then vim or nvi trump ed,
Quoting Stephen Frost [EMAIL PROTECTED]:
* Turbo Fredriksson ([EMAIL PROTECTED]) wrote:
Quoting Stephen Frost [EMAIL PROTECTED]:
* Turbo Fredriksson ([EMAIL PROTECTED]) wrote:
But regarding the build system, I REALLY object to any major changes!
Fixes yes,
but not REPLACEMENT!!
On Fri, May 19, 2006 at 05:45:46AM +0200, David Weinehall wrote:
Well, most of those scripts can be fixed quite easily, some require
a bit more work. I hereby promise to help fixing them to the extent
of my capability.
Let's see. The nbd-client and nbd-server initscripts use bash arrays. Do
On Fri, May 19, 2006 at 02:05:12AM +0200, Marco d'Itri wrote:
On May 19, Wouter Verhelst [EMAIL PROTECTED] wrote:
Since bash does enable some features that are not specified in
POSIX, even when called as /bin/sh, I don't see what the problem
would be of installing something else as our
On Fri, May 19, 2006 at 09:44:45AM +0200, Loïc Minier wrote:
On Thu, May 18, 2006, Margarita Manterola wrote:
During some tests I've performed, I've found that making the init
scripts run with dash as default shell instead of bash makes the boot
time a 10% faster (6 seconds in a 60 second
On Fri, May 19, 2006 at 03:25:28PM +0200, Wouter Verhelst wrote:
Fixing this wasn't very hard, but it made me consider why we let a
maintainer decide what the alternative priority of an editor would be.
Mm -- I always wondered why xfce-session-manager had a priority over
gnome-session-manager
On Fri, May 19, 2006 at 02:28:30PM +0100, Jon Dowland wrote:
At 1148052328 past the epoch, Wouter Verhelst wrote:
Using popcon would ensure that the applications which most people
prefer would be the default; this is a fair and objective criterion.
Thoughts?
Interesting idea, but by
On Fri, May 19, 2006 at 09:35:57AM +0200, Turbo Fredriksson wrote:
But regarding the build system, I REALLY object to any major changes! Fixes
yes,
but not REPLACEMENT!!
Well, it's a little late for that. ;-)
The first build system really sucked. It took AGES to build, and that
I have no
On Fri, May 19, 2006 at 02:44:14PM +0200, Turbo Fredriksson wrote:
Quoting Stephen Frost [EMAIL PROTECTED]:
Honestly, though, I'm much more concerned about maintainability than
speed of the build.
It's not especially problematic to maintain as it is now, and I ask you
to recognize the
Ich werde ab Fr, 19.05.2006 nicht im Büro sein. Ich kehre zurück am Di,
23.05.2006.
Bitte wenden Sie sich während meiner Abwesenheit an meine Kollegen von der
IT-Abteilung unter der Telefonnummer: +49 (8272) 86-555.
Please contact my colleagues from the IT department - extension -555 -
during my
Goswin von Brederlow wrote:
Margarita Manterola [EMAIL PROTECTED] writes:
During some tests I've performed, I've found that making the init
scripts run with dash as default shell instead of bash makes the boot
time a 10% faster (6 seconds in a 60 second boot).
To make this speed up
On Fri, May 19, 2006 at 10:18:46AM +0200, Michal Čihař wrote:
There are anyway users using dash as /bin/sh right now and broken
packages are bugged, so switching default should not reveal any new bug
The policy says:
# If a script requires non-POSIX features from the shell interpreter, the
#
On Fri, May 19, 2006 at 02:28:30PM +0100, Jon Dowland wrote:
Using popcon would ensure that the applications which most people
prefer would be the default; this is a fair and objective criterion.
Interesting idea, but by my reckoning that would make ed the default
editor for most people,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jon Dowland wrote:
At 1148052328 past the epoch, Wouter Verhelst wrote:
Using popcon would ensure that the applications which most people
prefer would be the default; this is a fair and objective criterion.
Thoughts?
Interesting idea, but by
On Fri, May 19, 2006 at 03:29:55PM +0200, Turbo Fredriksson wrote:
The ONLY problem with the current (partial) build system is that part of (!!)
the build is hardcoded. Where libs are, and the name of the MySQL/PgSQL libs
will rarely (if ever) change so this is not a PROBLEM, it's only a
* Turbo Fredriksson ([EMAIL PROTECTED]) wrote:
You keep saying that, without showing the problems. From what I can see,
all you say is it's wrong, it's very wrong and there's major problems
with it.
John pointed out the issues to it earlier in this thread, which you said
you had followed so I
On May 19, Adam Borowski [EMAIL PROTECTED] wrote:
Besides, here's an idea:
let's make it karma-mandatory for debian-devel readers to have /bin/sh point
to foosh for sh!=ba. The more people people use alternate shells, the
faster bugs are exposed.
Good idea, just don't try it with posh.
And
Steinar H. Gunderson [EMAIL PROTECTED] writes:
On Fri, May 19, 2006 at 03:25:28PM +0200, Wouter Verhelst wrote:
Fixing this wasn't very hard, but it made me consider why we let a
maintainer decide what the alternative priority of an editor would be.
Mm -- I always wondered why
Wouter Verhelst [EMAIL PROTECTED] writes:
On Fri, May 19, 2006 at 05:45:46AM +0200, David Weinehall wrote:
Well, most of those scripts can be fixed quite easily, some require
a bit more work. I hereby promise to help fixing them to the extent
of my capability.
Let's see. The nbd-client and
At 1148053588 past the epoch, Wouter Verhelst wrote:
That's not an issue. First, ed doesn't install an alternatives for
editor.
Ah. Of course :)
Sheepish,
--
Jon Dowland
http://alcopop.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
Hi,
I'm off on two trips.
One across Saskatchewan (Trans Canada, and parts south), from one side
of the province to the other.
The other to Cincinnati, OH via Minneapolis, MN Airport.
Email me for details (I'm not subscribed to debian-devel).
I may not be able to use my existing key (forgot
On 5/19/06, Wouter Verhelst [EMAIL PROTECTED] wrote:
On Fri, May 19, 2006 at 05:45:46AM +0200, David Weinehall wrote:
Well, most of those scripts can be fixed quite easily, some require
a bit more work. I hereby promise to help fixing them to the extent
of my capability.
Let's see. The
On Fri, May 19, 2006 at 03:17:20AM +0200, Goswin von Brederlow wrote:
Alternatives are more suited for cases where one binary is provided by
multiple packages. Currently we have bash, dash, sash, posh. Anything
else?
Alternatives break on a daily basis, I wouldn't trust them for something
as
Bernhard R. Link wrote:
* Goswin von Brederlow [EMAIL PROTECTED] [060518 21:20]:
Better to just remove the sections from override altogether. Just keep
what the package says.
Doesn't the current setup also ensure no package from non-free or
contrib accidentially end up in main when the
On Fri, May 19, 2006 at 03:41:12PM +0200, Steinar H. Gunderson wrote:
On Fri, May 19, 2006 at 03:25:28PM +0200, Wouter Verhelst wrote:
Fixing this wasn't very hard, but it made me consider why we let a
maintainer decide what the alternative priority of an editor would be.
Mm -- I always
Adam Borowski [EMAIL PROTECTED] wrote:
On Fri, May 19, 2006 at 10:18:46AM +0200, Michal Čihař wrote:
There are anyway users using dash as /bin/sh right now and broken
packages are bugged, so switching default should not reveal any new bug
The policy says:
# If a script requires non-POSIX
On Fri, May 19, 2006 at 10:58:33AM +0200, Goswin von Brederlow wrote:
Local admins are already allowed to convert directories into links,
e.g. to move parts ot the directory tree to another disk.
According to Steve Langasek in
Message-ID: [EMAIL PROTECTED]
that's not allowed and you should use
Gabor Gombas [EMAIL PROTECTED] writes:
On Fri, May 19, 2006 at 03:17:20AM +0200, Goswin von Brederlow wrote:
Alternatives are more suited for cases where one binary is provided by
multiple packages. Currently we have bash, dash, sash, posh. Anything
else?
Alternatives break on a daily
Hi,
Debian policy says:
| 8.2 Run-time support programs
|
| If your package has some run-time support programs which use the
| shared library you must not put them in the shared library
| package. If you do that then you won't be able to install several
| versions of the shared library without
On Fri, May 19, 2006 at 03:25:28PM +0200, Wouter Verhelst wrote:
Today, after upgrading my system, suddenly mcedit became the default
editor, rather than vim as I expected it. Investigating showed that some
funny guy decided that mcedit could use a priority of 100, whereas vim
had fallen back
Goswin von Brederlow wrote:
Hi,
Debian policy says:
| 8.2 Run-time support programs
|
| If your package has some run-time support programs which use the
| shared library you must not put them in the shared library
| package. If you do that then you won't be able to install several
| versions
Re: Goswin von Brederlow 2006-05-19 [EMAIL PROTECTED]
The line below looks for all packages with a *.so.* file in (/usr)/lib
and a file in (/usr)/bin. The assumption is that anything with a
*.so.* file in the system library dirs is a library package and those
may not have files in (/usr)/bin.
Goswin von Brederlow [EMAIL PROTECTED] writes:
Matthias Julius [EMAIL PROTECTED] writes:
I think a more elegant solution would be if aptitude had a command to
install build-depends. It could attach a new flag to a package that
causes aptitude to treat build-depends just like depends of that
Apparently dpkg was initially written/prototyped in perl; does there
exist somewhere a copy of that implementation?
Please Cc: me,
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Aurelien Jarno [EMAIL PROTECTED] wrote:
libc6 GNU Libc Maintainers debian-glibc@lists.debian.org
For this one, please talk with the ftpmasters. Such a change has
already been done, but rejected from the NEW queue.
Can you quote the reasons?
Regards, Frank
--
Frank Küster
The following is based on premises that portability is good and
that POSIX is a standard. A proposal.
Over the last couple months we've built about gazillion Ubuntu/Dapper
packages. The process is heavily automated ([1], [2], [3]).
And so, to lookup the result of the XYZ build (where XYZ is a
On Thu, May 18, 2006 at 07:21:33PM -0300, Margarita Manterola wrote:
Continuing on the goal of optimizing boot time, quite a number of
seconds (specially in old machines) can be saved by not running depmod
at boot time.
Currently it is run by these packages' postinst:
Wouldn't it be a good
Frank Küster wrote:
Aurelien Jarno [EMAIL PROTECTED] wrote:
libc6 GNU Libc Maintainers debian-glibc@lists.debian.org
For this one, please talk with the ftpmasters. Such a change has
already been done, but rejected from the NEW queue.
Can you quote the reasons?
Yes,
Aurelien Jarno [EMAIL PROTECTED] wrote:
Frank Küster wrote:
Aurelien Jarno [EMAIL PROTECTED] wrote:
libc6 GNU Libc Maintainers
debian-glibc@lists.debian.org
For this one, please talk with the ftpmasters. Such a change has
already been done, but rejected from the NEW
Hi,
I'm not suggesting splitting the dirs. Just the way the link is setup.
I'm suggesting creating it in the maintainer scripts instead of the
data.tar.gz so packages that do ship files in (/usr)/lib64 don't make
libc6 unupgradable.
On debootstrap install, libc6 postinst isn't actually ran
Aurelien Jarno [EMAIL PROTECTED] writes:
Goswin von Brederlow wrote:
Hi,
Debian policy says:
| 8.2 Run-time support programs
| | If your package has some run-time support programs which use the
| shared library you must not put them in the shared library
| package. If you do that then you
Christoph Berg [EMAIL PROTECTED] writes:
Re: Goswin von Brederlow 2006-05-19 [EMAIL PROTECTED]
The line below looks for all packages with a *.so.* file in (/usr)/lib
and a file in (/usr)/bin. The assumption is that anything with a
*.so.* file in the system library dirs is a library package
On Fri, May 19, 2006 at 10:34:35AM -0700, Alex Ross wrote:
The following is based on premises that portability is good and
that POSIX is a standard. A proposal.
I didn't see a concrete proposal in your email, only information about where
to find gnusolaris build logs. Can you elaborate?
--
Matthias Julius [EMAIL PROTECTED] writes:
Goswin von Brederlow [EMAIL PROTECTED] writes:
Matthias Julius [EMAIL PROTECTED] writes:
I think a more elegant solution would be if aptitude had a command to
install build-depends. It could attach a new flag to a package that
causes aptitude to
Goswin von Brederlow wrote:
Aurelien Jarno [EMAIL PROTECTED] writes:
Goswin von Brederlow wrote:
Hi,
Debian policy says:
| 8.2 Run-time support programs
| | If your package has some run-time support programs which use the
| shared library you must not put them in the shared library
| package.
Aurelien Jarno [EMAIL PROTECTED] writes:
Goswin von Brederlow wrote:
Aurelien Jarno [EMAIL PROTECTED] writes:
Goswin von Brederlow wrote:
Hi,
Debian policy says:
| 8.2 Run-time support programs
| | If your package has some run-time support programs which use the
| shared library you must
On Thu, May 18, 2006 at 10:09:28AM +0200, Frans Pop wrote:
If you really have urgent reasons to get a package into new, the best
action is probably to send a mail to debian-release and to present these
reasons.
Please don't abuse the release team's relationship with the ftpmasters for
NEW
On Friday 19 May 2006 10:25, Wouter Verhelst wrote:
Today, after upgrading my system, suddenly mcedit became the default
editor, rather than vim as I expected it. Investigating showed that some
funny guy decided that mcedit could use a priority of 100, whereas vim
had fallen back to 60 since
Junichi Uekawa [EMAIL PROTECTED] writes:
Hi,
I'm not suggesting splitting the dirs. Just the way the link is setup.
I'm suggesting creating it in the maintainer scripts instead of the
data.tar.gz so packages that do ship files in (/usr)/lib64 don't make
libc6 unupgradable.
On
Am Freitag, 19. Mai 2006 03:14 schrieb Goswin von Brederlow:
Hendrik Sattler [EMAIL PROTECTED] writes:
Am Donnerstag, 18. Mai 2006 21:53 schrieb Goswin von Brederlow:
But how do you detect when there is no device to be found to call the
function?
That's of absolutely no interest because
Alex Ross [EMAIL PROTECTED] writes:
The following is based on premises that portability is good and
that POSIX is a standard. A proposal.
Over the last couple months we've built about gazillion Ubuntu/Dapper
packages. The process is heavily automated ([1], [2], [3]).
And so, to lookup the
Let me reply to at least some of the points raised here right now. By
the way, one of the Sun engineers was involved in packaging, and
actually wrote (with help from others) part of the license agreement
code etc. using debconf. I don't think that has any legal value (but I'm
not a legal expert),
On Fri, 2006-05-19 at 18:44 +0200, Goswin von Brederlow wrote:
Debian policy says:
| 8.2 Run-time support programs
|
| If your package has some run-time support programs which use the
| shared library you must not put them in the shared library
| package. If you do that then you won't be
* Steve Langasek ([EMAIL PROTECTED]) wrote:
On Thu, May 18, 2006 at 10:09:28AM +0200, Frans Pop wrote:
If you really have urgent reasons to get a package into new, the best
action is probably to send a mail to debian-release and to present these
reasons.
Please don't abuse the release
On Friday 19 May 2006 05:12, Petter Reinholdtsen wrote:
I was a bit surprised that parallel execution only shaved 2 seconds of
the boot, but suspect it might be because of inefficient
implementation in /etc/init.d/rc.
Not really a /etc/init.d/rc fault, is more likely a problem that there is
On Fri, 19 May 2006, Goswin von Brederlow wrote:
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
On Fri, 19 May 2006, Goswin von Brederlow wrote:
Alternatives are more suited for cases where one binary is provided by
multiple packages. Currently we have bash, dash, sash, posh.
On Fri, May 19, 2006 at 01:15:44PM -0700, Alex Ross wrote:
Matt Zimmerman wrote:
On Fri, May 19, 2006 at 10:34:35AM -0700, Alex Ross wrote:
The following is based on premises that portability is good and that
POSIX is a standard. A proposal.
I didn't see a concrete proposal in your email,
Well, great we're now in Slashdot as new Java license supporters[0].
Of course, somebody noticed the error[1], but it isn't enough. The
original article[2] contains DLJ also has support from Gentoo and
Debian..
I haven't endorsed anything, so for those who prepared this and
submitted an
[Loïc Minier]
Right now, if a script is named .sh, it is sourced, perhaps it's
enough to change /etc/init.d/rc to use dash, depend on dash there
(sysv-rc), and progressively convert init scripts to use a symlink
ending in .sh when they are POSIX?
Actually, if we want to run the scripts in
Matt Zimmerman wrote:
On Fri, May 19, 2006 at 01:15:44PM -0700, Alex Ross wrote:
Matt Zimmerman wrote:
On Fri, May 19, 2006 at 10:34:35AM -0700, Alex Ross wrote:
The following is based on premises that portability is good and that
POSIX is a standard. A proposal.
I didn't see a concrete
[Gregor Herrmann]
If you look at by_vote [0] the situation is different:
http://popcon.debian.org/main/editors/by_vote
[0] which seems more relevant to me:
#inst is the number of people who installed this package;
#vote is the number of people who use this package regularly;
Note, the
Take a look at http://bugs.debian.org/367800. I cloned the bug, but
neither of the clones seem to have appeared on the page for gnucash,
nor did the severity of the bug get increased. The title did get
changed, however.
Any ideas what's going on?
Thomas
--
To UNSUBSCRIBE, email to [EMAIL
pe, 2006-05-19 kello 09:35 +0200, Marco d'Itri kirjoitti:
On May 19, David Weinehall [EMAIL PROTECTED] wrote:
That would mean having 2 shells since some scripts need bash. What a
waste on small systems.
Well, most of those scripts can be fixed quite easily, some require
a bit more
Matt Zimmerman wrote:
On Fri, May 19, 2006 at 10:34:35AM -0700, Alex Ross wrote:
The following is based on premises that portability is good and that
POSIX is a standard. A proposal.
I didn't see a concrete proposal in your email, only information about
where to find gnusolaris build logs.
On Fri, May 19, 2006 at 07:56:54PM +0200, Goswin von Brederlow wrote:
Aurelien Jarno [EMAIL PROTECTED] writes:
I don't see why this could be a problem for multiarch. The library is
only used by the binary which is the same package, so they are always
in sync.
libfoo:i386 contains
Al Stone [EMAIL PROTECTED] writes:
If the library is only used for binary packages from the same source
[which always get updated together] then why not put it in
/usr/lib/package/ and make it not public?
This could be done for the qprof package. I'm not sure that qualifies
as an RC bug,
Russ Allbery [EMAIL PROTECTED] writes:
I wonder if the weird AFS PAG hack is corrupting the process group list in
some way. It would be the first time I'd heard of that problem if so, but
That's quite possible, as I've observed similar behavior on my amd64
machine (but neglected to report it
Alex Ross [EMAIL PROTECTED] writes:
Minimally, package maintainers and developers could take a look on our
logs and see if there's anything wrong. If there is, in many cases the
fix is obvious.
You probably need to provide a view by maintainer in order to get
visibility to many developers.
1 - 100 of 186 matches
Mail list logo