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 re
Hi Pierre,
On Tue, Feb 05, 2008 at 09:17:12PM +0100, Pierre Habouzit wrote:
> Again, the discussion isn't (for me) about a tool, but an exchange
> format. We are discussing having patches served in a quilt series, and
okay, this approach is similar but different. So you want a quilt
series, but
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 kno
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 with
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, tha
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 softwar
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 man
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
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? :-)
H
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-
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
> chan
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 f
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.co
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 uploa
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". Tro
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
http://www.debian.org/d
On Wed, Oct 14, 2009 at 07:03:07PM +0100, Neil Williams wrote:
> On Wed, 14 Oct 2009 17:41:14 +
> Florian Weimer wrote:
>
> > * Michal Čihař:
> >
> > >> Can gnaughty download anything other than porn?
> > >
> > > Not really without patching the source.
> >
> > And the content is non-free, r
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 wro
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
> >
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 Germa
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 installat
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 aroun
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, whi
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
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&qu
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 r
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 y
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
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 uncl
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 aro
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, e
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
> >>
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 des
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? C
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
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 s
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 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 there
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 [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 things.
>
> I don't
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
>
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 t
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,
Patr
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 th
Package: wnpp
Severity: wishlist
Owner: Patrick Schoenfeld <[EMAIL PROTECTED]>
* Package name: innotop
Version : 1.4.3
Upstream Author : Baron Schwartz
* URL : http://innotop.sourceforge.net
* License : GPL
Programming Lang: Perl
Description : A
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 abso
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
Program
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 m
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 tha
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 univers
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 L
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 c
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
th
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 some
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 r
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?
On Tue, Dec 29, 2009 at 10:37:45AM -0800, Russ Allbery wrote:
> Patrick Schoenfeld 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
On Tue, Dec 29, 2009 at 11:01:58PM -0800, Russ Allbery wrote:
> Patrick Schoenfeld writes:
> > On Tue, Dec 29, 2009 at 10:37:45AM -0800, Russ Allbery wrote:
> >> Patrick Schoenfeld 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 writes:
>
> > Debconf or another tool that implements the Debian Configuration
> > Management Specification will also be installed, and any versioned
> > dependencies on it
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. P
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 snap
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.
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 dpk
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 fi
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,
Patri
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 hel
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 woul
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 pa
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 debian-devel-requ...@lists.debi
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
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 upstrea
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 e
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 direct
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
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
>
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.
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 b
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-co
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
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/defa
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
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
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 Russel,
On Mon, Nov 21, 2011 at 09:09:58PM +1100, Russell Coker wrote:
> On Mon, 21 Nov 2011, Ben Hutchings 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 many case
Hi,
On Mon, Nov 21, 2011 at 11:30:22PM +1100, Russell Coker wrote:
> On Mon, 21 Nov 2011, Patrick Schoenfeld wrote:
> > well, its obvious that the absolute power consumption, which is what
> > you measure, has increased, given that the performance of the systems
> >
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 101 matches
Mail list logo
