Hi, debian-devel-italian
#include hallo.h
* 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.
--
pearl auf tetrinet.debian.net sind leute,
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
aqsis
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
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
2005/12/20, Anthony Towns aj@azure.humbug.org.au:
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
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 before it
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=testingarchive=no
Shows four Archived bugs of normal severity. As an example, look at the
last one:
http://bugs.debian.org/322353
This version is
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'
Anthony Towns aj@azure.humbug.org.au 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,
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 quick
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 arguing over
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.
Does
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 those who
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 NMU
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 package version with
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 much as
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 that you already
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:
- Disk
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 single tool in
[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
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/
FWIW :
[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 /var/run/.
How
On 12/21/05, Goswin von Brederlow [EMAIL PROTECTED] wrote:
uncompressor file.tar.whatever | tar -x
$ uncompressor
-bash: uncompressor: command not found
This solution doesn't look usable in scripts and user have to use a
more complex syntax.
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:
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
security.debian.org
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 is: When I need
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 solve
* 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 then I
Olaf van der Spek [EMAIL PROTECTED] writes:
On 12/21/05, Goswin von Brederlow [EMAIL PROTECTED] wrote:
uncompressor file.tar.whatever | tar -x
$ uncompressor
-bash: uncompressor: command not found
This solution doesn't look usable in scripts and user have to use a
more complex syntax.
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 different
[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 (or
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
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 agree that
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
that
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.
Forcing
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
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 available
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 this
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
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 with
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
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 as
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
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
theoretical
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 rather
(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
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 be
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:
- Disk space is cheap,
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't
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 machines
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 simply
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 release of X
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 important
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
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
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 interface
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 all.
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 nvi
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 aj@azure.humbug.org.au 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
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 won't run
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, architectures.
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 I
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 nothing
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
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
more fragile.
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 wasteful. Not
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 possibly do any
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 software (a term
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 buildds
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 over a
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 forwarded
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 boot
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 work
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 needs vm
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
and thus
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
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 that
1 - 100 of 186 matches
Mail list logo
