Hello, everybody
I have a little question about ucf (example with a package which
contains a file package_file.conf)
Can i use de package_file.conf.dpkg-old generate by the ucf utility?
I would like to know how can i restore the old conf files after use ucf.?
I have created a package which man
On Tue, 20 May 2008 00:34:48 +0200, Franck JONCOURT wrote:
> > The package psad contains a file /usr/lib/perl5/IPTables/Parse.pm.
> As a matter of fact, all packages from cipherdyne are being packaged
> to avoid conflicts between psad, fwsnort and fwknop.
Sounds good, thanks for the clarification
Le Mon, May 19, 2008 at 10:25:35PM +0200, Bernd Eckenfels a écrit :
> In article <[EMAIL PROTECTED]> you wrote:
> > give a hint about this. If patches are "hidden" anywhere in the upstream
> > code some developers fail to realise this and my suggestion might help
> > noticing this fact.
>
> The d
Gunnar Wolf <[EMAIL PROTECTED]> writes:
> Lucas Nussbaum dijo [Sat, May 17, 2008 at 02:37:31PM +0200]:
>> If I understand things correctly (but I'm really not sure I do), 3.0
>> (quilt) won't really help with that: it won't prevent maintainers to
>> directly modify files outside of debian/ , and g
Pierre Habouzit <[EMAIL PROTECTED]> writes:
> On Mon, May 19, 2008 at 04:06:36PM +, Manoj Srivastava wrote:
>> B) (This is an honest question). How many things can rerere remember? If
>>I use rerere to record how to resolve current conflicts in feature
>>branches, does the historical i
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow
> <[EMAIL PROTECTED]> said:
>
> Hmm. You say things like this:
>> Because the git format is imho conceptualy broken and the
>> implementation is far from completely thought out.
>
>
On Tue, 20 May 2008, Pierre Habouzit wrote:
git-rerere keeps recorded conflicts resolution for 60 days by default,
and it's configureable, and it needs to use git-gc (or git rerere gc) to
cleanse it, so if you don't, it just won't disappear.
I admit I realy don't care what your favourite VCS
Michael Banck <[EMAIL PROTECTED]> writes:
> On Mon, May 19, 2008 at 08:59:51AM +0200, Goswin von Brederlow wrote:
>> 2) feature branches
>>
>> Each feature branche is based on upstream (with few exceptions) and
>> contains all changes for one feature.
>>
>> Then you have an integration branche w
Hi,
> The package psad contains a file /usr/lib/perl5/IPTables/Parse.pm.
>
> (http://www.cipherdyne.org/modules/ also mentions ".. provides ..
> modules used by the psad, ...")
>
> This potential clash should be sorted out before an upload.
As a matter of fact, all packages from cipherdyne are be
Mike Hommey <[EMAIL PROTECTED]> writes:
> On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote:
> > On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow
> > <[EMAIL PROTECTED]> said:
> > > It is trivial to generate a quilt format package from
> > > git/arch/hg/svn and I'm sure th
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
--- Please fill out the fields below. ---
Package name: Jubler
Version: 3.9.0
Upstream Author: [Panayotis Katsaloulis <[EMAIL PROTECTED]>]
URL: [http://www.jubler.org]
License: [GPL]
De
On Mon, May 19, 2008 at 04:06:36PM +, Manoj Srivastava wrote:
> B) (This is an honest question). How many things can rerere remember? If
>I use rerere to record how to resolve current conflicts in feature
>branches, does the historical information get lost? (like, I use
>rerere to h
On Mon, May 19, 2008 at 09:40:09PM +, Stefano Zacchiroli wrote:
> On Sun, May 18, 2008 at 01:24:13AM +0200, Pierre Habouzit wrote:
> > > You're describing a situation where upstream is difficult or impossible
> > > to communicate with. I can't solve that, nor can anyone except upstream.
> >
>
On Mon, 19 May 2008 22:38:16 +0200, Franck Joncourt wrote:
> * Package name: libiptables-parse-perl
> The "IPTables::Parse" package provides an interface to parse iptables
> rules on Linux systems through the direct execution of iptables
> commands, or from a file.
The package psad contains
On Mon, 19 May 2008, Bernd Eckenfels wrote:
The debian Diff is not hiding patches in the upstream code. It is the
canonical place to publish them (at least for some (most?) of the debian
packages following policy).
Well, I'm DD for 10 years - I know this fact. But did you read about
habits of
Lucas Nussbaum dijo [Sat, May 17, 2008 at 02:37:31PM +0200]:
> If I understand things correctly (but I'm really not sure I do), 3.0
> (quilt) won't really help with that: it won't prevent maintainers to
> directly modify files outside of debian/ , and generate a huge
> debian/patches/debian-changes
On Sat, May 17, 2008 at 03:55:12PM -0700, Don Armstrong wrote:
> One of the wishlist features for the BTS that I've been contemplating
> setting up is a "summary" feature, whre the current summary of a bug
> is shown at the top, with the history continuing below.
>
> This could be easily extended
On Sun, May 18, 2008 at 01:17:09AM +0200, Josselin Mouette wrote:
> That would be very nice. I think you could easily make giant
> improvements by reworking the bug listing pages. They would be much more
> useful with a table listing all bugs with one bug per line, color
> indicators for the severi
On Sun, May 18, 2008 at 01:24:13AM +0200, Pierre Habouzit wrote:
> > You're describing a situation where upstream is difficult or impossible
> > to communicate with. I can't solve that, nor can anyone except upstream.
>
> Except that once again, upstream that would benefit from our system
> the
Package: wnpp
Severity: wishlist
Owner: Franck Joncourt <[EMAIL PROTECTED]>
* Package name: libiptables-parse-perl
Version : 0.5
Upstream Author : Michael Rash <[EMAIL PROTECTED]>
* URL : http://www.cipherdyne.org/modules/
* License : GPL, Artistic
Programmi
On Mon, May 19, 2008 at 08:59:51AM +0200, Goswin von Brederlow wrote:
> 2) feature branches
>
> Each feature branche is based on upstream (with few exceptions) and
> contains all changes for one feature.
>
> Then you have an integration branche where all feature branches are
> merged. The merging
In article <[EMAIL PROTECTED]> you wrote:
> give a hint about this. If patches are "hidden" anywhere in the upstream
> code some developers fail to realise this and my suggestion might help
> noticing this fact.
The debian Diff is not hiding patches in the upstream code. It is the
canonical place
Luk Claes wrote:
> Hi Thiemo
>
> Thanks for this status report.
>
> Thiemo Seufer wrote:
> > I went again through the mips build problems and collected the appended
> > list which records the current state, with a few annotations added.
>
> > Needs retry
> > ---
>
> All given back when
On Mon, 19 May 2008, Manoj Srivastava wrote:
In that case, I fail to see why you are only interested in this
information if the maintainer did not use quilt. Seems like you should
be concerned about changes made to upstream, period, regardless of
whether the changes are recorded in quilt
Hi Thiemo
Thanks for this status report.
Thiemo Seufer wrote:
> I went again through the mips build problems and collected the appended
> list which records the current state, with a few annotations added.
> Needs retry
> ---
All given back when still needed. Please don't include packag
Package: wnpp
Severity: wishlist
Owner: Deepak Tripathi <[EMAIL PROTECTED]>
* Package name: libmath-algebra-symbols-perl
Version : 1.21
Upstream Author : Philip R Brenan <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/Math-Algebra-Symbols/
* License
On Mon, 19 May 2008 17:29:13 +0200, Mike Hommey <[EMAIL PROTECTED]> said:
> On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote:
>> On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow
>> <[EMAIL PROTECTED]> said:
>>
>> Hmm. You say things like this:
>> > Because the git format
On Mon, May 19, 2008 at 03:29:13PM +, Mike Hommey wrote:
> On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote:
> > On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow
> > <[EMAIL PROTECTED]> said:
> >
> > Hmm. You say things like this:
> > > Because the git format
On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote:
> On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow
> <[EMAIL PROTECTED]> said:
>
> Hmm. You say things like this:
> > Because the git format is imho conceptualy broken and the
> > implementation is far from complet
On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow
<[EMAIL PROTECTED]> said:
Hmm. You say things like this:
> Because the git format is imho conceptualy broken and the
> implementation is far from completely thought out.
And then you go saying things like that:
> It is tr
On Mon, 19 May 2008 09:20:11 +0200 (CEST), Andreas Tille <[EMAIL PROTECTED]>
said:
>> If you care about the changes, just use the command. You can even
>> have an alias if you prefer that.
>>
>> BTW:
>> +++ openssl-0.9.8g/Makefile
>> +++ openssl-0.9.8g/Configure
>> +++ ... (50 lines deleted)
>>
bonjour,
j'ai créer un paquet debian pour installer une configuration générale
d'authentification sur ldap.
pour cela j'ai utilisé "ucf" sur les fichiers /etc/pam_ldap.conf,
nsswitch.conf, ldap.conf et conf pam.
je voudrais savoir comment je peux récupérer la configuration avant
installation
On Mon, 19 May 2008, Russ Allbery wrote:
> Mark Brown <[EMAIL PROTECTED]> writes:
> > On Sun, May 18, 2008 at 07:14:10AM -0700, Russ Allbery wrote:
>
> >> The solution to this problem is to fix the mailing list code of conduct
> >> to stop creating this expectation. We don't enforce it anyway, an
Russ Allbery <[EMAIL PROTECTED]> writes:
> Codes of conduct usually have consequences for violating them, which
> this clearly doesn't (other than sparking 40-post threads every
> couple of months and annoyed paragraphs at the top of replies that
> people generally ignore anyway).
Again, my exper
Mark Brown <[EMAIL PROTECTED]> writes:
> On Sun, May 18, 2008 at 07:14:10AM -0700, Russ Allbery wrote:
>> The solution to this problem is to fix the mailing list code of conduct
>> to stop creating this expectation. We don't enforce it anyway, and all
>> this provision seems to do in practice is
On Fri, May 16, 2008 at 11:46:13PM +0200, Moritz Muehlenhoff <[EMAIL
PROTECTED]> was heard to say:
> Daniel Burrows wrote:
> > I notice that pwsafe is linked against openssl. Is it affected by the
> > recent debacle and if so, how? Do I need to regenerate all my
> > randomized passwords, or so
On Sunday 18 May 2008, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > The diff.gz contains all the changes including the debian dir. It is
> > by no means obvious if there are patches in there or not.
>
> I think reading a debian diff is the every day job of DD and DAs. And
"Miriam Ruiz" <[EMAIL PROTECTED]> writes:
> 2008/5/19 Goswin von Brederlow <[EMAIL PROTECTED]>:
>
>> Because the git format is imho conceptualy broken and the
>> implementation is far from completely thought out. The strongest
>> point against it is that the user has to learn git to use it.
>
> I'
On Mon, 19 May 2008, Lucas Nussbaum wrote:
> On 19/05/08 at 09:09 +0200, Raphael Hertzog wrote:
> > Fix-Debian-Bug: 5
>
> I think that:
> Fixes: http://bugs.debian.org/5
> is better. The patch might fix a problem not reported in Debian. For
> example, the Debian maintainer might monitor
On Mon, May 19, 2008 at 01:23:25PM +1000, Hamish Moffatt wrote:
> On Sun, May 18, 2008 at 07:21:29PM +0100, Mark Brown wrote:
> > Of course, MFT brings up the whole "it's not a standard, why should I
> > follow it, my MUA never heard of it" thing... You can't win.
> Our code of conduct has the s
On Mon, May 19, 2008 at 10:55:00AM +0200, Miriam Ruiz wrote:
> 2008/5/19 Goswin von Brederlow <[EMAIL PROTECTED]>:
>
> > Because the git format is imho conceptualy broken and the
> > implementation is far from completely thought out. The strongest
> > point against it is that the user has to learn
On Monday 19 May 2008 18:10, Bernhard R. Link wrote:
>
> People already CCed are a different beast. But CCing the creator of
> a mail by default is not reasonable.
>
Unfortunately that doesn't work with Kmail's reply-to-list, which means
manual attention is needed when the thread is being intentio
2008/5/19 Goswin von Brederlow <[EMAIL PROTECTED]>:
> Because the git format is imho conceptualy broken and the
> implementation is far from completely thought out. The strongest
> point against it is that the user has to learn git to use it.
I'm curious about this. Why is it conceptualy broken a
Raphael Hertzog <[EMAIL PROTECTED]> writes:
> On Mon, 19 May 2008, Goswin von Brederlow wrote:
>> Josselin Mouette <[EMAIL PROTECTED]> writes:
>>
>> > Le dimanche 18 mai 2008 à 12:00 +0200, Raphael Hertzog a écrit :
>> >> As a Debian package maintainer however I'm convinced that we'd be better
>>
* Martin Langhoff <[EMAIL PROTECTED]> [080518 22:02]:
> In this modern age of a mailman that lets subscribers configure their
> subscription to avoid duplicates, and procmail filters that help do
> the same at the client end (and some mail clients that have similar
> abilities of their own - ie gma
Le Mon, May 19, 2008 at 07:12:43AM +0200, Lucas Nussbaum a écrit :
> Take a bug #111, severity:serious, affecting unstable,testing,stable.
> The maintainer fixes the bug in unstable using a Debian patch. Following
> your process, the bug is now downgraded to wishlist. Meaning that RC
> #111 bug in
On 19/05/08 at 09:09 +0200, Raphael Hertzog wrote:
> Fix-Debian-Bug: 5
I think that:
Fixes: http://bugs.debian.org/5
is better. The patch might fix a problem not reported in Debian. For
example, the Debian maintainer might monitor Ubuntu's bug tracker, see a
bug reported there, and fix i
On 19/05/08 at 08:48 +0200, Goswin von Brederlow wrote:
> Lucas Nussbaum <[EMAIL PROTECTED]> writes:
> > and update the corresponding bug report, and it doesn't work with
> > version-tracking, which would need to be updated have 3 notions:
> > - notfound (already exist)
>
> ???
>
> > - fixed usin
On Mon, 19 May 2008, Lucas Nussbaum wrote:
> Two additional changes could be made as well, to help with the process:
> 1) add parsing for Closes-with-patch: in changelog. This closes the
>bug normally, and also tags the bug + divergence. sounds
>non-disruptive.
This should actually probabl
On Mon, 19 May 2008, Bernd Eckenfels wrote:
I dont see a reason why the normal unpack action should spam the user.
If a user feels spammed there might be means to switch this off. A command
line option that reduces the verbosity comes to mind even /dev/null might be
a place to foreward this s
On Mon, 19 May 2008, Goswin von Brederlow wrote:
> Josselin Mouette <[EMAIL PROTECTED]> writes:
>
> > Le dimanche 18 mai 2008 à 12:00 +0200, Raphael Hertzog a écrit :
> >> As a Debian package maintainer however I'm convinced that we'd be better
> >> served by having only native + 3.0 quilt. The VC
On 19/05/08 at 09:14 +0900, Charles Plessy wrote:
> 'morning Neil and everybody. So many mails to read for breakfast!
>
> Le Sun, May 18, 2008 at 03:51:18PM +0100, Neil Williams a écrit :
> > proposal:
> >
> > [EMAIL PROTECTED] | (Fixes: #nnn)
> > marks the bug as fixed by a patch added by De
On Sun, 18 May 2008, Patrick Winnertz wrote:
If there is anybody who is interested in this feature please mail me, since
upstream is pretty dead there is no great chance that he will fix this in
a reasonable time. So if someone have good C skills and would like to help
to port mc to link dynamic
On Mon, 19 May 2008, Charles Plessy wrote:
> Even simpler: Fixes: #nnn downgrades the severity to wishlist, adds "To
> be merged upstream:" to the subject, and sends a message saying "This
> bug has been fixed by patching the original sources; we will forward
> this patch to the upstream authors an
Josselin Mouette <[EMAIL PROTECTED]> writes:
> Le dimanche 18 mai 2008 à 12:00 +0200, Raphael Hertzog a écrit :
>> As a Debian package maintainer however I'm convinced that we'd be better
>> served by having only native + 3.0 quilt. The VCS comes _before_ the
>> source package and the source packa
"Bernhard R. Link" <[EMAIL PROTECTED]> writes:
> * Goswin von Brederlow <[EMAIL PROTECTED]> [080518 16:09]:
>> The quilt extension is certainly a big improvement and will hopefully
>> unify a lot of patch system using packages after lenny.
>
> Though I guess there still needs to be a way to get su
56 matches
Mail list logo
