#include
* Nathanael Nerode [Tue, Dec 20 2005, 04:59:46PM]:
> rlog -- old version is in testing
Depends on the update of fuse. I am waiting for any reaction from Bartosz
and I am going to NMU fuse next week or so if nothing happens.
Eduard.
--
auf tetrinet.debian.net sind leute, die ich noc
On Tue, Dec 20, 2005 at 04:59:46PM -0500, Nathanael Nerode wrote:
> The following libraries still need to be uploaded with name changes
> for the c2a transition
> (http://lists.debian.org/debian-devel-announce/2005/11/msg00010.html):
> Most are not in testing at the moment.
>
> alps-light1
> a
On Wed, Dec 21, 2005 at 08:58:08AM +0100, Eduard Bloch wrote:
> > rlog -- old version is in testing
>
> Depends on the update of fuse. I am waiting for any reaction from Bartosz
> and I am going to NMU fuse next week or so if nothing happens.
I'm working on it, but in the same time I'm going to
Package: wnpp
Severity: wishlist
* Package name: gifsicle
Version : 1.44
Upstream Author : Eddie Kohler <[EMAIL PROTECTED]>
* URL : http://www.lcdf.org/gifsicle/
* License : See below
Description : Powerful tool for manipulationg GIF images
This is a powerf
Hi,
I'd like to use usertags to track the status of bugs in testing
vs. unstable, but I cannot find the trick in the URL to restrict the
displayed bugs to those that are still open in testing. For example,
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pdfoutput;[EMAIL
PROTECTED];dist=testing
2005/12/20, Anthony Towns :
> So the old behaviour's POSIX compatible as long as the Makefile doesn't
> specify the .POSIX target.
The real question is, is there a way to allow the old
supported-for-years syntax. With large makefiles it uglyfies the file
somewhat. And interestingly, in the changel
Hi, debian-devel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lars Wirzenius <[EMAIL PROTECTED]> writes:
> Automated testing of program functionality
> ==
>
> Automatic testing needs to happen in various contexts:
>
> * When the package has been built, but befo
Gürkan Sengün writes:
> * Package name: gifsicle
#212193, if anyone is thinking this sounds vaguely familiar.
> * URL : http://www.lcdf.org/gifsicle/
Which reads, in part:
"As of July 2004, all of Unisys's LZW/GIF patents have expired, but IBM
has a remaining patent. There
On Tue, 20 Dec 2005, Steve Greenland wrote:
On 20-Dec-05, 09:56 (CST), Gabor Gombas <[EMAIL PROTECTED]> wrote:
On Tue, Dec 20, 2005 at 08:57:08AM -0600, Steve Greenland wrote:
[1] Dark blue on black. Need I say more?
The reality is that visibility of color combinations is heavily
dependent on
On Wed, Dec 21, 2005 at 10:40:59AM +0100, Frank Küster wrote:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pdfoutput;[EMAIL
> PROTECTED];dist=testing&archive=no
> Shows four Archived bugs of normal severity. As an example, look at the
> last one:
> http://bugs.debian.org/322353
> This versi
On Tue, 20 Dec 2005, Henning Makholm wrote:
Scripsit Gabor Gombas <[EMAIL PROTECTED]>
Now, if your terminal pretends to be xterm but does not use the color
scheme of xterm, how should vim know that?
You can't.
real console: TERM='linux'
xterm: TERM='xterm'
gnome-terminal: TERM='xterm'
konsol
Anthony Towns wrote:
>> How can I specify an URL that correctly shows only bugs open in testing?
>
> Adding ";pend-exc=done,absent" should do what you want, I think.
Thank you, fine. Archived bugs are still displayed, but only in the
separate resolved categories.
Regards, Frank
--
Frank Küst
ke, 2005-12-21 kello 10:28 +, Roger Leigh kirjoitti:
> For this task, you might find schroot(1) useful. It's a means of
> accessing chroot environments, but it supports LVM snapshots as one
> method.
Does this require the user to set up LVM somehow before using schroot?
> This is a very qu
First, thanks to Lars for drawing our attention to an important topic
and for taking an initiative that is long overdue.
Lars, I agree fully with what you say. When it comes to team
maintenance I would go even further than you do. You say:
> Mandatory teams for packages seems ridiculous to
On Wed, Dec 21, 2005 at 02:07:30AM +0200, Lars Wirzenius wrote:
> Sloppiness tends to result in real problems sooner or later.
possible slogan for volatile-sloppy ? :)
> Several ideas have been floating around for years on how to improve
> this situation, of which I'd like to mention three. While
Anthony Towns wrote:
> On Mon, Dec 19, 2005 at 08:45:45PM -0800, Russ Allbery wrote:
> > > (TBH, I'd be much happier just making the technical changes
> > > necessary to ensure /var is mounted early -- keeps the
> > > filesystem sane, and it's just a simple matter of programming,
> > > rather than
Martin Schulze <[EMAIL PROTECTED]> writes:
>
> The Debian Projecthttp://www.debian.org/
> Debian GNU/Linux 3.1 updated (r1) [EMAIL PROTECTED]
> December 20th, 2005
On Tue, Dec 20, 2005 at 01:53:07PM -0600, Steve Greenland wrote:
> On 20-Dec-05, 12:54 (CST), Graham Wilson <[EMAIL PROTECTED]> wrote:
> > I've found vim's defaults are unreadable except on a white background,
> > since that is what vim assumes you have by default.
>
> Actually, I do use a white
On Wednesday 21 December 2005 12.23, Thomas Hood wrote:
> I don't think that it is ridiculous to require that every package have a
> team behind it---i.e., at least two maintainers. First, if someone can't
> find ONE other person willing to be named as a co-maintainer of a given
> package then I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lars Wirzenius <[EMAIL PROTECTED]> writes:
> ke, 2005-12-21 kello 10:28 +, Roger Leigh kirjoitti:
>> For this task, you might find schroot(1) useful. It's a means of
>> accessing chroot environments, but it supports LVM snapshots as one
>> method
Anand Kumria <[EMAIL PROTECTED]> writes:
> On Fri, Dec 16, 2005 at 03:56:30PM +0100, Goswin von Brederlow wrote:
>> Anand Kumria <[EMAIL PROTECTED]> writes:
>>
>> > I'd like to congratulate our ftp-master team on their ability to timely
>> > process packages progressing through the NEW queue.
>>
On 20.12. 08:36, Steve Greenland wrote:
> I'm still missing the incentive. Joey Hess wrote in his earlier message
> that "It's now only marginally larger than nvi". It achieves that by
> removing many of the features that distinguish vim from nvi, to the
> point that my guess is that most of thos
Lars Wirzenius <[EMAIL PROTECTED]> wrote:
> * Less strong ownership of packages.
(snip)
> This idea hasn't been tested. It could be tested if
> some group of maintainers declared that some or all
> of their packages were part of the experiment, that
> anyone could
Andreas Fester <[EMAIL PROTECTED]> writes:
> Benjamin Mesing wrote:
>>>"Please (re)check, if the package can be built by g++ > 3.4
>>> on [hppa/arm/m68k]"?
>>>
>>>Do I simply remove the explicit build dependency on g++,
>>>upload the package and wait if it succeeds (and probably
>>>create another
On Wed, Dec 21, 2005 at 03:31:26PM +0100, Christian Fromme wrote:
> On 20.12. 08:36, Steve Greenland wrote:
>
> > I'm still missing the incentive. Joey Hess wrote in his earlier message
> > that "It's now only marginally larger than nvi". It achieves that by
> > removing many of the features that
On Wed, Dec 21, 2005 at 03:31:26PM +0100, Christian Fromme wrote:
> > vaguely dissastified by the change. If the result of this is that a)
> > base is not smaller, and b) vim users still have to install vim-nottiny,
> > and c) nvi users now have to install nvi, I don't think it's a net win.
> As mu
Russ Allbery <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>> Russ Allbery <[EMAIL PROTECTED]> writes:
>
>>> Funny, I just did a Google search for
>
>>> site:www.debian.org cvs repository www.debian.org
>
>>> and there it was, plain as day.
>
>> That implies th
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:
> On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote:
>> I've run some scripts to find out the size of binary pakcages in debian
>> and how theycould be made smaller, here's the results:
>
> My comments are about the same as on IRC:
>
Olaf van der Spek <[EMAIL PROTECTED]> writes:
> On 12/18/05, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote:
>> On Sun, Dec 18, 2005 at 02:56:10PM +0100, Olaf van der Spek wrote:
>> > Why would this be huge?
>> > Why is it that hard to plugin another codec?
>>
>> You'd have to rewrite about every
[Petter Reinholdtsen]
> One user is bootlogd, needing before init is started to store
> stats about the boot. That is before both these points in the boot.
I managed to write bootlogd when I intended to write bootchartd. That
is the package making statistics about the boot process.
[Anthony To
Raphael Hertzog <[EMAIL PROTECTED]> writes:
> On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote:
>> Hi
>>
>> I've run some scripts to find out the size of binary pakcages in debian
>> and how theycould be made smaller, here's the results:
>>
>> http://www.linuks.mine.nu/sizematters/
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> Peter Samuelson wrote:
>> Given the need, and now the reality, of /run, is there any need for
> a
>> separate /var/run?
>
>
> "Need" is probably too strong, but it's certainly convenient if we
> don't
> have to change the way we currently use /va
On 12/21/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> uncompressor
Hi,
While I'm a addicted vim user, the build-dependencies of vim(-tiny) is a bit
scary for a base package. While we do not have requirements of base
packages of being easily buildable, changing to vim-tiny will make bootstrapping
a basic debian system again a little bit harder.
nvi:
Build-Depen
Michelle Konzack <[EMAIL PROTECTED]> writes:
> Am 2005-12-12 13:23:01, schrieb Goswin von Brederlow:
>
>> Actualy one thing apt could do:
>>
>> [EMAIL PROTECTED]:~% host security.debian.org
>> security.debian.org A 82.94.249.158
>> security.debian.org A 128.101.80.133
>> secur
Michelle Konzack <[EMAIL PROTECTED]> writes:
> Am 2005-12-06 09:53:43, schrieb Ivan Adams:
>> Hi again,
>> in my case:
>> I have slow internet connection. BUT I have friends with the same
> ^^^
>> connection
>> in my local area network, who have apt-proxy.
>> My goal
On 12/21/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> > Who need PARALELISM and who has a bandwidth of more then 8 MBit?
>
> I have 10240kBit downstream and get way less from security.debian.org.
> Especialy when there is a security release of X or latex.
But parallel downloads won't solv
* Thomas Hood <[EMAIL PROTECTED]> [2005:12:21 12:23 +0100]:
> I don't think that it is ridiculous to require that every package have a
> team behind it---i.e., at least two maintainers. First, if someone can't
> find ONE other person willing to be named as a co-maintainer of a given
> package the
Olaf van der Spek <[EMAIL PROTECTED]> writes:
> On 12/21/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>> uncompressor
> $ uncompressor
> -bash: uncompressor: command not found
>
> This solution doesn't look usable in scripts and user have to use a
> more complex syntax.
You have to replac
On Wed, 2005-12-21 at 16:12 +0100, Goswin von Brederlow wrote:
> "Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:
>
> > On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote:
[snip]
> The transition itself would go completly unadministered. Once dpkg is
> switched to default to a diffe
[Thomas Hood]
> I don't think that it is ridiculous to require that every package
> have a team behind it---i.e., at least two maintainers. First, if
> someone can't find ONE other person willing to be named as a
> co-maintainer of a given package then I would seriously doubt that
> that package
On Wed, 2005-12-21 at 17:08 +0100, Petter Reinholdtsen wrote:
> At the very minimum, I believe all base packages (those installed by
> debootstrap by default) should have co-maintainers.
This sounds like a good compromise between the two sides of this
discussion.
Thijs
signature.asc
Descriptio
On Wed, Dec 21, 2005 at 11:00:15AM -0500, Erinn Clark wrote:
> * Thomas Hood <[EMAIL PROTECTED]> [2005:12:21 12:23 +0100]:
> > Team maintainership is working very well for some other distributions.
>
> That may be true, but it's not a good argument for forcing such a
> situation in Debian.
I agr
I wrote:
> I don't think that it is ridiculous to require that every package have
> a team behind it---i.e., at least two maintainers. First, if someone
> can't find ONE other person willing to be named as a co-maintainer of
> a given package then I would seriously doubt that that package (or
> th
> True. However, the issue in question is whether or not it would be
> better if they maintained in teams.
I imagine that it would not be better.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
* Thomas Hood <[EMAIL PROTECTED]> [2005:12:21 17:32 +0100]:
> Erinn Clark wrote:
> > There are plenty of people who are maintaining packages alone
> > that are doing an excellent job
>
> True. However, the issue in question is whether or not it would be
> better if they maintained in teams.
>
>
On Wed, Dec 21, 2005 at 05:32:21PM +0100, Thomas Hood wrote:
> This is not a fair characterization of what the introduction of
> a two-maintainer rule would be doing. No one should be insulted
> by general rule changes designed to make Debian work better.
I think a two-maintainer rule is a bit ar
Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> You just try to make a point out of buildd.net not having a direct
> source link which is completly irelevant imho.
Hey, I don't care if there's a direct link or not. I care if the source
is available for anyone to go download. If it's availabl
Thijs Kinkhorst <[EMAIL PROTECTED]> writes:
> On Wed, 2005-12-21 at 17:08 +0100, Petter Reinholdtsen wrote:
>> At the very minimum, I believe all base packages (those installed by
>> debootstrap by default) should have co-maintainers.
> This sounds like a good compromise between the two sides of
Package: general
Followup-For: Bug #279983
The cdrom doesnot work too. One of them randomly works.
This happend with two computers with about same debain version, but
different cdrom boxes.
chypre:~# mount /cdrom/
mount: wrong fs type, bad option, bad superblock on /dev/sr0,
missing codep
On Wed, Dec 21, 2005 at 02:07:30AM +0200, Lars Wirzenius wrote:
> Several ideas have been floating around for years on how to improve
> this situation, of which I'd like to mention three. While I've here
> used the number of bugs as the measure of a package's quality,
> the same ideas might help wi
Package: wnpp
Owner: Debian Xfce Maintainers <[EMAIL PROTECTED]>
Severity: wishlist
* Package name: thunar
Version : 0.1.4svn+r1885
Upstream Author : Benedikt Meurer <[EMAIL PROTECTED]>
* URL : http://thunar.xfce.org
* License : GPL
Description : Xfce File
Package: wnpp
Owner: Debian Xfce Maintainers <[EMAIL PROTECTED]>
Severity: wishlist
* Package name: orage
Version : 4.3.1.22svn
Upstream Author : Mickaël Graf <[EMAIL PROTECTED]>
* URL : http://foo-projects.org/~korbinus/orage/
* License : GPL
Description
Em Qua, 2005-12-21 às 14:34 +, Matthew Garrett escreveu:
> I think I've said this before, but I have no objections to anyone
> uploading any of my packages. I'd be even happier if anyone who did so
> was willing to enter into some sort of reciprocal agreement.
So do I, but I would be really ha
Erinn Clark wrote:
> For maintainers who are doing a lot of good work, there's simply not
> enough to justify more people. Once there's already a certain level of
> efficiency, adding another person is not going to increase it, and will
> likely decrease it. I can't see the point of enforcing this
Jeroen van Wolffelaar wrote:
> I don't think it's easily possible to count on people contributing to
> this thread to be representative, but I do think (b) is certainly less
> than it seems: Even vim-tiny would I think be liked more than nvi --
So do I. As others have said, vim users can run vim-t
On Wed, Dec 21, 2005 at 10:12:56AM -0800, Russ Allbery wrote:
> This may sound heretical to you, but I don't consider software to be
> DFSG-free unless there's actually a copy somewhere that people can get to.
> If the source is unavailable, the software isn't free, regardless of what
> theoretica
David Nusinow wrote:
> I agree that we shouldn't force teams on anyone, but I'd like to see more
> large-scale teams encompassing loosely connected smaller packages[0]. If,
> for no other reason, than for developers to claim ownership of (and by
> extension responsibility for) the whole project rat
(Please followup to -project if you're replying on the subject of
holding polls like this -- the discussion on holding polls is not
technical, so does not belong to -devel. For opinions on nvi versus vim,
please reply elsewhere in the current thread, this subthread isn't the
place for it)
For the
On Wednesday 21 December 2005 13:33, David Nusinow wrote:
> I agree that we shouldn't force teams on anyone, but I'd like to see more
> large-scale teams encompassing loosely connected smaller packages
This will also bring the side effect of making it easier for non-DDs: Now
instead of finding a s
Nathanael Nerode <[EMAIL PROTECTED]> writes:
> aqsis
It would be nice if whoever uploads this could also address #324025
(64-bit FTBFS, patch available).
> It would be very nice to finish these off. Once all these libraries are
> transitioned, the remaining C++ programs using the old ABI can
I demand that Alexander E. Patrakov may or may not have written...
> Kay Sievers wrote:
>> There is also the plan to do parallel device probing inside the kernel
>> some day, that will make the situation of relying on kernel names even
>> more fragile.
> Right, this means that the way of passing
On Mon, Dec 19, 2005 at 09:56:27AM +0100, Olaf van der Spek wrote:
> On 12/19/05, Andrew Suffield <[EMAIL PROTECTED]> wrote:
> > On Sun, Dec 18, 2005 at 08:27:36PM +0100, Florian Weimer wrote:
> > > * Steinar H. Gunderson:
> > >
> > > > My comments are about the same as on IRC:
> > > >
> > > > -
In article <[EMAIL PROTECTED]> you wrote:
> aren't really there anyway, I have never heard of non-swappable in-memory
> filesystems.
the ram disks, afaik.
> Those are: Solaris, *BSD and The Hurd. Solaris and all of the BSDs can do
> VM-based filesystems that are nearly identical to tmpfs. I don
ke, 2005-12-21 kello 14:19 +, Roger Leigh kirjoitti:
> The difference for a minimal chroot is not too great. The main
> advantage of schroot LVM snapshotting is that the time is constant
> irrespective of the size of the LV (it's copy-on-write), whereas for
> tar it is linear. For slow machin
On Wed, Dec 21, 2005 at 09:14:16PM +0100, Jeroen van Wolffelaar wrote:
> (Please followup to -project if you're replying on the subject of
> Because this is certainly not the first time I was curious on the
> opinion of the so called "Silent majority" (if such beast exists at
> all), I decided to s
On Wed, Dec 21, 2005 at 12:23:32PM +0100, Thomas Hood wrote:
> I would support requiring team maintainership because TM will be
> beneficial in almost all cases and making it a requirement it cuts off a
> lot of useless discussion.
Cute theory, gaping hole. Making a group of people responsible for
On Wed, 21 Dec 2005, Olaf van der Spek wrote:
> On 12/21/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> > > Who need PARALELISM and who has a bandwidth of more then 8 MBit?
> >
> > I have 10240kBit downstream and get way less from security.debian.org.
> > Especialy when there is a security r
On Wed, Dec 21, 2005 at 08:10:03PM +0100, Thomas Hood wrote:
> It turns out that there is no need for them to be hurt at all. Lone
> can carry on working as before and find a co-maintainer who won't get
> in his way. But when Lone falls off his horse he'll be glad that Tonto
> is nearby.
...
Glenn Maynard <[EMAIL PROTECTED]>
> I have no sympathy for the notion of a "silent majority". If you have an
> opinion, speak it. [...]
Hard if you can't hear the question above the NOISE.
> wonder how many people will vote for nvi bacause "nvi is more like
> regular vi than vim". This is impo
Andrew Suffield wrote:
> Cute theory, gaping hole. Making a group of people responsible for
> something, rather than a single person, means that they can all spend
> all their time passing the buck and hoping that one of the others
> takes care of it, with the result that nobody does.
This is a l
On Wed, Dec 21, 2005 at 04:56:35PM +0200, Riku Voipio wrote:
> While I'm a addicted vim user, the build-dependencies of vim(-tiny)
> is a bit scary for a base package. While we do not have requirements
> of base packages of being easily buildable, changing to vim-tiny
> will make bootstrapping a b
Package: wnpp
Severity: wishlist
Owner: Mathieu Parent <[EMAIL PROTECTED]>
* Package name: musmap
Version : 0.9.0
Upstream Author : Mathieu Parent <[EMAIL PROTECTED]>
* URL : http://musmap.sf.net/
* License : GPL
Description : Advanced web mapping interfac
On 21-Dec-05, 13:10 (CST), Thomas Hood <[EMAIL PROTECTED]> wrote:
> How much would this rule "hurt" those lone ranger maintainers you are
> talking about, the ones who package everything perfectly and cannot
> possibly do any better?
>
> It turns out that there is no need for them to be hurt at a
On 21-Dec-05, 16:11 (CST), MJ Ray <[EMAIL PROTECTED]> wrote:
> Current unstable Installed-Size:
> vim-tiny ranges from 696 to 1852 with a median of 898k.
> nvi ranges from 560 to 1040 with a median of 648k
"Ranges"? Over what? Architectures?
> vim-tiny depends on the 200k-ish vim-common too, so
On Wed, Dec 21, 2005 at 10:11:14PM +, MJ Ray wrote:
> - vim-tiny is on fewer platforms than nvi, which seems as
> important as size or accuracy of emulation.
Vim still runs in 16-bit DOS, and I think it even has a functioning OS/2
build, but it won't run on all of the platforms Debian supports
In article <[EMAIL PROTECTED]>,
Anthony Towns wrote:
>/var/run has always been the right place in the namespace; it's just
>not been usable for technical reasons. If we fix the technical reasons,
>all is good.
Well there is on more technical solution that might have been overlooked.
Why not crea
Glenn Maynard <[EMAIL PROTECTED]>
> On Wed, Dec 21, 2005 at 10:11:14PM +, MJ Ray wrote:
> > - vim-tiny is on fewer platforms than nvi, which seems as
> > important as size or accuracy of emulation.
>
> Vim still runs in 16-bit DOS, and I think it even has a functioning OS/2
> build, but it wo
Steve Greenland <[EMAIL PROTECTED]>
> On 21-Dec-05, 16:11 (CST), MJ Ray <[EMAIL PROTECTED]> wrote:
> > Current unstable Installed-Size:
> > vim-tiny ranges from 696 to 1852 with a median of 898k.
> > nvi ranges from 560 to 1040 with a median of 648k
> "Ranges"? Over what? Architectures?
Yes, arch
On Wed, Dec 21, 2005 at 12:23:32PM +0100, Thomas Hood wrote:
> I don't think that it is ridiculous to require that every package have a
> team behind it---i.e., at least two maintainers. First, if someone can't
Sorry, but I'm having an issue with the word "require" here. Call me
idealistic, but
On Thu, Dec 22, 2005 at 02:28:23AM +, MJ Ray wrote:
> Who knows? It's not currently built for as many. For hurd-i386,
> hppa and s390, nvi is a working editor and vim-tiny isn't. I
> can't remember what counts as support right now (URL anyone?)
I'll have to punt on that one, since I know nothi
Glenn Maynard <[EMAIL PROTECTED]> writes:
> I much prefer vim-tiny over nvi, others have agreed (at least Frans Pop
> and Joey Hess), and not one person so far has actually said they prefer
> nvi over vim--just that they prefer its defaults, which has been
> addressed.
Just to be completely unamb
Package: wnpp
Severity: wishlist
Owner: Russell Stuart <[EMAIL PROTECTED]>
* Package name: flowscan-cuflow
Version : 1.5
Upstream Author : Johan Andersen <[EMAIL PROTECTED]>, Matt Selsky <[EMAIL
PROTECTED]>
* URL : http://www.columbia.edu/acis/networks/advanced/CUFlow
On Thu, 22 Dec 2005 06:29, Darren Salt wrote:
> I demand that Alexander E. Patrakov may or may not have written...
>
> > Kay Sievers wrote:
> >> There is also the plan to do parallel device probing inside the kernel
> >> some day, that will make the situation of relying on kernel names even
> >> mo
On Wed, 21 Dec 2005 12:23:32 +0100, Thomas Hood
<[EMAIL PROTECTED]> said:
>> Mandatory teams for packages seems ridiculous to me.
>> Lots of packages are so small that having to arrange a team for
>> them, even if it is only the effort to set up and subscribe to a
>> team mailing list, is waste
On Wed, 21 Dec 2005 17:52:21 -0600, Steve Greenland <[EMAIL PROTECTED]> said:
> On 21-Dec-05, 13:10 (CST), Thomas Hood <[EMAIL PROTECTED]> wrote:
>> How much would this rule "hurt" those lone ranger maintainers you
>> are talking about, the ones who package everything perfectly and
>> cannot poss
On Wed, 21 Dec 2005 02:08:13 +, Matthew Garrett <[EMAIL PROTECTED]> said:
> Francesco Poli <[EMAIL PROTECTED]> wrote:
>> That is completely irrelevant. The FSF doesn't use the DFSG as
>> freeness guidelines.
> But the DFSG are intended to be a more detailed description of what
> free softwar
Miquel van Smoorenburg wrote:
> mount --move . /var/run
mount --move only works in 2.6, not in 2.4. I think something similar
was suggested earlier in the thread and it is a nice solution for linux
2.6 systems.
--
see shy jo
signature.asc
Description: Digital signature
MJ Ray wrote:
> Who knows? It's not currently built for as many. For hurd-i386,
> hppa and s390, nvi is a working editor and vim-tiny isn't. I
> can't remember what counts as support right now (URL anyone?)
Oh, come on. vim-tiny entered the archive this week. The fact that we
have some slow buildd
Steve Greenland wrote:
> Okay, so that's not "about the same". Stefano? If the above numbers are
> correct, then the best case is a (696+200-560)==336K increase. Last I
> heard, the CD builders considered that a non-trivial amount of space. Or
> am I confusing the boot image with base?
Anything ov
MJ Ray wrote:
> The increase is between 101% for ia64 and 58% for i386.
> vim-tiny+vim-common is smallish by current standards, but
> neither "about the same" as nvi, nor "only marginally larger".
> Was there a maths error near the top of this thread?
The very top of this thread contained a forwar
On Monday 19 December 2005 11:49, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > If /run is tmpfs, it means everything stored there eats virtual memory.
> > So a musch metter strategy would be to move everything from /run to
> > /var/run at the end of the
On Thu, 22 Dec 2005 04:32, David Nusinow wrote:
> On Wed, Dec 21, 2005 at 05:32:21PM +0100, Thomas Hood wrote:
> > This is not a fair characterization of what the introduction of
> > a two-maintainer rule would be doing. No one should be insulted
> > by general rule changes designed to make Debian
On Monday 19 December 2005 23:04, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 19, 2005 at 01:49:37AM +0100, Bernd Eckenfels wrote:
> > tmpfs stores run ressources in vm more efficiently (since they are
> > otherwise in th buffercache and the filesystem).
>
> Quite the contrary. tmpfs need
On Wednesday 21 December 2005 01:27, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 20, 2005 at 10:09:43PM +1000, Anthony Towns wrote:
> > The other aspect is that /var's the place for stuff that varies during
> > normal use; introducing some other place for the same thing is redundant
> > a
Riku Voipio wrote:
> While I'm a addicted vim user, the build-dependencies of vim(-tiny) is a bit
> scary for a base package. While we do not have requirements of base
> packages of being easily buildable, changing to vim-tiny will make
> bootstrapping
> a basic debian system again a little bit h
On Wednesday 21 December 2005 19.24, Russ Allbery wrote:
[mandatory comaintainers]
> I think that the energy used to define these sorts of procedures is
> probably better used finding a package with a large bug count and
> volunteering to work with the maintainer to try to get the bug count
> down.
On Wednesday 21 December 2005 20.10, Thomas Hood wrote:
> It turns out that there is no need for them to be hurt at all. Lone
> can carry on working as before and find a co-maintainer who won't get
> in his way. But when Lone falls off his horse he'll be glad that Tonto
> is nearby.
Except tha
On Thu, 22 Dec 2005, Russell Coker wrote:
> On Monday 19 December 2005 23:04, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> > On Mon, Dec 19, 2005 at 01:49:37AM +0100, Bernd Eckenfels wrote:
> > > tmpfs stores run ressources in vm more efficiently (since they are
> > > otherwise in th buffercache and t
1 - 100 of 107 matches
Mail list logo
