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, s
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 requeste
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 sa
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
On Fri, May 19, 2006 at 12:38:00PM +1000, Drew Parsons wrote:
> Brian displayed:
> > 2. License Grant. ...
> > (c) you do not combine, configure or distribute
> > the Software to run in conjunction with any additional software
> > that implements the same or similar functionality or APIs
Drew Parsons wrote:
> Brian displayed:
>> 2. License Grant. ...
>> (c) you do not combine, configure or distribute
>> the Software to run in conjunction with any additional software
>> that implements the same or similar functionality or APIs as the
>> Software;
>
> I am correct in
[Ccing: amd64 and dpkg developers as they are concerned by this subject]
Hi all,
[Short introduction to understand the problem]
I am asking here for help to take a decision. As some of you may know,
on amd64, the main libraries are installed into (/usr)/lib, with
(/usr)/lib64 being a symlink
On Thu, May 18, 2006 at 10:38:08PM +0200, 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 secon
Brian displayed:
> 2. License Grant. ...
> (c) you do not combine, configure or distribute
> the Software to run in conjunction with any additional software
> that implements the same or similar functionality or APIs as the
> Software;
I am correct in understanding that this means b
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 line that the alternatives system
will never, ever leav
cobaco (aka Bart Cornelis) wrote:
> On Wednesday 17 May 2006 23:08, Roberto C. Sanchez wrote:
>
>>Except that most customers don't know what a port is, nor much less care
>>that any are blocked (unless it prevents them from playing everquest or
>>chatting). Most people don't run their own mail se
On Thu, 18 May 2006, Florent Bayle wrote:
> Why no managing /bin/sh link with update-alternatives ?
Because it is essential.
--
"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." -- Th
On Thu, May 18, 2006 at 05:27:00PM -0300, Margarita Manterola wrote:
> 1. Make /bin/sh point to /bin/dash
The biggest problem with this seems to be scripts that expect /bin/sh to
point to /bin/bash. Arguably those scripts are broken, but there exists
another choice that avoids that unnecessary
Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes:
> I think one of the issues here is that it depends on what kernel you
> currently use, and iirc there can be a situation where one does not
> want to run depmod at installation time, or when that might give wrong
> results.
That used to be the ca
Darren Salt <[EMAIL PROTECTED]> writes:
> I demand that Goswin von Brederlow may or may not have written...
>
>> Darren Salt <[EMAIL PROTECTED]> writes:
>>> I demand that Matthias Julius may or may not have written...
>>> [snip]
I think a more elegant solution would be if aptitude had a comma
Michal Politowski <[EMAIL PROTECTED]> writes:
> On Thu, 18 May 2006 22:38:08 +0200, Goswin von Brederlow wrote:
> [...]
>> 3. Make sh an alternative
>
> dash already optionally diverts it. Isn't it good enough?
When I upload my fash (fast shell) package that would want to divert
sh too and then c
Hendrik Sattler <[EMAIL PROTECTED]> writes:
> Am Donnerstag, 18. Mai 2006 21:53 schrieb Goswin von Brederlow:
>> Hendrik Sattler <[EMAIL PROTECTED]> writes:
>> > Am Donnerstag, 18. Mai 2006 19:22 schrieb Goswin von Brederlow:
>> >> Because the only _solution_ with current userspace is to kill the
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 default /bin/sh (ignoring the fact
That it would break all thes
On May 19, Joey Hess <[EMAIL PROTECTED]> wrote:
> A while back Debian would only run depmod on boot if it had not been run
> before since the last kernel upgrade. Could you refresh my memory about
> why that optimisation was dropped?
I think because depmod --quick is supposed to be about as fast a
On Thu, May 18, 2006 at 11:29:47PM +0200, Jeroen van Wolffelaar wrote:
> On Thu, May 18, 2006 at 05:27:23PM -0300, Margarita Manterola wrote:
> > This option also might imply some extra bugs, but it's believed that
> > not so many, since there are already quite a number of people with
> > /bin/sh -
On Thu, May 18, 2006 at 05:27:23PM -0300, Margarita Manterola wrote:
> Also, I've heard other options being posed, such as writing all init
> scripts (including /etc/init.d/rc) in python. But I do want to
> concentrate on what's possible to do for etch or etch+1.
If you're going to use a real scr
Jeroen van Wolffelaar wrote:
> I think one of the issues here is that it depends on what kernel you
> currently use, and iirc there can be a situation where one does not
> want to run depmod at installation time, or when that might give wrong
> results.
FWIW, d-i currently runs depmod at image bui
Margarita Manterola wrote:
> Currently it is run by these packages' postinst:
> * kernel/linux-image-*
This takes care to run depmod -F ,
which should make the depmod work even though that kernel isn't running yet.
> * pwc-modules-*
> * ndiswrapper-modules-*
> * linux-wlan-ng-modules-*
> * spca5
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:
> * [long list]
>
Marco d'Itri wrote:
> If we can agree that it's not needed anymore (i.e. mandate by policy
> that packages need to run depmod on their own) then I will be happy to
> remove it from the m-i-t init script.
A while back Debian would only run depmod on boot if it had not been run
before since the last
On Thu, May 18, 2006 at 07:21:33PM -0300, Margarita Manterola <[EMAIL
PROTECTED]> 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.
(...)
> It looks like it's quite safe to stop runnin
On May 19, Margarita Manterola <[EMAIL PROTECTED]> 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.
If we can agree that it's not needed anymore (i.e. mandate by policy
that packages
On May 18, Gustavo Franco <[EMAIL PROTECTED]> wrote:
> Good, but i think interested people here are all our users, so what
> we're going to do with the 10% performance hit for use bash? I think
Nothing. A 10% optimization of init scripts which we already know
are highly suboptimal is not worth pur
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:
* kernel/linux-image-*
* module-init-tools
* powermgt-base
* zaptel
* lirc
* toshutils
* thinkpad
Anthony Towns schrieb am Donnerstag, den 18. Mai 2006:
> 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 asked
Package: wnpp
Severity: wishlist
Owner: Torsten Werner <[EMAIL PROTECTED]>
Package name: otrs2
Version : 2.0.4
Upstream Author : OTRS GmbH
URL : http://www.otrs.org/
License : GPL
Description : Open Ticket Request System version 2
OTRS is an Open s
On Thu, 18 May 2006 22:38:08 +0200, Goswin von Brederlow wrote:
[...]
> 3. Make sh an alternative
dash already optionally diverts it. Isn't it good enough?
--
Michał Politowski
Talking has been known to lead to communication if practiced carelessly.
I demand that Goswin von Brederlow may or may not have written...
> Darren Salt <[EMAIL PROTECTED]> writes:
>> I demand that Matthias Julius may or may not have written...
>> [snip]
>>> I think a more elegant solution would be if aptitude had a command to
>>> install build-depends.
>> .
>>> It cou
On 5/18/06, Marco d'Itri <[EMAIL PROTECTED]> wrote:
On May 18, Margarita Manterola <[EMAIL PROTECTED]> wrote:
> To make this speed up available to everyone, we have 2 main choices:
>
> 1. Make /bin/sh point to /bin/dash
> 2. Change #!/bin/sh for #!/bin/dash in the scripts
We have an even simple
On Wed, 17 May 2006 23:09:30 -0700 Don Armstrong wrote:
> Executive Summary:
[...]
< I'd recommend that ftp-masters
> consider pulling this package from non-free until these issues are
> resolved (or at least understood.)
Agreed.
[...]
> > 2. License Grant. Subject to the terms and conditions o
On Thu, May 18, 2006 at 05:27:23PM -0300, 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).
>
> To make this speed up available
On May 18, Margarita Manterola <[EMAIL PROTECTED]> wrote:
> To make this speed up available to everyone, we have 2 main choices:
>
> 1. Make /bin/sh point to /bin/dash
> 2. Change #!/bin/sh for #!/bin/dash in the scripts
We have an even simpler choice which already works and does not require
cha
Hi *DPL*,
Anthony Towns writes:
> 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 asked questions that have alread
On Thu, May 18, 2006 at 06:10:06PM -0300, Daniel Ruoso wrote:
> > This option also might imply some extra bugs, but it's believed that
> > not so many, since there are already quite a number of people with
> > /bin/sh -> /bin/dash, and they do file bugs when "bashisms" appear.
> A tool searching f
Em Qui, 2006-05-18 às 17:27 -0300, Margarita Manterola escreveu:
> 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).
Nice...
> To make this speed up availab
On Thu, 18 May 2006, 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 asked questions tha
"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 available to everyone, we hav
Darren Salt <[EMAIL PROTECTED]> writes:
> I demand that Matthias Julius may or may not have written...
>
> [snip]
>> 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
>> b
Le Jeudi 18 Mai 2006 22:31, Olaf van der Spek a écrit :
> On 5/18/06, Margarita Manterola <[EMAIL PROTECTED]> 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
On 5/18/06, Margarita Manterola <[EMAIL PROTECTED]> 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).
To make this speed up available to everyone, we ha
Am Donnerstag, 18. Mai 2006 21:53 schrieb Goswin von Brederlow:
> Hendrik Sattler <[EMAIL PROTECTED]> writes:
> > Am Donnerstag, 18. Mai 2006 19:22 schrieb Goswin von Brederlow:
> >> Because the only _solution_ with current userspace is to kill the
> >> kernels hotplug design and go back to synchro
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 available to everyone, we have 2 main choices:
1. Make /bin/sh point to /bin/dash
2. Ch
I demand that Matthias Julius may or may not have written...
[snip]
> 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 package. [...]
Hendrik Sattler <[EMAIL PROTECTED]> writes:
> Am Donnerstag, 18. Mai 2006 19:22 schrieb Goswin von Brederlow:
>> Because the only _solution_ with current userspace is to kill the
>> kernels hotplug design and go back to synchronous handling.
>
> Another solution might be to dynamically attach to u
Am Donnerstag, 18. Mai 2006 19:22 schrieb Goswin von Brederlow:
> Because the only _solution_ with current userspace is to kill the
> kernels hotplug design and go back to synchronous handling.
Another solution might be to dynamically attach to udev events. This is how
in-kernel async device disc
"Kevin B. McCarty" <[EMAIL PROTECTED]> writes:
> Could the archive infrastructure be updated to synch the override file
> with what's in the .debs automatically?
>
> regards,
Better to just remove the sections from override altogether. Just keep
what the package says.
MfG
Goswin
--
To
On 5/18/06, 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 asked questions that have already b
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 asked questions that have already been answered
isn't terribly useful.
Gabor Gombas <[EMAIL PROTECTED]> writes:
> On Thu, May 18, 2006 at 07:22:47PM +0200, Goswin von Brederlow wrote:
>> E.g. how do you convert startx into an udev rule so it can load
>> the mouse modules savely?
>
> By the time the user types his/her password and starts startx the mouse
> will be sur
On Thu, May 18, 2006 at 08:05:35PM +0200, Gabor Gombas wrote:
> On Thu, May 18, 2006 at 07:16:00PM +0200, Goswin von Brederlow wrote:
>
> > That is because udev is slower so the window of the race condition
> > gets increased many many times. Without udev you don't have to wait
> > for the mknod c
Goswin von Brederlow wrote:
> Christoph Berg <[EMAIL PROTECTED]> writes:
>
>> Re: Kevin B. McCarty 2006-05-17 <[EMAIL PROTECTED]>
>>> In case anyone is interested in filing mass bug reports (I am not
>>> sufficiently interested, sorry), here are the -dev packages in
>>> unexpected sections, obtai
On Thu, May 18, 2006 at 07:16:00PM +0200, Goswin von Brederlow wrote:
> Wouter Verhelst <[EMAIL PROTECTED]> writes:
>
> > On Thu, May 18, 2006 at 04:16:33PM +0200, Gabor Gombas wrote:
> >> On Wed, May 17, 2006 at 10:24:28PM +0200, Goswin von Brederlow wrote:
> >> > Just like the kernel always did
Gabor Gombas <[EMAIL PROTECTED]> writes:
> On Thu, May 18, 2006 at 07:16:00PM +0200, Goswin von Brederlow wrote:
>
>> That is because udev is slower so the window of the race condition
>> gets increased many many times. Without udev you don't have to wait
>> for the mknod call to complete.
>
> I t
On Thu, May 18, 2006 at 07:45:01PM +0200, Marco d'Itri wrote:
> On May 18, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>
> > The only other solution that keeps the asynchronisity is what Joey
> > suggested at the start: Instead of waiting/polling for udev events to
> > finish move the code int
I've just seen this in the gnome-applets package's postinst:
if [ "$1" = "configure" ]; then
SCHEMA_LOCATION=/usr/share/gconf/schemas
GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
HOME=/root \
gconftool-2 --direct --config-source=${GCONF_CONFIG_SOUR
On Thu, May 18, 2006 at 07:22:47PM +0200, Goswin von Brederlow wrote:
> The only other solution that keeps the asynchronisity is what Joey
> suggested at the start: Instead of waiting/polling for udev events to
> finish move the code into udev rules that get called asynchronously
> when the device
On Thu, May 18, 2006 at 07:16:00PM +0200, Goswin von Brederlow wrote:
> That is because udev is slower so the window of the race condition
> gets increased many many times. Without udev you don't have to wait
> for the mknod call to complete.
I think you got the speed comparison wrong: udev does
Matthias Julius <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>
>> Then I had the idea that I could just as well convert Sources files to
>> create pseudo packages for sources that depend on all the
>> Build-Depends. So I create a dummy deb without contents and con
On May 18, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> The only other solution that keeps the asynchronisity is what Joey
> suggested at the start: Instead of waiting/polling for udev events to
> finish move the code into udev rules that get called asynchronously
> when the devices appear. T
Christoph Berg <[EMAIL PROTECTED]> writes:
> Re: Kevin B. McCarty 2006-05-17 <[EMAIL PROTECTED]>
>> In case anyone is interested in filing mass bug reports (I am not
>> sufficiently interested, sorry), here are the -dev packages in
>> unexpected sections, obtained as follows:
>
> Isn't that more a
Wouter Verhelst <[EMAIL PROTECTED]> writes:
> On Thu, May 18, 2006 at 04:52:58PM +0200, Goswin von Brederlow wrote:
>> Wouter Verhelst <[EMAIL PROTECTED]> writes:
>>
>> > On Wed, May 17, 2006 at 10:08:38PM +0200, Goswin von Brederlow wrote:
>> >> Wouter Verhelst <[EMAIL PROTECTED]> writes:
>> >>
Gabor Gombas <[EMAIL PROTECTED]> writes:
>> And that is what I consider broken. I know it is not going to change
>> but I pain for all the users (and myself) that will (and already have
>> been) get hit by problems caused by it.
>
> Then why not start working on a solution? There are several distr
Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> Then I had the idea that I could just as well convert Sources files to
> create pseudo packages for sources that depend on all the
> Build-Depends. So I create a dummy deb without contents and converted
> the Sources file to have src-foobar as pac
Wouter Verhelst <[EMAIL PROTECTED]> writes:
> On Thu, May 18, 2006 at 04:16:33PM +0200, Gabor Gombas wrote:
>> On Wed, May 17, 2006 at 10:24:28PM +0200, Goswin von Brederlow wrote:
>> > Just like the kernel always did prior to udev.
>>
>> You're missing a very important thing. This is _NOT_ a "ud
On Thu, May 18, 2006 at 05:01:53PM +0200, Goswin von Brederlow wrote:
> Now the system randomly doesn't boot and instead of a 10 minute boot
> time you have a 3 hour drive to reset the system and analyse that is
> was just udev screwing you over.
Then introduce a timeout. Create /etc/default/wait
Package: wnpp
Severity: wishlist
Owner: Cyril Lacoux <[EMAIL PROTECTED]>
* Package name: digitools
Version : 1.0
Upstream Author : Andrew Calkin <[EMAIL PROTECTED]>,
Richard Taylor <[EMAIL PROTECTED]>,
Ben Potter <[EMAIL PROTECTED]>
* URL
On May 18, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> Actually, if you look at the hotplug .agent scripts you may find
> artificial "sleep"s in some of them that's just seem to paper over the
> race conditions you're talking about... What happens if you add the same
> delays to the udev rules?
RUN
Re: Kevin B. McCarty 2006-05-17 <[EMAIL PROTECTED]>
> In case anyone is interested in filing mass bug reports (I am not
> sufficiently interested, sorry), here are the -dev packages in
> unexpected sections, obtained as follows:
Isn't that more a matter of updating the override files?
Christoph
On Thu, May 18, 2006 at 08:36:05AM +0900, Osamu Aoki wrote:
> On Thu, May 18, 2006 at 11:01:52AM -0400, Justin Pryzby wrote:
> > Package: developers-reference
> > Version: 3.3.7
> > Severity: wishlist
> >
> > IMO it is a best-practice to set usertags when filing lots of bugs for
> > a given proble
On Thu, May 18, 2006 at 04:50:44PM +0200, Wouter Verhelst wrote:
> Install udev on my system -> things break randomly and unreproducibly,
> due to race conditions all over the place.
This is quite in line with what I said about userspace not being ready
for hotplug. The kernel can send the events
On Thu, May 18, 2006 at 04:52:58PM +0200, Goswin von Brederlow wrote:
> Wouter Verhelst <[EMAIL PROTECTED]> writes:
>
> > On Wed, May 17, 2006 at 10:08:38PM +0200, Goswin von Brederlow wrote:
> >> Wouter Verhelst <[EMAIL PROTECTED]> writes:
> >> > Have you considered employing the alternatives sys
Tim Cutts <[EMAIL PROTECTED]> writes:
> Playing devil's advocate for a moment:
While we are at it why not remove sections alltogether?
We have the debtags system that by far superseeds the sections and
since the pool structure is used sections have been quite useless.
MfG
Goswin
--
T
Toni Mueller <[EMAIL PROTECTED]> writes:
> Hello,
>
> On Tue, 16.05.2006 at 04:05:41 +, Brian M. Carlson <[EMAIL PROTECTED]>
> wrote:
>> [ udev being, umm, not very nice ]
>>
>> Need I say more?
>
> yes: Please say *why* newer 2.6.x kernels actually do depend on udev
> instead of hotplug.
>
Gabor Gombas <[EMAIL PROTECTED]> writes:
> On Wed, May 17, 2006 at 10:24:28PM +0200, Goswin von Brederlow wrote:
>
>> What timeout? With feedback you would know exactly when it is done and
>> wouldn't have to poll.
>
> Quoting Linus:
>
> : It really is very hard to accept the "blocking" behaviour.
Wouter Verhelst <[EMAIL PROTECTED]> writes:
> On Wed, May 17, 2006 at 10:08:38PM +0200, Goswin von Brederlow wrote:
>> Wouter Verhelst <[EMAIL PROTECTED]> writes:
>> > Have you considered employing the alternatives system (or something
>> > similar)? What I'm suggesting is that you'd basically get
On Thu, May 18, 2006 at 04:16:33PM +0200, Gabor Gombas wrote:
> On Wed, May 17, 2006 at 10:24:28PM +0200, Goswin von Brederlow wrote:
> > Just like the kernel always did prior to udev.
>
> You're missing a very important thing. This is _NOT_ a "udev vs.
> pre-udev" question. This is a "new kernel
On Thu, May 18, 2006 at 11:25:46AM +0200, Toni Mueller wrote:
> yes: Please say *why* newer 2.6.x kernels actually do depend on udev
> instead of hotplug.
1. They do not depend on it at all. 2.6.x kernels work just fine with a
static /dev as long as you don't need dynamic device creation. Ther
On 5/18/06, Thijs Kinkhorst <[EMAIL PROTECTED]> wrote:
On Thu, 2006-05-18 at 16:02 +0200, Olaf van der Spek wrote:
> On 5/18/06, Frans Pop <[EMAIL PROTECTED]> wrote:
> > On Thursday 18 May 2006 09:28, Josselin Mouette wrote:
> > > On Wed, May 17, 2006 at 10:21:27PM +0200, Francesco Poli wrote:
>
On Thu, 2006-05-18 at 16:02 +0200, Olaf van der Spek wrote:
> On 5/18/06, Frans Pop <[EMAIL PROTECTED]> wrote:
> > On Thursday 18 May 2006 09:28, Josselin Mouette wrote:
> > > On Wed, May 17, 2006 at 10:21:27PM +0200, Francesco Poli wrote:
> > > > As far as I can tell the packages were accepted fr
Goswin von Brederlow wrote:
> "Kevin B. McCarty" <[EMAIL PROTECTED]> writes:
>
>> In case anyone is interested in filing mass bug reports (I am not
>> sufficiently interested, sorry), here are the -dev packages in
>> unexpected sections, obtained as follows:
>>
>> grep-aptavail -r -P '.*-dev$' -s
On Wed, May 17, 2006 at 10:24:28PM +0200, Goswin von Brederlow wrote:
> What timeout? With feedback you would know exactly when it is done and
> wouldn't have to poll.
Quoting Linus:
: It really is very hard to accept the "blocking" behaviour.
:
: Some things can take a _loong_ time to be ready,
On 5/18/06, Frans Pop <[EMAIL PROTECTED]> wrote:
On Thursday 18 May 2006 09:28, Josselin Mouette wrote:
> On Wed, May 17, 2006 at 10:21:27PM +0200, Francesco Poli wrote:
> > As far as I can tell the packages were accepted from NEW in a very
> > short time frame (~ 5hours).
Could have something
Interesting. apt already provides some of the features of Conary but
not all and Conary or a Conary-like system may help Debian-based
distributions or local customizations.
Conary is a package management system, based on concepts similar to
those of the distributed Version Control Systems like dar
Le jeudi 18 mai 2006 à 10:09 +0200, Frans Pop a écrit :
> 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.
I know that. However there's nothing that I could call "urgent" in GNOME
2.14. It'
Package: wnpp
Severity: wishlist
Owner: Ted Percival <[EMAIL PROTECTED]>
* Package name: fetch-exc
Version : 1.0.0
Upstream Author : Juhani Rautiainen
* URL : http://personal.inet.fi/atk/fetchexc/
* License : GPL
Programming Lang: Java
Description : Fe
On Wed, 2006-05-17 at 23:09 -0700, Don Armstrong wrote:
[snip]
> > (c) you do not combine, configure or distribute the Software to
> > run in conjunction with any additional software that implements
> > the same or similar functionality or APIs as the Software;
>
> This means that we c
On Thu, 2006-05-18 at 13:11 +0200, cobaco (aka Bart Cornelis) wrote:
> > chatting). Most people don't run their own mail servers and can
> easily
> > be convinced by the ISP to use a mail client like Lookout, which is
> > pointed at the ISP's outbound mail server. Personally, I think it
> is a
>
On Thu, 2006-05-18 at 04:55 +0200, Jeroen van Wolffelaar wrote:
> On Wed, May 17, 2006 at 03:16:35PM -0500, Ron Johnson wrote:
> > Ignorance, fear of becoming an open relay and years of learning
> > will have to be overcome before Most Users will config Debian to
> > use a relayhost.
>
> It's not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17 May 2006, at 10:46 pm, Roberto C. Sanchez wrote:
I found this more instructive:
$ apt-cache search -n .\*-dev\$ | sed 's/ -.*//' | xargs apt-cache
show
| grep \^Section: | sort | uniq -c
1 Section: admin
1 Section: comm
On Thu, 18 May 2006, martin f krafft wrote:
> Also, what you are saying leads me to believe that you would want me
> to document *all* important changes, whether respective Debian bugs
> existed or not. NEWS.Debian is clearly a better method for such
Many important changes do not modify the intend
Am Donnerstag 18 Mai 2006 11:25 schrieb Toni Mueller:
> Hello,
>
> On Tue, 16.05.2006 at 04:05:41 +, Brian M. Carlson
<[EMAIL PROTECTED]> wrote:
> > [ udev being, umm, not very nice ]
> >
> > Need I say more?
>
> yes: Please say *why* newer 2.6.x kernels actually do depend on udev
> instead of
On Thu, 18 May 2006, Goswin von Brederlow wrote:
> No, you sounded like you wanted to enforce the installation of an MTA
> on every system and only support that (since all systems would have
> one why bother with anything else?).
Drop the "only" and change that to "by default always", and you will
On Wednesday 17 May 2006 23:08, Roberto C. Sanchez wrote:
> Lionel Elie Mamane wrote:
> > On Wed, May 17, 2006 at 09:42:42AM -0300, Henrique de Moraes Holschuh
wrote:
> >>An open outgoing port 25 is commonly blocked by default anywhere you
> >>have non-incompetent network management, unless you ar
Hello,
On Tue, 16.05.2006 at 04:05:41 +, Brian M. Carlson <[EMAIL PROTECTED]>
wrote:
> [ udev being, umm, not very nice ]
>
> Need I say more?
yes: Please say *why* newer 2.6.x kernels actually do depend on udev
instead of hotplug.
Thank you!
Best,
--Toni++
--
To UNSUBSCRIBE, email t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Koch a écrit :
> The Debian Java Team wants to switch the default
> version gcj/gij to point to the according 4.1 version.
Hi Michael,
Who is the Debian Java Team? I did not see a mail about this decision. I
thought I was a small part of the
1 - 100 of 109 matches
Mail list logo
