Re: package config

[Manoj Srivastava]

On Tue, 20 May 2008 08:34:10 +0200, Anthony  <[EMAIL PROTECTED]> said: 

> 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?

Use it for what?

> I would like to know how can i restore the old conf files after use
> ucf.?

If this is in a maintainer script, just don't run ucf. If this
 is as an end user, you should have been asked a question had you
 modified the file -- and yes, you can recover the older version of the
 file.

> I have created a package which manage some files with ucf BUT when i
> remove the package i would like to restore the files before the
> installation .  I could rename the file package_file.conf.dpkg-old in
> package_file.conf in postrm script (remove)

The dpkg.old file might not exist at that point ( the user might
 have gotten rid of it, for one thing). If you want to reliably do that,
 copy the file somewhere safe, and restore from your cached location
 later.  Depending on the old file being around is risky.

manoj
-- 
You have a tendency to feel you are superior to most computers.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: what about an special QA package priority?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> even though it's "just" a command line utility.  Who knows what
> weird, unexpected side effects there might be from running such an
> app within a tight bash loop.

none*. And not cleaning up yourself also improves performance for short
running apps.

Gruss
Bernd

* unless we talk persistent resources like files or ipc.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Ben Finney]

Stefano Zacchiroli <[EMAIL PROTECTED]> writes:

> The remaining ones will indeed need manual intervention, but aren't
> this kind of changes those which are supposed to be pushed upstream?
> So some more burden on the developer on these rare (if you buy my
> statement above) cases can even be beneficial from a social point of
> view.

In many of the cases discussed in this thread, the Debian package
maintainer is already bearing much of the burden of the divergence and
upstream (whatever their attitude to the developer) is not going to
incorporate the patch any time soon.

Why, in these cases, do you see extra burden on the Debian package
maintainer to be a good thing?

