Michelle Konzack schrieb am Thursday, den 17. March 2011:
> Hello Andrei Popescu and Listmasters,
>
> it would be nice, if could implement an autoresponder
> for peoles sending messages to lists without being subscribed.
Eh no. Autoresponder are a plague.
Alex
--
To UNSUBSCRIBE, email to de
On Fri, 18 Mar 2011, Russell Coker wrote:
> On Fri, 18 Mar 2011, Goswin von Brederlow wrote:
> > > On a machine with lots of RAM (== disk cache...) and high I/O load, you
> > > don't want to do a (global!) sync(). This can totally kill the machine
> > > for 20min or more and is a big no go.
> >
Package: wnpp
Severity: wishlist
Owner: Daniel Kahn Gillmor
* Package name: libcrypt-nettle-perl
Version : 0.1
Upstream Author : Daniel Kahn Gillmor
* URL : http://search.cpan.org/dist/Crypt-Nettle/
* License : GPL
Programming Lang: C, Perl
Description
Hello Lisandro Damián Nicanor Pérez Meyer,
Am 2011-03-17 20:27:57, hacktest Du folgendes herunter:
> On Thursday 17 March 2011 20:02:31 Michelle Konzack wrote:
> > But I do not mean Auto-Subscribe.
> Neither me, sorry for not being clear. I meant that people tend to subscribe
> on recibing such m
On Fri, Mar 18, 2011 at 12:11 AM, Russell Coker wrote:
>> Then don't use the option. It should definetly be an option:
>
> It's a pity that there is no kernel support for synching one filesystem (or
> maybe a few filesystems).
That'd be only a partial work around. Even with a single fs one big
sy
On Thursday 17 March 2011 20:02:31 Michelle Konzack wrote:
> Am 2011-03-17 19:15:45, schrieb Lisandro Damián Nicanor Pérez Meyer:
> > Just as a bit of extra information, we have done this (although manually)
> > in a couple of very used lists with nice success (people getting
> > subscribed and som
On Fri, 18 Mar 2011, Goswin von Brederlow wrote:
> > On a machine with lots of RAM (== disk cache...) and high I/O load, you
> > don't want to do a (global!) sync(). This can totally kill the machine
> > for 20min or more and is a big no go.
> >
> > -- vbi
>
> Then don't use the option. It sh
Am 2011-03-17 19:15:45, schrieb Lisandro Damián Nicanor Pérez Meyer:
> Just as a bit of extra information, we have done this (although manually) in
> a
> couple of very used lists with nice success (people getting subscribed and
> sometimes becoming real active).
>
> Of course, not everyone wil
On Thursday 17 March 2011 18:32:43 Michelle Konzack wrote:
> Hello Andrei Popescu and Listmasters,
>
> it would be nice, if could implement an autoresponder
> for peoles sending messages to lists without being subscribed.
>
> This message should only send one time per year and contain usefu
On Tue, Mar 15, 2011 at 10:29:57PM +, Marcin Owsiany wrote:
> How are others doing it?
Thanks for all the responses (I never expected to start such a big
discussion - it must have been a while since I last read debian-devel),
and especially for the pointer to dh-autoreconf. This looks like exa
Hello Andrei Popescu and Listmasters,
it would be nice, if could implement an autoresponder
for peoles sending messages to lists without being subscribed.
This message should only send one time per year and contain usefull
links based on the mailinglist, the FAQ and the CoC.
Thanks, Greeti
Ian Jackson writes:
> The design of autoconf is predicated on the idea that people who are
> building the package are given a portable configure as part of the
> source package, so there is no need to have good compatibility between
> configure.in and various versions of autoconf.
> I don't unde
Ian Jackson writes:
> Goswin von Brederlow writes ("Transitional packages with conffiles"):
>> Looking into the cause we discovered that the problem is that
>> dhcp3-client is now a transitional package that pulls in
>> isc-dhcp-client. The new package expects its config files in /etc/dhcp
>> whi
Hello Carsten Hey,
Am 2011-03-12 10:50:03, hacktest Du folgendes herunter:
> If a message I reply to contains a Mail-Followup-To: set, I use it. If
> not, I guess if the person I reply to wants to receive a reply. To
> prevent me to Cc: you, you need to explicitly set Mail-Followup-To: to
> the
Hello Shachar Shemesh,
Am 2011-03-13 19:54:01, hacktest Du folgendes herunter:
> If I set "reply-to" to myself, the mail won't go to the list. If I
> set it to the list, it won't go to me. Either way, the desired
> effect isn't achieved.
>
> Also, reply-to is the wrong tool for this job (this is
"Bernhard R. Link" writes:
> * Goswin von Brederlow [110316 01:24]:
>> I disagree. If non-free has a superior implementation of a package and
>> the user has non-free configured then it should prefer the non-free
>> package.
>
> Superiority is always a question of what metrics you start with.
>
Joey Hess writes:
> I've been hearing a bit lately about removing dependencies that are no
> longer needed for stable upgrade paths. The most common reason seems
> that this will make apt need less memory[1].
>
> So then, someone must have measured the memory use. Unless this is a
> kind of prema
Processing commands for cont...@bugs.debian.org:
> reassign 618473 nfs-common
Bug #618473 [general] general: Problems to handle NIS group names
Bug reassigned from package 'general' to 'nfs-common'.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
618473: http://bu
Adrian von Bidder writes:
> On Wednesday 02 March 2011 17.02:11 Marius Vollmer wrote:
>> - Instead, we move all packages that are to be unpacked into
>> half-installed / reinstreq before touching the first one, and put a
>> big sync() right before carefully writing /var/lib/dpkg/status.
>
> Y
Marius Vollmer writes:
> ext Chow Loong Jin writes:
>
>> Could we somehow avoid using sync()? sync() syncs all mounted filesystems,
>> which
>> isn't exactly very friendly when you have a few slow-syncing filesystems like
>> btrfs (or even NFS) mounted.
>
> Hmm, right. We could keep a list of
reassign nfs-common
thanks
On Tue, 2011-03-15 at 15:10 +0100, Christian Andretzky wrote:
> I've really no idea, which package(s) are responsible for this problem.
Reassigning to nfs-common because that seems to be the most likely
candidate (assuming autofs is used to mount nfs filesystems).
> In
Tollef Fog Heen writes ("Re: Best practice for cleaning autotools-generated
files?"):
> | Adam Borowski writes ("Re: Best practice for cleaning autotools-generated
> files?"):
> | No, it doesn't work if the auto* on the system is not compatible with
> | the auto* in the package, which happens ver
* Peter Samuelson [110317 19:12]:
> If there _is_ some risk or perception of risk, that re-auto-tooling a
> package might break it, then we're not really providing the FSF's
> freedom 1. We're then saying "This is free software; downstream users
> can modify the .c files, you can modify the .h fi
Peter Samuelson writes ("Re: Best practice for cleaning autotools-generated
files?"):
> Better to take on this risk, such as it is, by building from source
> every time. It's the only way to know we _can_. And fix whatever
> issues come up. Even though it's not actually spelled out in the DFSG,
[Bernhard R. Link]
> It usually also make sense to think twice before patching build
> systems. Especially automake is very good in allowing many things
> changed without having to patch something. (There are some cases
> where patches are necessary, but there are also enough cases where
> patchi
]] Ian Jackson
Hi,
| Adam Borowski writes ("Re: Best practice for cleaning autotools-generated
files?"):
| > Ie, consistently with all regular commands in a makefile: if a source file
| > has been modified, everything that is generated from that source needs to be
| > rebuilt.
| >
| > Which wo
Adam Borowski writes ("Re: Best practice for cleaning autotools-generated
files?"):
> Ie, consistently with all regular commands in a makefile: if a source file
> has been modified, everything that is generated from that source needs to be
> rebuilt.
>
> Which works just fine if timestamps haven'
On Thu, Mar 17, 2011 at 11:01:44AM -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 17 Mar 2011, Andreas Tille wrote:
> > Assume please the following:
> >
> > 1. Unpack upstream source, copy debian/ dir into it
> > 2. make -f debian/rules clean
>
> You should have looked for a get-orig-sou
Package: wnpp
Severity: wishlist
Owner: Pierre Chifflier
* Package name: sagan-rules
Version : 10212010-r1
Upstream Author : Champ Clark III
* URL : http://sagan.softwink.com/
* License : BSD
Programming Lang: other (text files)
Description : Real-time
On Thu, 17 Mar 2011, Sean Finney wrote:
> autofoo stuff examines timestamps on various files, so it's possible
> that if configure gets patched before configure.ac, and
> AM_MAINTAINER_MODE is set to a specific value, that ./configure ends up
> wanting to regenerate ./configure at build time. doub
On Thu, 17 Mar 2011, Andreas Tille wrote:
> Assume please the following:
>
> 1. Unpack upstream source, copy debian/ dir into it
> 2. make -f debian/rules clean
You should have looked for a get-orig-sources target, first. You just
skipped any orig source conditioning the maintainer had to do
On Thu, 17 Mar 2011, Andreas Tille wrote:
> On Thu, Mar 17, 2011 at 04:09:25PM +0800, Paul Wise wrote:
> > Agreed. That would usually not be something that would cause enough
> > problems for a new tar.gz to be warranted though.
>
> I just accept your opinion that repackaging is not warranted and
On Thu, 17 Mar 2011, Paul Wise wrote:
> Does your autogen.sh script ever become anything more than calling
> autoreconf with some specific options?
Yes. I think it was Cyrus IMAP that required -I in places where
autoreconf doesn't reach, so I called each tool separately. Which is
obviously a pro
Sean Finney writes ("Re: Best practice for cleaning autotools-generated
files?"):
> On Wed, 2011-03-16 at 16:36 +, Ian Jackson wrote:
> > That's fine, you patch the input, rerun the autofoobar stuff, and then
> > build the source package with diff. If you're using a patch queue
> > system, or
On Thu, Mar 17, 2011 at 10:30:48AM +0100, Julien Cristau wrote:
> > The problem is that the regenerated files are not identical to the
> > original files and you simply get a diff which finally makes different
> > Debian source packages depending how often you start the build process.
> >
> Err, n
On Thu, Mar 17, 2011 at 09:17:05AM +0100, Michael Biebl wrote:
> Am 17.03.2011 08:51, schrieb Sean Finney:
> >>> So Makefile rules can then re-run auto* tools at build time and you
> >>> lost the benefit you want to have.
> >>
> >> Makefile rules should not rerun auto* stuff at build time.
> >
> >
On Thu, Mar 17, 2011 at 10:12:35 +0100, Andreas Tille wrote:
> On Thu, Mar 17, 2011 at 04:40:29PM +0800, Paul Wise wrote:
> > Eh? Rebuilding twice in a row would remove the files, regenerate them,
> > remove them, regenerate them. I can't see how the second regeneration
> > would fail if the first
On Thu, Mar 17, 2011 at 5:12 PM, Andreas Tille wrote:
> The problem is that the regenerated files are not identical to the
> original files and you simply get a diff which finally makes different
> Debian source packages depending how often you start the build process.
You won't get a diff if yo
On Thu, Mar 17, 2011 at 09:17:27AM +, Lars Wirzenius wrote:
> > > My rule is: when there is something non-free or when the amount of
> > > useless stuff is huge. For example I would repack a tarball with a
> > > small program and 20Mb of embedded code copies of all its dependencies
> > > to rem
On to, 2011-03-17 at 10:12 +0100, Andreas Tille wrote:
> On Thu, Mar 17, 2011 at 04:40:29PM +0800, Paul Wise wrote:
> > My rule is: when there is something non-free or when the amount of
> > useless stuff is huge. For example I would repack a tarball with a
> > small program and 20Mb of embedded co
On Thu, Mar 17, 2011 at 04:40:29PM +0800, Paul Wise wrote:
> My rule is: when there is something non-free or when the amount of
> useless stuff is huge. For example I would repack a tarball with a
> small program and 20Mb of embedded code copies of all its dependencies
> to remove the deps.
What a
On Tue, March 15, 2011 21:40, Joerg Jaspert wrote:
>
>>> The new implementation is currently only used for suites that are not
>>> marked as untouchable. Oldstable and stable will switch during the next
>>> point release.
>> Have you (or anyone else) verified that any tools in {old,}stable
>> parsi
On Thu, Mar 17, 2011 at 4:34 PM, Andreas Tille wrote:
> I just accept your opinion that repackaging is not warranted and I did
> not in the past - but I was never really sure whether this is really
> reasonable. I'm somehow missing *clear* rules when to rebuild the orig
> tarball and when not.
On to, 2011-03-17 at 08:32 +, Roger Leigh wrote:
> You can get the same effect with "file" chroots (tarball unpack). It's
> not that slow providing your tarball is really minimal, and it works
> on all architectures. I used this for the whole archive rebuild after
> LVM snapshots oopsed and t
On Thu, Mar 17, 2011 at 04:09:25PM +0800, Paul Wise wrote:
>
> Agreed. That would usually not be something that would cause enough
> problems for a new tar.gz to be warranted though.
I just accept your opinion that repackaging is not warranted and I did
not in the past - but I was never really su
On Thu, Mar 17, 2011 at 08:31:13AM +0100, Cyril Brulebois wrote:
> Hi,
>
> just as a reminder:
>
> Roger Leigh (16/03/2011):
> > OK. I think this is the only known discrepancy between the two
> > resolvers. Given that we now routinely build using minimal clean
> > (cloned) chroots, they will b
Am 17.03.2011 08:51, schrieb Sean Finney:
>
>>> So Makefile rules can then re-run auto* tools at build time and you
>>> lost the benefit you want to have.
>>
>> Makefile rules should not rerun auto* stuff at build time.
>
> they will if AM_MAINTAINER_MODE is being used, in some cases.
It's real
On Thu, Mar 17, 2011 at 4:02 PM, Andreas Tille wrote:
> Sorry, I was not precise. I also regard Makefile.in and configure (and
> files which are used by configure to run properly) as useful in an
> upstream tarball. However, files like config.log etc. should be cleaned
> up.
Agreed. That would
On Thu, Mar 17, 2011 at 03:32:05PM +0800, Paul Wise wrote:
> On Thu, Mar 17, 2011 at 3:15 PM, Andreas Tille wrote:
>
> > Would you consider the existence of autotools autogenerated files inside
> > an upstream source a valid reason to rebuild upstream source in a
> > get-orig-source target?
>
>
On Thu, 17 Mar 2011, Sean Finney wrote:
> > > If you do it with the patch system (quilt or even plain dpkg),
> > > before building the package source, you cannot ensure that files are
> > > patched in the right order.
> >
> > What do you mean "in the right order" ?
>
> autofoo stuff examines time
On Wed, 2011-03-16 at 16:36 +, Ian Jackson wrote:
> > Then, you need a way to patch them. There is lots of software where
> > you need to patch configure.ac and/or Makefile.am
>
> That's fine, you patch the input, rerun the autofoobar stuff, and then
> build the source package with diff. If y
On Thu, Mar 17, 2011 at 3:15 PM, Andreas Tille wrote:
> Would you consider the existence of autotools autogenerated files inside
> an upstream source a valid reason to rebuild upstream source in a
> get-orig-source target?
I would consider autotools generated files (Makefile.in, configure,
etc)
Hi,
just as a reminder:
Roger Leigh (16/03/2011):
> OK. I think this is the only known discrepancy between the two
> resolvers. Given that we now routinely build using minimal clean
> (cloned) chroots, they will behave identically in practice because
AFAICT: only possible on Linux f
On Thu, Mar 17, 2011 at 11:21:52AM +0800, Paul Wise wrote:
> > 5. Cheerfully ignore any purists complaining that debian/rules clean does
> > not restore whatever crap was there upstream.
>
> I generally don't bother with these unless I'm patching the autotools
> source files (configure.ac/Makefi
54 matches
Mail list logo
