Hi,
currently we seem to have no clear policy in Debian how to handle
the question: Shall a service started once its installed or not?
The current state of affairs is that some packages start after beeing
installed, some don't, because they don't have a reasonable default
configuration and some
On Wed, Apr 01, 2009 at 06:31:04PM +0300, Lars Wirzenius wrote:
ke, 2009-04-01 kello 17:03 +0200, Patrick Schoenfeld kirjoitti:
There are clear disadvantages with this:
- The administrator has no way to influence the decision weither
a service shall run directly after installation
On Wed, Apr 01, 2009 at 05:38:29PM +0200, Josselin Mouette wrote:
Le mercredi 01 avril 2009 à 17:03 +0200, Patrick Schoenfeld a écrit :
* We add a new configuration file (possibly /etc/rc.conf because thats
a file that exists in different distributions and has a similar meaning)
which
Hi,
On Wed, Apr 01, 2009 at 06:12:29PM +0200, Michael Biebl wrote:
I don't like this idea of RUN=yes variables in /etc/default.
1.) There is already a documented interface, how to disable a service (i.e.
renaming the S?? symlinks for that runlevel to K??). Adding another layer to
do
this
Hi,
On Wed, Apr 01, 2009 at 09:50:47PM +0300, Lars Wirzenius wrote:
ke, 2009-04-01 kello 20:30 +0200, Patrick Schoenfeld kirjoitti:
You finished reading my mail after that paragraph, didn't you? ;)
Pretty much. It looked long and complicated and I was in a hurry. I
skimmed it but I see now
On Wed, Apr 01, 2009 at 11:39:34PM +0200, Adam Borowski wrote:
On Wed, Apr 01, 2009 at 05:03:27PM +0200, Patrick Schoenfeld wrote:
the question: Shall a service started once its installed or not?
The current state of affairs is that some packages start after beeing
installed, some don't
On Wed, Apr 01, 2009 at 03:54:22PM -0700, Steve Langasek wrote:
On Wed, Apr 01, 2009 at 08:38:46PM +0200, Patrick Schoenfeld wrote:
Well, its only about *new* services after installation. The intention
behind that is that some people don't like to run un- or half-configured
daemons
On Wed, Apr 01, 2009 at 06:05:48PM -0700, Steve Langasek wrote:
I think that renaming and/or removing the init script symlinks is the
Right Thing To Do, but the tools we have for doing this are awful. I
think it would be a great solution if update-rc.d gained the following
features:
I
Hi Steve,
On Wed, Apr 01, 2009 at 06:51:29PM -0700, Steve Langasek wrote:
On Wed, Apr 01, 2009 at 08:56:43PM +0200, Patrick Schoenfeld wrote:
On Wed, Apr 01, 2009 at 06:12:29PM +0200, Michael Biebl wrote:
I don't like this idea of RUN=yes variables in /etc/default.
1.) There is already
On Thu, Apr 02, 2009 at 12:07:25PM -0700, Steve Langasek wrote:
On Thu, Apr 02, 2009 at 01:12:25PM +0200, Patrick Schoenfeld wrote:
On Wed, Apr 01, 2009 at 06:05:48PM -0700, Steve Langasek wrote:
I think that renaming and/or removing the init script symlinks is the
Right Thing To Do
On Thu, Apr 02, 2009 at 12:41:20PM -0700, Steve Langasek wrote:
Indeed. Didn't think about the possibility of diversions. I guess
diverting the init scripts could be a solution (besides that it needs
some further work to the service managing utility). Then I'd
whole-heartedly agree with
Hi Olivier,
thanks for stepping up and working on this (also for your work on
mantis -- will come back to this seperated).
On Wed, May 20, 2009 at 10:08:59AM +0200, Olivier Berger wrote:
Le lundi 18 mai 2009 à 07:42 +0100, Neil Williams a écrit :
On Sun, 17 May 2009 23:18:40 +0100
Hi,
On Fri, Jul 17, 2009 at 09:41:05AM +0200, Sandro Tosi wrote:
http://lists.debian.org/debian-devel-announce/2008/09/msg6.html
Thanks for the pointer, but I'm referring to
the upload queue, is pointed elsewhere during that time,
not to the general reorganization of upload queues
On Wed, Dec 03, 2008 at 04:33:15PM +0100, Martin Wuertele wrote:
I completely disagree. It's a welcome benefit if packages of inferior
quality are prevented from entering the archive in the first place imo.
I agree with this and we should not get rid of it.
If you want to test packages not
Hi,
On Fri, Dec 12, 2008 at 03:21:50PM +0100, Daniel Leidert wrote:
Well, licensecheck(1) exists. Maybe many packagers don't know it?
Well, licensecheck is a unreplaceable tool, but it cannot be a unique
ressource for copyright/license checking, as it suffers from bugs
(and/or unknown patterns)
On Mon, Dec 22, 2008 at 05:03:03PM +0100, Bernhard R. Link wrote:
* Michael Casadevall sonicmcta...@gmail.com [081222 12:14]:
The thought of a rolling release system has a lot of appeal to me for
desktop usage, but not for server usage, since each update contains
the potential to break
Hi,
On Mon, Jan 05, 2009 at 08:40:03PM +0100, Luk Claes wrote:
Ralf Treinen and I are looking for help with the GPG Key Signing
Coordination page.
I'm quiet interested in helping out a bit, but for now undecided.
Ralf Treinen and I have been taking care of this page the last years but
I
Hi,
On Mon, Jan 05, 2009 at 09:56:23PM +0100, Ralf Treinen wrote:
It is not a big time investment. The most time-consuming work consists in
regular cleanups (removing bogus entries and key signing requests that have
been satisfied). Maybe once per year, taking several hours of work (since
On Sun, Feb 15, 2009 at 09:00:22PM -0600, William Pitcock wrote:
There is also questions concerning why you would want to package
something that has effectively a dead upstream, and many code flaws
which could result in security issues in the future.
Uh? Since when is Unrealircd dead upstream?
Hi,
On Mon, Feb 16, 2009 at 11:14:52AM +0100, Josselin Mouette wrote:
I wanted to discuss the python-support directory tree location (and
similar issues) with the FHS maintainers, however it occurred to me that
the mailing list is completely dead, and the standard doesn’t seem very
alive
Juliusz Chroboczek wrote:
Popcon gives 23000 for iceweasel, 500 for dillo, and 18 for netsurf.
(Correct me if I'm wrong, but I believe that konqueror statistics are
not significant since it's also used as a file manager.)
If that's not a monoculture, I don't know what is.
The point is that
Faidon Liambotis wrote:
IMHO, it's not the ftp-master's job to check with each upload if a
number of DDs follow the social contract as they should.
No? What exactly *is* there job then? According to
http://ftp-master.debian.org/REJECT-FAQ.html
it *is* one of their jobs.
Regards,
Hi,
IANADD but...
Christian Perrier wrote:
Then file a bug against *apt* packages and p.d.o to have them support
displaying info from that field, before or after the d-d-a
announcement.
you wrote what I thought when I read this proposal. After all it makes
sense to first add support for the
Package: wnpp
Severity: wishlist
Owner: Patrick Schoenfeld [EMAIL PROTECTED]
* Package name: innotop
Version : 1.4.3
Upstream Author : Baron Schwartz baron at xaprb dot com
* URL : http://innotop.sourceforge.net
* License : GPL
Programming Lang: Perl
Mike Hommey schrieb:
What are we going to see next ? Yet another package because someone else
will feel none of gitpkg or git-buildpackage fit his needs ?
Whats so bad about this? FOSS is much about choice, isn't it? Why
shouldn't the user have the choice to select from different tools? In my
Steve Greenland wrote:
It seems to me that module-assistant should recommend/depend on bzip2,
since it is presumably m-a that is calling it.
Since it seems as if not every module package is distributed as a bzip2
tarball I think Recommends would be suffice. Because it is a strong, but
not
Hamish Moffatt schrieb:
True, but what would be the harm in depending on bzip2? Given that
Well, i don't see a harm caused by that. But IMHO it is just a question
of how to read the policy, as it states the (spongelike) sentence:
The Depends field should be used if the depended-on package is
Package: wnpp
Severity: wishlist
Owner: Patrick Schoenfeld [EMAIL PROTECTED]
* Package name: gimmix
Version : 0.4.1
Upstream Author : Priyank Gosalia [EMAIL PROTECTED]
* URL : http://gimmix.berlios.de/index.php
* License : GPL
Programming Lang: C
Romain Beauxis schrieb:
Well the real solution to solve this is to count the ratio of packages that
provides sources as a bzip2 tarball with regard to gzip tarballs.
Why do you call it the *real* solution? What makes the solution better
over the one I suggested?
If this is a vast majority,
Romain Beauxis wrote:
Let's say that it's the quantitative approach. Other approaches are just
chatty chatty.
Well, quantitative must not always be the best thing. And if it should
be an argument one should create *proper* stats.
(This search is not adequate, it matches non-module packages
Bastian Blank wrote:
You already built the kernel and therefor have a compiler installed.
But m-a would install all the clutter anyways, wouldn't it?
Regards,
Patrick
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Don Armstrong wrote:
The reason why maintainers may be checked far more thoroughly is
because the average employee of Google or Microsoft can't make changes
to any piece of software company wide, nor do they vote on the
direction of the entire company. [It's also far easier to fire someone
Piotr Roszatycki wrote:
Why just new maintainers are checked so precisely? The old Debian
Because the old Debian developers should have been checked already.
developers also can make a threat for Debian Project. It's logical,
Yeah, off course *can* they do this. But it is impossible to check
Don Armstrong wrote:
Those Developers who haven't gone through the NM process for the most
part have been checked by a far more rigorous procedure: they've
actually contributed and done the work. [Indeed, all developers are
continually being rechecked by this metric.]
Eh.. i agree with most
Don Armstrong schrieb:
If you're saying that it can't be evaluated at all, I disagree.
No. Don't get me wrong, because that is /absolutely/ not what I wanted
to say. But you said (as far as I have understood) that those Debian
Developers that have /not/ gone through the NM process has proven
Neil Williams wrote:
The work of those DD's is constantly reviewed and checked by other DD's
- during mass bug filing, NMU's, bug triage etc.etc.
And the work of non-DD contributors isn't?
Come on, you know that I don't speak against how it is currently, but
against the /argumentation/. It is
Don Armstrong wrote:
That's actually backwards from what I've said. My argument is not that
DDs should be trusted, but that DDs are in a position where they can
Well, but actually it does not work without a level of trust. And as a
community that tries to build up a good, reliable and
Package: wnpp
Severity: wishlist
Owner: Patrick Schoenfeld [EMAIL PROTECTED]
* Package name: libmowgli
Version : 0.4.0
Upstream Author : Atheme Project
* URL : http://www.atheme-project.org/projects/mowgli.shtml
* License : BSD
Programming Lang: C
Package: wnpp
Severity: wishlist
Owner: Patrick Schoenfeld [EMAIL PROTECTED]
* Package name: detox
Version : 1.1.1
Upstream Author : Doug Harple
* URL : http://detox.sourceforge.net
* License : BSD
Programming Lang: C
Description : utility to cleanup
Hi,
On Sat, Dec 01, 2007 at 09:21:33PM -0500, Daniel Schepler wrote:
i386 using dpkg-buildpackage -j3 on a dual core machine. The results as
before are at http://people.debian.org/~schepler/build-logs/bymaint.html .
I am not sure how to handle these problems with my packages. Currently
Hi Bernhard,
On Mon, Dec 03, 2007 at 12:21:45PM +0100, Bernhard R. Link wrote:
The problem is in upstream's Makefile.in:
thanks for the good explanation. Also to Daniel whose hint already pointed me
in the right direction. Its already fixed in latest upload.
Thanks,
Best Regards
Patrick
--
On Thu, Dec 06, 2007 at 08:15:08AM +, Frank Küster wrote:
Indeed - but there's a bug, #432564, requesting to change it.
Hmm. Which seems quiet controversal. Maybe the DD should find a decision
on this, before anything else? But this topic is again an example why
changing debian/rules to
Hi,
On Sat, Jan 26, 2008 at 12:40:14AM +0900, Osamu Aoki wrote:
This seems to be much cleaner than dpatch or quilt. Also with the help
of gitk, history is much more visible. I look forward to see it matured
and accepted.
personally I am a fan of the diversity in the Debian project. Its
Hi Matt,
On Wed, Feb 06, 2008 at 11:25:19AM +, Matthew Johnson wrote:
I'd have said that it would be more sensible to define a reasonable subset
of quilt features. A set of patches with comments at the top and a
yes, this sounds reasonable. But I'm not a quilt user and therefore
don't know
Hi Pierre,
(BTW. there is no need to CC me with your answers, I did not ask for
that as I am subscribed to the list :-)
On Sat, Feb 09, 2008 at 12:50:46AM +0100, Pierre Habouzit wrote:
quilt is way more powerful to refresh patches when a new upstream
occurs. It does what it can do best
On Tue, Feb 26, 2008 at 09:36:32AM +0100, Franklin PIAT wrote:
What about a bug... Bugs are our pets : we take care of them.
Oh god. No, please, everything but not a bug as mascot. You'll be unable
to communicate to our users that we _care_ for bugs. It will bring the
reputation to Debian, that
Hi,
On Tue, Feb 26, 2008 at 09:56:40AM +0100, martin f krafft wrote:
also sprach Franklin PIAT [EMAIL PROTECTED] [2008.02.26.0936 +0100]:
What about a bug... Bugs are our pets : we take care of them.
I guess I just repeat myself when I question why we need to join the
free software zoo. Is
Package: wnpp
Severity: normal
Hi,
as upstream is considering some changes in the upgrade path that will
make upgrading with pure sql files quiet hard and they never really
supported upgrading through pure sql files (and therefore dbconfig-common)
I could need someone to help with maintaining
Hi Christoph,
On Sun, Apr 20, 2008 at 03:47:38PM +0200, Christoph Haas wrote:
I'm encountering a lot of bitching with using svn-inject (from
svn-buildpackage) over an NFS share. A quick survey of fellow DDs told me
of which kind? Personally I do use svn-buildpackage on a NFSv4 mounted
home
Hi,
On Sat, Jun 21, 2008 at 01:38:07PM -0400, Roberto C. Sánchez wrote:
But backports.org is still unofficial.
so what? Its unofficial, but still its of great use for the most Debian
users.
If it were permitted, then what
would happen when other unofficial repository maintainers want to
Hi,
On Sun, Jun 22, 2008 at 01:08:30PM -0500, Adam Majer wrote:
Patrick Schoenfeld wrote:
In my humble opinion they should be allowed to be packaged as if they
are normal packages. Don't get me wrong, but Debian is a distribution,
so what we basically do is pack up things that are worth
On Sun, Jun 22, 2008 at 09:37:46PM +0200, Goswin von Brederlow wrote:
PS: I would prefer if apt-get could fetch and verify keyring updates
directly from a repository though. Keyring packages are awfull for key
rollovers.
Do you mean from a central repository, somewhat like a keyserver? :-)
How
Hi Neil,
On Sun, Jun 22, 2008 at 09:54:43PM +0100, Neil Williams wrote:
Do you mean from a central repository, somewhat like a keyserver? :-)
How would one check integrity then?
Precisely as you do with any key - signatures and gpg integrity checks
when the key is imported into apt-key.
Hi Goswin,
On Mon, Jun 23, 2008 at 01:07:38AM +0200, Goswin von Brederlow wrote:
For example: Each repository puts its keyring into Release.keyring
(next to Release and Release.gpg). The Release.keyring could be listed
with checksum in Release so frontends know it is there and when it
Hi,
On Mon, Jun 23, 2008 at 11:20:33AM +0200, Goswin von Brederlow wrote:
The beauty of signatures is that you do not have to trust the source
of the key, only the signatures. It truely doesn't matter wher you get
the key from.
yes, you are right (given that you mean signatures on the key
Package: wnpp
Severity: wishlist
Owner: Patrick Schoenfeld [EMAIL PROTECTED]
* Package name: ratproxy
Version : 1.51
Upstream Author : Michal Zalewski [EMAIL PROTECTED]
(Copyright: 2007, 2008 by Google)
* URL : http://code.google.com/p/ratproxy
Hi people,
for several reasons Debian Etch did not include a mantis package, which
was sad for the mantis users out there. This will change with lenny and
if everythings works out well Debian Lenny will ship with mantis 1.1.2.
The mantis developers and I worked hard to make this possible, so
Hi,
On Fri, Apr 15, 2011 at 02:01:06PM +0200, Bjørn Mork wrote:
Josselin Mouette j...@debian.org writes:
Since it was completely redesigned, almost from scratch, this doesn’t
apply for 0.8. Its system daemon is able to manage connections without
anyone logged on, and with a number of
On Thu, Sep 17, 2009 at 05:06:02PM +0200, Vincent Danjean wrote:
I cannot see a good solution here.
Well, the obvious solution is to include it in the Release Notes.
Best Regards,
Patrick
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe.
retitle 471094 O: web-based bug tracking system
noowner 471094
thanks
Hi,
as I do not use mantis anymore and I don't have the time nor interest
to keep up with the mantis development, I'm hereby orphaning mantis.
If you want to be the new maintainer, please take it -- see
On Wed, Oct 14, 2009 at 07:03:07PM +0100, Neil Williams wrote:
On Wed, 14 Oct 2009 17:41:14 +
Florian Weimer f...@deneb.enyo.de wrote:
* Michal Čihař:
Can gnaughty download anything other than porn?
Not really without patching the source.
And the content is non-free,
On Wed, Oct 14, 2009 at 11:52:48AM -0700, Rodrigo Gallardo wrote:
On Wed, Oct 14, 2009 at 08:30:16PM +0200, Patrick Schoenfeld wrote:
On Wed, Oct 14, 2009 at 07:03:07PM +0100, Neil Williams wrote:
On Wed, 14 Oct 2009 17:41:14 +
Florian Weimer f...@deneb.enyo.de wrote:
* Michal
On Sun, Nov 29, 2009 at 06:55:58PM +0100, Andreas Marschke wrote:
As such, we prefer that people who want to apply to NM have been active
in Debian for a while already, and have built up some experience. In the
last few months, we've already redirected some people to the DM process
when we
Hi,
On Wed, Dec 02, 2009 at 04:52:59PM +0100, Adnan Hodzic wrote:
I'm definitely interested in participating! One question tho, since I'm from
Bosnia,
nice. :-)
what other activities (perhaps involving Debian) could I be involved in during
this whole week, since I wouldn't come to Germany
Hi,
when testing my packages with piuparts I noticed an inability of
our package management. Dpkg does not have support for management
of dynamically generated configuration files. Therefore some packages
now use ucf.
The basic usage is somewhat like
- Registering config files to ucf on
On Sat, Dec 05, 2009 at 04:56:02PM +, brian m. carlson wrote:
On Sat, Dec 05, 2009 at 04:47:18PM +0100, Patrick Schoenfeld wrote:
That is okay, as long as ucf is around. But as soon as it isn't
the purge of a package is succesful while leaving modified files around.
So the effect
On Sat, Dec 05, 2009 at 06:37:45PM +0100, Sven Joachim wrote:
It is the package's responsibility to remove those files, ucf --purge
does not do that, see ucf(1).
I never said that. The problem are not the files owned by the package,
but the files owned by ucf, which are modified by ucfr, while
On Sat, Dec 05, 2009 at 07:16:58PM +0100, Daniel Baumann wrote:
Patrick Schoenfeld wrote:
So the call of ucf looks something like that:
if which ucf /dev/null; then
ucf --purge /etc/foo.conf
fi
no, the correct one is:
if which ucf /dev/null
On Sat, Dec 05, 2009 at 05:25:29PM -0600, Manoj Srivastava wrote:
On Sat, Dec 05 2009, Patrick Schoenfeld wrote:
On Sat, Dec 05, 2009 at 06:37:45PM +0100, Sven Joachim wrote:
It is the package's responsibility to remove those files, ucf --purge
does not do that, see ucf(1).
I never
On Sat, Dec 05, 2009 at 11:44:39AM -0600, Manoj Srivastava wrote:
Making a package essential in order to avoid a if clause in
postinsts is very likely too frivolous a reason to pass muster, yes.
I do not want to avoid the if-clause. I want to avoid leaving modified
files around when
On Sat, Dec 05, 2009 at 12:39:28PM -0800, Steve Langasek wrote:
There's no reason that ucf *should* fall under either of these rules; so
even if ucf /didn't/ work the way it does, the right solution here would be
to fix it so that it did, not to add it to Essential.
Makes sense. But how do you
Hello,
On Sat, Dec 05, 2009 at 08:35:38PM -0600, Manoj Srivastava wrote:
I never said that. The problem are not the files owned by the package,
but the files owned by ucf, which are modified by ucfr, while not
restoring the changes if ucf is not around.
Well, if ucf is not
Hi,
On Sat, Dec 05, 2009 at 11:43:28AM -0600, Manoj Srivastava wrote:
This is where things break down. ucf --purge does not do what
you think it does, it by no means removes the configuration files. You
remove the configuration files, not ucf.
It seems that I expressed myself
On Sun, Dec 06, 2009 at 06:12:24AM +0100, Norbert Preining wrote:
Not wanting to start another flame war, but ...
On Sa, 05 Dez 2009, Patrick Schoenfeld wrote:
The crux is the last point. For a good reason postrm must not require
tools it depends on to be around when removing the package
On Sun, Dec 06, 2009 at 05:00:18PM +0100, Tollef Fog Heen wrote:
]] Patrick Schoenfeld
Hi,
| depends on what you expect. I would expect or no lets say I wish that
| purging a package removes all traces that the package where installed
| in the first place, except the cases where
On Sun, Dec 06, 2009 at 09:28:11AM -0600, Manoj Srivastava wrote:
On Sun, Dec 06 2009, Patrick Schoenfeld wrote:
On Sat, Dec 05, 2009 at 11:44:39AM -0600, Manoj Srivastava wrote:
Making a package essential in order to avoid a if clause in
postinsts is very likely too frivolous
On Sun, Dec 06, 2009 at 11:47:11PM -0600, Manoj Srivastava wrote:
In this particular case, what is the harm befalling the user?
Well, I don't think that making an Operating System is just about
keeping harm away from our users.
But it is a tenet of software design that
On Mon, Dec 07, 2009 at 09:08:08AM +0100, Raphael Hertzog wrote:
So one day ucf might be deprecated by dpkg itself.
That day will be a good day. Thanks for the news.
Regards,
Patrick
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
Hi,
(uhm.. I really hate it, if I can't hold the promises to myself I made;
in this case: not further discussing it, but still here is
another answer)
On Mon, Dec 07, 2009 at 10:04:14AM -0600, Manoj Srivastava wrote:
On Mon, Dec 07 2009, Patrick Schoenfeld wrote:
On Sun, Dec 06, 2009 at 11
Hi Manoj,
On Mon, Dec 07, 2009 at 12:12:36PM -0600, Manoj Srivastava wrote:
For me this assumes that data created during this task belongs to
the package that requested the creation of the data in the first
place.
That breaks abstraction and encapsulation.
I'm not sure if
Hi,
On Mon, Dec 28, 2009 at 04:40:50PM +0100, Reinier Haasjes wrote:
I'm trying to solve bug #561324 which uses it's own binary in the config
script.
It uses it's own binary to get some information (tunnel id) which uses
login+password to retrieve, it really needs this to compile a good
Hi,
On Tue, Dec 29, 2009 at 02:38:46PM +0100, Lionel Elie Mamane wrote:
On Mon, Dec 28, 2009 at 07:44:56PM +0100, Reinier Haasjes wrote:
Why? Is it really required to have _all_ questions in the postinst?
No, not all. There are 4 questions asked.
1) brokers list, the list is received
On Tue, Dec 29, 2009 at 05:32:29PM +0100, Josselin Mouette wrote:
Le mardi 29 décembre 2009 à 14:38 +0100, Lionel Elie Mamane a écrit :
Well, this could be solved by a pre-depends on dnsutils |
bind9-host. Pre-depends are often frowned upon, what do others think
of this for this case?
It
On Tue, Dec 29, 2009 at 10:37:45AM -0800, Russ Allbery wrote:
Patrick Schoenfeld schoenf...@debian.org writes:
Uhm, yes, you are right. So it wouldn't help anyway. Only possibility
would be a versioned dependency (according to [1]) or to really do it in
the postinst. Leads to the question
On Tue, Dec 29, 2009 at 11:01:58PM -0800, Russ Allbery wrote:
Patrick Schoenfeld schoenf...@debian.org writes:
On Tue, Dec 29, 2009 at 10:37:45AM -0800, Russ Allbery wrote:
Patrick Schoenfeld schoenf...@debian.org writes:
Uhm, yes, you are right. So it wouldn't help anyway. Only
On Tue, Dec 29, 2009 at 11:50:40PM -0800, Russ Allbery wrote:
Patrick Schoenfeld schoenf...@debian.org writes:
Debconf or another tool that implements the Debian Configuration
Management Specification will also be installed, and any versioned
dependencies on it will be satisfied before
On Wed, Jan 06, 2010 at 10:00:55AM +, Julien Cristau wrote:
On Tue, Jan 5, 2010 at 23:05:30 -0500, Michael Gilbert wrote:
Remember that item 4 of the social contract states that: Our
priorities are our users and free software.
Every time you say that, god kills a kitten. Please,
Hi,
On Tue, Jan 19, 2010 at 03:40:22PM -0800, Russ Allbery wrote:
Why would we want that?
I mean, it's very difficult to guarantee that packages build correctly
in dirty envs. I don't really see the point of enforcing that when we
have the technology (pbuilder, sbuild + lvm snapshots)
On Tue, Jan 19, 2010 at 04:04:07PM -0800, Russ Allbery wrote:
hu? since when do we have a broader interest in people patching and
rebuilding packages? I know that there are *some* people interested in
that (me included) but I don't see that a broader audience wants to
support that.
Uh,
On Wed, Jan 20, 2010 at 05:13:21PM +0100, Goswin von Brederlow wrote:
Unless ucf is removed but not purged, right?
Shouldn't the question rather be:
When will ucf be merged into dpkg?
I find is stupid that ucf handled configuration files will not be
tracked by dpkg and that dpkg and
On Wed, Jan 20, 2010 at 10:30:13AM -0800, Russ Allbery wrote:
That does not mean that we shouldn't fix such bugs if they arise
(obviously we should) but having priority on it is a different thing.
Then I'm not sure that you're disagreeing with me?
Oh I don't. However in one of your first
Hi,
On Fri, Feb 26, 2010 at 02:13:48PM +0100, Mathieu Malaterre wrote:
http://lintian.debian.org/tags/doc-base-unknown-section.html
Where should I fill a bug for that ?
See the bottom of the page:
Please send all comments about these web pages to the Lintian
maintainers.
Regards,
Patrick
On Thu, Mar 04, 2010 at 09:11:21AM +0100, Stefano Zacchiroli wrote:
FWIW, about the people proposing to change from md5 to something else,
it should be pretty easy to achieve too: if all of us is using
dh_md5sums,
Which is not the case. There are still people who like to package
without
Hi,
On Tue, May 11, 2010 at 09:26:25AM +0200, Peter Palfrader wrote:
Therefore if you uploaded something that is not redistributable please
file a bug against the snapshot.debian.org pseudo-package asking for
removal:
fair enough to request that responsibility from the maintainers.
But
On Thu, May 20, 2010 at 12:05:50PM +0200, Yves-Alexis Perez wrote:
On 20/05/2010 11:21, Ron Johnson wrote:
hat does this do that existing tools don't?
$ du -Sk | sort -nr | head -n10
131960./.Newsletters.Washington_Post/cur
not sure dirsum can do that either, but it's painful that
On Fri, Jul 16, 2010 at 07:30:17PM +0200, Christoph Anton Mitterer wrote:
What about /etc?
Well, this one is easy: /etc *can not* be on its own partition.
It has to be on the root filesystem so it will be available.
Regards,
Patrick
--
To UNSUBSCRIBE, email to
Hi,
On Mon, Aug 09, 2010 at 02:06:18PM +0100, Ben Hutchings wrote:
On Mon, 2010-08-09 at 15:00 +0200, Michel wrote:
This information belongs in the release notes. I'm not sure where one
should look to see the draft release notes for the next release.
I guess its already known: #549573
Its
Hi Russel,
On Mon, Nov 21, 2011 at 09:09:58PM +1100, Russell Coker wrote:
On Mon, 21 Nov 2011, Ben Hutchings b...@decadent.org.uk wrote:
I think that would be a pity if Debian will not provide anymore a kernel
for this old cpus.
Maybe you think it's a waste to replace old PCs, but in
Hi,
On Mon, Nov 21, 2011 at 11:30:22PM +1100, Russell Coker wrote:
On Mon, 21 Nov 2011, Patrick Schoenfeld schoenf...@debian.org wrote:
well, its obvious that the absolute power consumption, which is what
you measure, has increased, given that the performance of the systems
has increased
On Tue, Nov 22, 2011 at 12:29:01AM +1100, Russell Coker wrote:
People save power to save money, to save cooling, or to save the environment.
Right, but far from relevant when comparing old systems to new systems
in terms of power saving.
Buying new hardware isn't the way to save money
,
1 - 100 of 184 matches
Mail list logo