-- 
 \  "I hope some animal never bores a hole in my head and lays its |
  `\   eggs in my brain, because later you might think you're having a |
_o__)  good idea but it's just eggs hatching."  -- Jack Handey |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Manoj Srivastava]

On Tue, 20 May 2008 00:44:44 +0200, Stefano Zacchiroli <[EMAIL PROTECTED]> 
said: 

> On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote:
>> And then you go saying things like that:
>> > It is trivial to generate a quilt format package from
>> > git/arch/hg/svn and I'm sure there will be a RCS-build-package soon
>> > enough that does that.
>> This can not happen without manual intervention, if the topic
>> branches have overlap. And Redoing the manual conflict resolution
>> over

> I stopped buying this argument (generally, not specifically from you)
> on the basis that in most of the cases packages have several non
> overlapping patches wrt upstream.  So the "trivial" part above is
> indeed true for a lot of packages.

If you want to only cater to package who currently do not have
 overlapping branches, sure. I am not sure I'll feel motivated enough to
 go along with a partial solution, but perhaps you do not need everyone
 buy-in.

> The remaining ones will indeed need manual intervention, but aren't
> this kind of changes those which are supposed to be pushed upstream?
> So some more burden on the developer on these rare (if you buy my
> statement above) cases can even be beneficial from a social point of
> view.

While in theory evey divergence is something to be pushed
 upstream, and anything ihn ./debian/patches should disappear, in
 practice, for multitudinous reasons, we still have divergence.  Any
 policy that relies on this not being the case is, umm, being somewhat
 unrealistic. 

manoj
-- 
"In every country and every age, the priest has been hostile to
Liberty." Thomas Jefferson
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: what about an special QA package priority?

[John Hasler]

Ron Johnson writes:
> Still, though, it's Bad Practice not to clean up after yourself, even
> though it's "just" a command line utility.  Who knows what weird,
> unexpected side effects there might be from running such an app within a
> tight bash loop.

None.  If the process exits it exits.  It doesn't matter how quickly it is
started again.
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Manoj Srivastava]

On Tue, 20 May 2008 08:00:48 +0200, Goswin von Brederlow <[EMAIL PROTECTED]> 
said: 

> 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.
>> 
>> And then you go saying things like that:
>>> It is trivial to generate a quilt format package from
>>> git/arch/hg/svn and I'm sure there will be a RCS-build-package soon
>>> enough that does that.
>> 
>> This can not happen without manual intervention, if the topic
>> branches have overlap. And Redoing the manual conflict resolution
>> over and over and over again is a burden (the manual conflict
>> resolution lives generally in the integration branch history, and can
>> be done once, and mostly ignored from that point on).

> A quilt format package with a single combined patch. Get the
> integration branch, get orig.tar.gz, build. dpkg-buildpackage will
> automatically create a debian_version.patch for you. It is easy.

How is this better than the current diff.gz thing?

> I'm not saying you get a nice and shiny debian/patches/* out of
> it. That indeed needs human interaction as already said elsewhere.

> To the non git (even not quilt) experienced user the combined patch
> will be usable in that he can edit the source and fix bugs. The git
> format does not allow that.

Unpack a 3.0 (git) source package. Hack.
 "git commit -a -m"Why I hacked this."
 dpkg-buildpackage

Seems like does not allow is a bit strong.

As more and more people swithc to git, git awareness will
 spread, making more people who can actually deal with creating a git
 branch to make changes on.  Seems like a long term win.

> Even with some git knowledge I think that most users that write a
> patch won't follow the maintainers workflow. They won't find the right
> feature branch a patch belongs to and how to merge that into an
> integration branch. Instead they will just edit the source, git commit
> and send the resulting patch. And that means you get a patch against
> the integration branch. Same as you would with the quilt format.

The users are not really following the maintainers workflow even
 in the git case (If I have to modify patch 7 of 9, I need some
 quilt-fu).

manoj

-- 
Do unto others before they undo you.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debian-installer: driver disk compatibility

[Roberto C . Sánchez]

On Tue, May 20, 2008 at 07:39:24PM -0700, Ken Teague wrote:
> 
> For example, lets
> say I have a new motherboard with a chipset that isn't supported by the
> current Linux kernel on the Debian installation media.  I go to said
> manufacturers web site and they have downloads for Red Hat and SuSE.  I
> download either of the two, pop in the floppy disk, and
> Debian is able to determine whether it's designed for distribution X and
> loads the module.  That, in itself, would be the next best thing since
> the "alien" package. :-)
> 
The main problem with that is that it would require one of the
following:

 1. the module be compiled against an ABI-compatible kernel

 OR

 2. the source be included on the disk, the headers to the kernel be
 available on the install medium, along with a compiler, and then
 compile the module right there on the spot

The first one is highly unlikely to happen.  The second would be a pain
to implement and would probably require an extra CD and possible
redistributing how packages are distributed on the CDs.  To say nothing
of the massive memory requirement (in comparison with the paltry 16 MB
or 24 MB requirement of the regular installer) that would be imposed to
be able to do that.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: what about an special QA package priority?

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/20/08 18:42, Nicolas François wrote:
> Hi,
> 
> On Tue, May 20, 2008 at 05:21:07PM -0300, Luciano Bello wrote:
[snip]
> 
>> For example:
>>  - It should be checked with debugging tools (like valgrind :P)
> 
> It's not always needed.
> It may show some bad practices, but having a command line utility which
> allocate some resources (memory, syslog, files, PAM, ...) and does not
> free them directly (i.e. it relies on system to do the cleanup on exit) is
> not an issue.
> 

Still, though, it's Bad Practice not to clean up after yourself,
even though it's "just" a command line utility.  Who knows what
weird, unexpected side effects there might be from running such an
app within a tight bash loop.

- --
Ron Johnson, Jr.
Jefferson LA  USA

ESPN makes baseball players better.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIM4mtS9HxQb37XmcRArSXAJ92VD0i7lBncKAt65cOo2J2s7aq8wCfUsfz
NHsVsPSaxuuaWonjTRuLJ0o=
=ee7/
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

debian-installer: driver disk compatibility

[Ken Teague]

Since Debian isn't really supported by most hardware vendors, it makes
it difficult to install the distribution when the kernel on the
installation media doesn't support, say, a RAID controller or the IDE
chipset... things of that nature.  However, hardware vendors over the
years are starting to embrace and support some of the other major
distributions such as Red Hat, SuSE, and others.

What method does Debian have for someone to load a 3rd party module,
besides going to another VT and manually doing it?  Would it be too much
to request that the Debian installer be adjusted to accept 3rd party
driver disks designed for other major distributions?  For example, lets
say I have a new motherboard with a chipset that isn't supported by the
current Linux kernel on the Debian installation media.  I go to said
manufacturers web site and they have downloads for Red Hat and SuSE.  I
download either of the two, pop in the floppy disk, and
Debian is able to determine whether it's designed for distribution X and
loads the module.  That, in itself, would be the next best thing since
the "alien" package. :-)

Best regards,
Ken Teague


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: what about an special QA package priority?

[Nicolas François]

Hi,

On Tue, May 20, 2008 at 05:21:07PM -0300, Luciano Bello wrote:
> Hi list,
> I was thinking about the Debian/OpenSSL debacle. Clearly it not easy to 
> manage a hard meticulous QA process in all packages. In the other hand, there 
> are packages more critical than others, which are more delicate to security.
> Sometimes, those packages have different priorities in the policy meaning. 
> Maybe we can implement this as an Optional header in the control.
> The point is: if we can create critical QA category for delicate packages in 
> the security sense we can have mandatory QA requirement.

It will be hard to define this list of "delicate" packages.
For example, I'm not sure I would have put openssl in the list a few weeks
ago.
I would have first think about setuid/setgid programs, servers, with high
popcon packages first.

> For example:
>  - It should be checked with debugging tools (like valgrind :P)

It's not always needed.
It may show some bad practices, but having a command line utility which
allocate some resources (memory, syslog, files, PAM, ...) and does not
free them directly (i.e. it relies on system to do the cleanup on exit) is
not an issue.

If you want to improve quality, you can also recommend using checkers
(splint, security checkers), code metrics tools (e.g. pmccabe), unit tests

It might be good to recommend these tools (including valgrind), and to
provide some web services to provide the reports of these tools (IIRC,
there is already some servers with rats reports; for other checkers,
formalizing some debian/rules rules could help to to start the checkers).
But I don't think it will be possible to have them mandatory.

>  - It should maintained by a team

We will only be able to advertise that these packages need comaintainers.
Or is there a defined response for the "delicate" packages with no
teams/comaintainers.

>  - It should a public VCS
>  - Its patches should be sign-off by reviewers (Raphael Hertzog (hertzog@) 
> proposed something like this)

ACK for both.

> You can extend or reduce this list. We can discuss about the implementation. 
> But I mainly want to know your opinion.

I really appreciate the idea, but it might be hard to implement.

-- 
Nekral


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: what about an special QA package priority?

[William Pitcock]

Hi,

On Tue, 2008-05-20 at 17:21 -0300, Luciano Bello wrote:
> Hi list,
>   I was thinking about the Debian/OpenSSL debacle. Clearly it not easy to 
> manage a hard meticulous QA process in all packages. In the other hand, there 
> are packages more critical than others, which are more delicate to security.
>   Sometimes, those packages have different priorities in the policy 
> meaning. 
> Maybe we can implement this as an Optional header in the control.
>   The point is: if we can create critical QA category for delicate 
> packages in 
> the security sense we can have mandatory QA requirement. For example:
>  - It should be checked with debugging tools (like valgrind :P)

Isn't valgrind how we got into this mess to begin with?

>  - It should maintained by a team
>  - It should a public VCS
>  - Its patches should be sign-off by reviewers (Raphael Hertzog (hertzog@) 
> proposed something like this)
> 
>   You can extend or reduce this list. We can discuss about the 
> implementation. 
> But I mainly want to know your opinion.
>   Please, paste the URL if you discussed this in the pass.
> 
> luciano

I think for critical packages, valgrind prettyness isn't something to
care about (unless the interest is generating suppressions).

William



signature.asc
Description: This is a digitally signed message part

Re: what about an special QA package priority?

[Miriam Ruiz]

2008/5/20 Luciano Bello <[EMAIL PROTECTED]>:
> But I mainly want to know your opinion.

I think it would be a good idea to have something like that :)

Greetings,
Miry


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#482124: ITP: lxnm -- Lightweight X11 Network Manager

[Andrew Lee]

Package: wnpp
Severity: wishlist
Owner: Andrew Lee <[EMAIL PROTECTED]>

* Package name: lxnm
  Version : 0.2
  Upstream Author : Fred Chien <[EMAIL PROTECTED]>
* URL : http://lxde.sf.net/
* License : (GPL)
  Programming Lang: (C, shell script.)
  Description : Lightweight X11 Network Manager

 LXNM(Lightweight X11 Network Manager) is a script-based lightweight
 network manager with fewer dependencies. It attempts to make networking
 configuration and setup as painless and automatic as possible.
 .
 LXNM is the default Network Manager for LXDE(the Lightweight X11
 Desktop Environment) project. It currently only works with netstat
 plugin of lxpanel.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> modified. A quick inspection shows that for most of them the only change
> is the path to Perl in the first line.

Yes, and I really wonder why they are using local perl and removing the -w
flag. Both is against best practise. I was actually asuming while seeing the
list of files, it would be the other way around :)

Gruss
Bernd


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#481973: ITP: libiptables-parse-perl -- Perl extension for parsing iptables firewall rulesets

[Franck JONCOURT]

[...]

> BTW: Just in case you don't know, there's the Debian Perl Group that
> could help with the two lib*-perl packages:
> http://wiki.debian.org/Teams/DebianPerlGroup

Thanks, I did not know about it.

---
Franck Joncourt
http://www.debian.org/ - http://smhteam.info/wiki/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

what about an special QA package priority?

[Luciano Bello]

Hi list,
I was thinking about the Debian/OpenSSL debacle. Clearly it not easy to 
manage a hard meticulous QA process in all packages. In the other hand, there 
are packages more critical than others, which are more delicate to security.
Sometimes, those packages have different priorities in the policy 
meaning. 
Maybe we can implement this as an Optional header in the control.
The point is: if we can create critical QA category for delicate 
packages in 
the security sense we can have mandatory QA requirement. For example:
 - It should be checked with debugging tools (like valgrind :P)
 - It should maintained by a team
 - It should a public VCS
 - Its patches should be sign-off by reviewers (Raphael Hertzog (hertzog@) 
proposed something like this)

You can extend or reduce this list. We can discuss about the 
implementation. 
But I mainly want to know your opinion.
Please, paste the URL if you discussed this in the pass.

luciano


signature.asc
Description: This is a digitally signed message part.

Re: divergence from upstream as a bug

[Don Armstrong]

On Tue, 20 May 2008, Stefano Zacchiroli wrote:
> The only non trivial design issue is that it should be possible to
> mark some of the patches as denoting the "current patch state"

Presumably the most recent patch is the current one; that's what I'm
actually going to do for summaries.


Don Armstrong

-- 
Guns Don't Kill People.
*I* Kill People.

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packages using VCS but with no 'Vcs-*' control field

[Stefano Zacchiroli]

On Sun, May 18, 2008 at 12:03:32PM +0300, Lars Wirzenius wrote:
> su, 2008-05-18 kello 18:40 +1000, Ben Finney kirjoitti:
> > This would still not meet the stated requirement for the proposed mass
> > bug filing, of finding packages that *do* use a VCS but don't declare
> > it.

> Of course, I wouldn't do a mass bug filing yet. I'd add a lintian check
> first, and do a d-d-a mail, and wait a couple of months.

And how would the lintian check work? lintian works on source and binary
packages, there usually all hints that the package is using a VCS are
lost (even more now that dpkg-source strip out VCS-specific files by
default, which is not a bad thing per se).

See another post of mine in this thread, I've thought at the problem of
discovering undeclared Vcs-* headers and I'm running out of good ideas.
The best I've right now is to harvest alioth.d.o looking for
debian/control-s, but there is quite a lot of room for false positives,
probably too much ...

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: divergence from upstream as a bug

[Stefano Zacchiroli]

On Tue, May 20, 2008 at 10:28:45AM +0100, Don Armstrong wrote:
> > Fair enough, but why are you referring to a _set_ of patches?
> 
> There may just be one current patch, but having access to the previous
> patches and/or attachments which describe the problem easily is
> useful. Whether debbugs display just one or displays many is a trivial
> decision once debbugs tracks them all.

ACK. The only non trivial design issue is that it should be possible to
mark some of the patches as denoting the "current patch state", probably
the same you are going to do for the summary (i.e. marking one of the
message in the bug log as "current bug state"). Thanks for this
developments BTW.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Bug#482073: ITP: wnpp -- libwill-paginate-ruby

[Gunnar Wolf]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

   Package name: libwill-paginate-ruby
Version: 2.3.2
Upstream Author: Mislav Marohnić <[EMAIL PROTECTED]>
URL: http://github.com/mislav/will_paginate/wikis
License: MIT/X
Description: Ruby plugin adding pagination to ActiveRecord

Pagination is just limiting the number of records displayed, showing a
subset of them at any given view, and allowing you to move the
displayed window. This plugin makes the whole process a breeze.

WillPaginate is aimed at being used from the Ruby on Rails framework.

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Michael Banck]

On Tue, May 20, 2008 at 07:48:55AM +0200, Goswin von Brederlow wrote:
> Michael Banck <[EMAIL PROTECTED]> writes:
> > Try to git-format-patch (or whatever tool applies for the particular
> > DVCS) each feature branch, see whether they apply cleanly by
> > luck/accident.  If so, store them as a 3.0 (quilt) debian/patches.
> 
> They will not except for trivial cases. And in trivial cases you can
> probably seperate patches from on big patch reasonably well too.

I'm not sure what you mean with "trivial cases".  Most patches I've seen
to upstream involve different source files, with the exception of
Makefile{,.in,.am}, maybe.  Even if a change involves several source
files and another the same, it's not a given that the changes necessary
overlap.

So I think it works except for complicated cases.


Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Heads up: ffmpeg transition (SONAME Change!)

[Paul Wise]

On Tue, May 20, 2008 at 10:33 PM, Reinhard Tartler <[EMAIL PROTECTED]> wrote:
> Adeodato Simó <[EMAIL PROTECTED]> writes:
>
>> Er, is there a reason you're proposing this, instead of the release team
>> scheduling binNMUs?
>
> Oh, I'm sorry, you are completely right. Please ignore my post.

Some packages will need source changes, at least synfig was bit by a
structure member changing from a structure to a pointer. KiBi or I
will do this one in the next few days.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise

Re: Heads up: ffmpeg transition (SONAME Change!)

[Reinhard Tartler]

Adeodato Simó <[EMAIL PROTECTED]> writes:

> Er, is there a reason you're proposing this, instead of the release team
> scheduling binNMUs?

Oh, I'm sorry, you are completely right. Please ignore my post.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#482054: ITP: libio-compress-bzip2-perl -- Read and write bzip2-compressed files and buffers in perl

[Bas Zoetekouw]

Package: wnpp
Severity: wishlist
Owner: Bas Zoetekouw <[EMAIL PROTECTED]>

* Package name: libio-compress-bzip2-perl
  Version : 2.011
  Upstream Author : Paul Marquess <[EMAIL PROTECTED]>
* URL : * http://search.cpan.org/~pmqs/IO-Compress-Bzip2-2.011/
* License : dual GPL1+ and Artistic
  Programming Lang: Perl
  Description : Read and write bzip2-compressed files and buffers in perl

 This package provides a Perl interface that allows reading and
 writing bzip2 compressed data to files or buffers.

 It contains two perl modules: IO::Compress::Bunzip2 and
 IO::Uncompress::Bunzip2.


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#482051: ITP: libcompress-raw-bzip2-perl -- low-level interface to libbz2 compression library

[Bas Zoetekouw]

Package: wnpp
Severity: wishlist
Owner: Bas Zoetekouw <[EMAIL PROTECTED]>

* Package name: libcompress-raw-bzip2-perl
  Version : 2.011
  Upstream Author : Paul Marquess <[EMAIL PROTECTED]>
* URL : * http://search.cpan.org/~pmqs/Compress-Raw-Bzip2-2.011/
* License : dual GPL1+ and Artistic
  Programming Lang: perl
  Description : low-level interface to libbz2 compression library

The Compress::Raw::Bzip2 module provides a Perl low-level interface to the
libbz2 compression library.

This is the bzip2 sister of libcompress-raw-zlib-perl, and is needed
for libio-compress-bzip2-perl, which I am also packaging.


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Heads up: ffmpeg transition (SONAME Change!)

[Adeodato Simó]

* Reinhard Tartler [Tue, 20 May 2008 11:57:39 +0200]:

> Reinhard Tartler <[EMAIL PROTECTED]> writes:

> > Dear fellow debian developers.

> > Currently debian/testing ships a very old copy of ffmpeg, dated from
> > 0.cvs20070307. We, the ffmpeg maintainers (Fabian Greffrath and myself)
> > do not consider that version of ffmpeg acceptable for release in debian
> > lenny. Many newer applications of ffmpeg (like mplayer) require a newer
> > ffmpeg to build, others (like xine) are waiting for debian to update the
> > ffmpeg package.

> The new ffmpeg package now has entered unstable and did build on all
> architectures successfully. Please rebuild your packages against this
> new version of ffmpeg at your earliest convenience.

Er, is there a reason you're proposing this, instead of the release team
scheduling binNMUs?

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
 Listening to: Mónica Naranjo - Desátame


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#482047: ITP: openssl-blacklist -- list of blacklisted OpenSSL RSA keys

[Christoph Martin]

Package: wnpp
Severity: wishlist
Owner: Christoph Martin <[EMAIL PROTECTED]>


Contains the list of known-bad OpenSSL keys for openssl-vulnkey to use when
 examining suspect keys.

The Ubuntu openssl maintainers released a openssl-blacklist equivalent
to the openssh-blacklist package. It includes a blacklist with
compromised openssl key hashes and a program with a openssl-vulnkey
program suitable to test your openssl key files.

I think it would be a good think to coordinate the work between debian
and ubuntu and to incorporate this package into debian main.

* Package name: openssl-blacklist
  Version : 0.1
  Upstream Author : Jamie Strandboge <[EMAIL PROTECTED]>
* URL : https://launchpad.net/ubuntu/+source/openssl-blacklist/
* License : (GPL.)
  Programming Lang: (Python)
  Description : list of blacklisted OpenSSL RSA keys

(Include the long description here.)

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (900, 'stable'), (70, 'testing'), (50, 'unstable')
Architecture: i386 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.22-4-amd64
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Gunnar Wolf]

Goswin von Brederlow dijo [Tue, May 20, 2008 at 08:10:05AM +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-version.diff.
> 
> Yes it will. Any modified file will end up in debian/patches/ instead
> of modifying the file directly. It will not prevent patches but it
> ensures they are used exclusively. So no packages that change some
> files directly and use debian/patches/ for others.

Ok... I have not followed the development of the new package version

> > But with some time put to it, we can end up including a "the
> > maintainer shuold not modify files outside of the debian/ directory
> > without a strong rationale", and provide lintian checks for packages
> > still directly modifying upstream code...
> 
> Do you mean no debian/patches at all?

No, of course not - But I _do_ mean no patches with no rationale at
all. If I understand correctly, were I to repackage something I have
now that directly modifies the upstream code, my whole unorganized
patchwork probably become something like debian/patches/01. Of course,
a tool cannot understand _what_ it does, and how it should be split. I
suppose (and, again, I'm just guessing right now, please forgive me) a
good maintainer would split and name that in
debian/patches/01_fixes_blah, debian/patches/02_foo and so on, and in
each of the files' headers would note what bug or issue is this patch
addressing. And we can make tools understand said headers - and
complain if an unexplained patch was found.

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: possible mass-bug filing on fc-cache-using packages

[Adam D. Barratt]

martin f krafft wrote, Tuesday, May 20, 2008 1:41 PM

also sprach Josselin Mouette <[EMAIL PROTECTED]> [2008.05.20.1323 +0100]:
> Le mardi 20 mai 2008 à 12:05 +0100, martin f krafft a écrit :
> >   if [ "$1" = configure -a -x /usr/bin/fc-cache ]
>
> Note -that the "$1" = configure check is wrong, see #446856.

Also, the -a is a bashism, isn't it?


It is, but one that policy 10.4 explicitly permits.

Adam 



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: possible mass-bug filing on fc-cache-using packages

[martin f krafft]

also sprach brian m. carlson <[EMAIL PROTECTED]> [2008.05.20.1321 +0100]:
> I could be wrong, but if the subshell exits 1, then the entire
> expression is false, and so if you are using "set -e" like you're
> supposed to, then the postinst fails.

The policy mentions it, but it doesn't say set -e is required.
ttf-bitstream-vera does not use it.

> ttf-bitstream-vera isn't using set -e, which is probably a bug.  ISTR
> that policy dictated set -e.

I don't think so, section 6.1:

  or shell scripts this means that you almost always need to use set
  -e (this is usually true when writing shell scripts, in fact).

This, to me, is waste of space in a policy document.



also sprach Josselin Mouette <[EMAIL PROTECTED]> [2008.05.20.1323 +0100]:
> Le mardi 20 mai 2008 à 12:05 +0100, martin f krafft a écrit :
> >   if [ "$1" = configure -a -x /usr/bin/fc-cache ]
> 
> Note -that the "$1" = configure check is wrong, see #446856.

Also, the -a is a bashism, isn't it?

> Since the postinst uses set -e, it will also exit it.

It does not.

> > But instead of having everyone fix this, I wonder
> > why debhelper isn't taking care of this. Thoughts?
> 
> This is not needed anymore. Fontconfig should manage this through a
> trigger, removing entirely those snippets.

Okay, that should make it easier... :)

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"it isn't pollution that's harming the environment.
 it's the impurities in our air and water that are doing it." 
  - dan quayle


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: possible mass-bug filing on fc-cache-using packages

[Josselin Mouette]

Le mardi 20 mai 2008 à 12:05 +0100, martin f krafft a écrit :
>   if [ "$1" = configure -a -x /usr/bin/fc-cache ]

Note -that the "$1" = configure check is wrong, see #446856.

> (echo "failed; see /var/log/fontconfig.log for more information."; \
> exit 1)

> This is wrong. Using ()'s creates a subshell, and exit then only
> exits the subshell, not the postinst (which I believe it's supposed
> to do). 

Since the postinst uses set -e, it will also exit it.

> But instead of having everyone fix this, I wonder
> why debhelper isn't taking care of this. Thoughts?

This is not needed anymore. Fontconfig should manage this through a
trigger, removing entirely those snippets.

Cheers,
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: possible mass-bug filing on fc-cache-using packages

[brian m. carlson]

On Tue, May 20, 2008 at 12:05:46PM +0100, martin f krafft wrote:

Hi folks,

I noticed the other day that there are quite a few packages like
ttf-bitstream-vera which do the following in
/var/lib/dpkg/info/ttf-bitstream-vera.postinst:

 if [ "$1" = configure -a -x /usr/bin/fc-cache ]
 then
   echo -n "Regenerating fonts cache... "
   HOME=/root fc-cache -f -v 1>/var/log/fontconfig.log 2>&1 || \
   (echo "failed; see /var/log/fontconfig.log for more information."; \
   exit 1)
   echo "done."
 fi

This is wrong. Using ()'s creates a subshell, and exit then only
exits the subshell, not the postinst (which I believe it's supposed
to do). The code either needs an "|| exit $?" appended, or {}'s
should be used. Compare


I could be wrong, but if the subshell exits 1, then the entire
expression is false, and so if you are using "set -e" like you're
supposed to, then the postinst fails.

For example, at the prompt, try:
  (set -e; echo 1; false || (echo error; exit 1); echo 2)
which will never print "2".

ttf-bitstream-vera isn't using set -e, which is probably a bug.  ISTR
that policy dictated set -e.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

possible mass-bug filing on fc-cache-using packages

[martin f krafft]

Hi folks,

I noticed the other day that there are quite a few packages like
ttf-bitstream-vera which do the following in
/var/lib/dpkg/info/ttf-bitstream-vera.postinst:

  if [ "$1" = configure -a -x /usr/bin/fc-cache ]
  then
echo -n "Regenerating fonts cache... "
HOME=/root fc-cache -f -v 1>/var/log/fontconfig.log 2>&1 || \
(echo "failed; see /var/log/fontconfig.log for more information."; \
exit 1)
echo "done."
  fi

This is wrong. Using ()'s creates a subshell, and exit then only
exits the subshell, not the postinst (which I believe it's supposed
to do). The code either needs an "|| exit $?" appended, or {}'s
should be used. Compare

  sh -c '( echo foo; exit 1; ); echo bar' 
  sh -c '{ echo foo; exit 1; }; echo bar' 

The reason seems to be brainless cut-n-pasting.

I think this calls for a mass-bug filing on fc-cache-using packages,
severity minor. But instead of having everyone fix this, I wonder
why debhelper isn't taking care of this. Thoughts?

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"even a stopped clock gives the right time twice a day."
-- orbital


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: Heads up: ffmpeg transition (SONAME Change!)

[Reinhard Tartler]

Reinhard Tartler <[EMAIL PROTECTED]> writes:

> Dear fellow debian developers.
>
> Currently debian/testing ships a very old copy of ffmpeg, dated from
> 0.cvs20070307. We, the ffmpeg maintainers (Fabian Greffrath and myself)
> do not consider that version of ffmpeg acceptable for release in debian
> lenny. Many newer applications of ffmpeg (like mplayer) require a newer
> ffmpeg to build, others (like xine) are waiting for debian to update the
> ffmpeg package.

The new ffmpeg package now has entered unstable and did build on all
architectures successfully. Please rebuild your packages against this
new version of ffmpeg at your earliest convenience.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Pierre Habouzit]

On Tue, May 20, 2008 at 06:07:14AM +, Goswin von Brederlow wrote:
> How do you tell git-rerere to keep all conflict resolutions needed to
> convert feature branches into a patch series but not others?

  I was merely answering a first set of questions, for the rest please
read documentation git-rerere(1) e.g. This part of the thread is
*really* becoming OT.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpacYazid1E6.pgp
Description: PGP signature

Re: divergence from upstream as a bug

[Pierre Habouzit]

On Tue, May 20, 2008 at 07:50:10AM +, Don Armstrong wrote:
> On Tue, 20 May 2008, Pierre Habouzit wrote:
> >TTBOMK emacs does too.
> 
> Emacs is currently evaluating debbugs.

  Well, then my point stands, debbugs _is_ also a sane BTS for reporting
bugs :)

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpjLqif6RjxR.pgp
Description: PGP signature

Re: divergence from upstream as a bug

[Don Armstrong]

On Tue, 20 May 2008, Stefano Zacchiroli wrote:
> On Tue, May 20, 2008 at 09:02:21AM +0100, Don Armstrong wrote:
> > The idea was that a patch, since it would actually contain the
> > resolution of the original problem, would be the correct place to
> > summarize the problem. However, on thinking about it more, I think
> > that having a single summary, with a set of patches and possibly
> > attachments located near the summary is the way to go. I haven't
> 
> Fair enough, but why are you referring to a _set_ of patches?

There may just be one current patch, but having access to the previous
patches and/or attachments which describe the problem easily is
useful. Whether debbugs display just one or displays many is a trivial
decision once debbugs tracks them all.
 
> > This is an unecessary restriction, as not all patches need
> > necessarily be diff files. Making it easy to extract extractable
> > patches should be good enough; those that can't will just have to
> > refer to a message.
> 
> What other kind of patches, beside diffs, are you referring to?
> Stuff like prose explanation on how to fix a problem, binary blobs,
> or what else?

Yes.

> Anyhow, even if you make the distinction between extractable and
> non-extractable patches, I think diff should be extractable, and
> allowing them to be inlined is a PITA. Maybe this can be overcomed
> at an API implementation level, with some logics to recognize
> inlined diffs in messages tagged +patch which are missing
> attachments? It starts looking complicate though ...

I don't want to add in a set of restriction mechanisms to when a tag
can and cannot be placed. Making the automatic extraction work with
extractable patches and attachments and documenting this fact should
be enough to encourage their use without unecessarily restricting
flexibility and making the tagging fragile because of it.


Don Armstrong

-- 
Democracy is more dangerous than fire. Fire can't vote itself immune
to water.
 -- Michael Z. Williamson

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Stefano Zacchiroli]

On Tue, May 20, 2008 at 09:02:21AM +0100, Don Armstrong wrote:
> The idea was that a patch, since it would actually contain the
> resolution of the original problem, would be the correct place to
> summarize the problem. However, on thinking about it more, I think
> that having a single summary, with a set of patches and possibly
> attachments located near the summary is the way to go. I haven't

Fair enough, but why are you referring to a _set_ of patches? For the
sake of simplicity assuming that a bug has a single patch sounds like a
fair assumption to me. Of course the patch can patch multiple files and
of course and can be obtained only after a round of repeated
submissions, but in the end: one bug, one patch.  If you agree on this I
think the BTS interface should exploit the principle: at most one
"current" patch, as it will have at most one "current" summary.

> > But still this does not solve another problem we have with patch
> > management in the BTS: they are sometimes inlined, while sometimes
> > the are attached. Can't we fix attachment as the required format for
> This is an unecessary restriction, as not all patches need necessarily
> be diff files. Making it easy to extract extractable patches should be
> good enough; those that can't will just have to refer to a message.

What other kind of patches, beside diffs, are you referring to? Stuff
like prose explanation on how to fix a problem, binary blobs, or what
else?  I tend to believe that diffs are the only things we are usually
interested in pushing upstream, but not knowing the other kind of
patches you have in mind I can't be sure.

Anyhow, even if you make the distinction between extractable and
non-extractable patches, I think diff should be extractable, and
allowing them to be inlined is a PITA.  Maybe this can be overcomed at
an API implementation level, with some logics to recognize inlined diffs
in messages tagged +patch which are missing attachments? It starts
looking complicate though ...

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: How to handle Debian patches

[Stefano Zacchiroli]

On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote:
> And then you go saying things like that:
> > It is trivial to generate a quilt format package from git/arch/hg/svn
> > and I'm sure there will be a RCS-build-package soon enough that does
> > that. 
> This can not happen without manual intervention, if the topic
>  branches have overlap. And  Redoing the manual conflict resolution over

I stopped buying this argument (generally, not specifically from you) on
the basis that in most of the cases packages have several non
overlapping patches wrt upstream.  So the "trivial" part above is indeed
true for a lot of packages.

The remaining ones will indeed need manual intervention, but aren't this
kind of changes those which are supposed to be pushed upstream? So some
more burden on the developer on these rare (if you buy my statement
above) cases can even be beneficial from a social point of view.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: How to handle Debian patches

[Stefano Zacchiroli]

On Sat, May 17, 2008 at 10:18:58PM +0100, Roger Leigh wrote:
> The syntax for the fields also does not currently let you specify a
> branch or tag, it's just the whole repo.  Personally, I'd like it to
> allow specification of the branch/tag used to produce the specific
> release of the package in Sources.gz (or better, the latest
> development on that branch).
> 
> For example:
> 
>   Vcs-Git: git://git.debian.org/git/buildd-tools/schroot
> 
> This gives you the master branch, but the Debian packages are actually
> on the schroot-1.2 stable release branch.  For people who want to hack
> on what's actually in use in Debian testing/unstable right now, this
> is the wrong branch.

This is coherent with the initial idea of the field: give a human being
(the Debian maintainer) a pointer to where the packages is being worked
on. Then you will need some additional information to know where to
look, as you would looking on the VCS tab of sourceforge or on the
author homepage.

If, as it seems to me, we are now starting to feel the need of having
more structure Vcs-* information so as to enable _automatic_ processing
of VCS information, well, let's sit down and standardize that. Though
note that this will need to be done on a per-Vcs basis, as concepts from
one VCS not necessarily apply to other (that's for example why we have
$VCS-buildpackage rather than a single vcs-buildpackage).

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: divergence from upstream as a bug

[Don Armstrong]

On Mon, 19 May 2008, Stefano Zacchiroli wrote:
> How I'm reading the latter paragraph is that patch messages are
> *alternative* as some non-patch summary message, am I wrong? I think
> the two should be orthogonal: you can have or not a summary message,
> you can have or not a patch.

The idea was that a patch, since it would actually contain the
resolution of the original problem, would be the correct place to
summarize the problem. However, on thinking about it more, I think
that having a single summary, with a set of patches and possibly
attachments located near the summary is the way to go. I haven't
completely decided how this should be implemented, though.

> But still this does not solve another problem we have with patch
> management in the BTS: they are sometimes inlined, while sometimes
> the are attached. Can't we fix attachment as the required format for
> patches? (e.g. forcing an attachment if one wants to add +patch or
> something similar). This + the forthcoming ability above to identify
> *the* latest patch will give us the ability to automatically extract
> patches from bug reports.

This is an unecessary restriction, as not all patches need necessarily
be diff files. Making it easy to extract extractable patches should be
good enough; those that can't will just have to refer to a message.


Don Armstrong

-- 
 why the hell does kernel-source-2.6.3 depend on xfree86-common?
 It... Doesn't?
 good point

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Don Armstrong]

On Tue, 20 May 2008, Pierre Habouzit wrote:
>TTBOMK emacs does too.

Emacs is currently evaluating debbugs.


Don Armstrong

-- 
I may not have gone where I intended to go, but I think I have ended
up where I needed to be.
 -- Douglas Adams _The Long Dark Tea-Time of the Soul_

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

[Lars Wirzenius]

ti, 2008-05-20 kello 00:01 +0200, Andreas Tille kirjoitti:
> > 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 other fellow developers in this thread.  Just reread and come back
> if you are really sure that an extra hint about patches is really useless.

I'm a fairly long-time Unix user. I find it much preferably when command
line tools are quiet by default when things are going well. Providing a
--verbose option rather than a --quiet option would be my preference.
Having a tool print out a lot of information that is peripheral to what
I'm doing is distracting, and if it happens often, I start mentally
ignoring the output until something breaks. Listing patches when I
unpack source is one of those cases to me.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]