On Sun, 02 Dec 2007, Mike Hommey wrote:
On Sun, Dec 02, 2007 at 05:11:52PM +0100, Loïc Minier wrote:
What do you think of such a system? Please share your ideas and
comments!
I think there is a problem using build dependencies for that purpose:
There are dozens of reasons why you want
On Fri, 07 Dec 2007, Loïc Minier wrote:
I do imagine it wont be mandatory (or useful) for all libs as well and
I agree it should be added on a per package basis; one idea I
mentionned to Raphaël is to extend the shlibs / symbols system to allow
a syntax meaning Take the build-dep version
On Sat, 08 Dec 2007, Nico Golde wrote:
To make sure packages don't end up with only inactive (co-)maintainers.
That could be avoided if you check that every maintainer of
the package is MIA.
A MIA-check is not something instantaneous. It takes several months. So
it's not really possible...
On Fri, 07 Dec 2007, Loïc Minier wrote:
On Fri, Dec 07, 2007, Raphael Hertzog wrote:
libgtk-x11-2.0.so.0 libgtk2.0-0 #MINVER#
* Devel-Package: libgtk2.0-dev
[EMAIL PROTECTED] 2.8.0
...
How does that sound ?
Sounds like a good start! Perhaps the injection should be explicitely
On Mon, 10 Dec 2007, Sune Vuorela wrote:
On 2007-12-10, Loïc Minier [EMAIL PROTECTED] wrote:
I think in both cases it was something like the main binary being
linked to many utility libraries (because it was easy to link it to
everything which configure found), and then the plugin
Hello Daniel,
On Thu, 20 Dec 2007, Daniel Baumann wrote:
there are more and more packages which require wxwidgets =2.8. Last
time[0], I hoped somebody would finally take care of it, but nothing
happened yet.
With the new version of poedit, it's not possible to build anymore with an
older
On Wed, 26 Dec 2007, Luca Brivio wrote:
BTW, I don't know what's with the Collaborative Repository of
Meta-Informations[1]. Maybe Raphael can provide some useful insights to the
debate.
Well, CRMI is still a concept, we got mole implemented by Jeroen which
helps a lot in archive-wide
On Thu, 03 Jan 2008, Luk Claes wrote:
* Show the N: line with a count of overrides per package by default and
provide an option to suppress this output if someone wants.
* Don't show the N: line by default and provide an option to turn it on.
Which should we do?
We should show
On Wed, 02 Jan 2008, Russ Allbery wrote:
Currently on dpkg I have 4 N: lines: one per deb + one for the
.dsc. That clutters the output a bit too much to my taste. And ideally
it should be at the end of the output (or at the beginning) but not
spread in the output.
I was going to ask:
On Sat, 05 Jan 2008, Lars Wirzenius wrote:
On la, 2008-01-05 at 13:43 +, Steve McIntyre wrote:
As you might expect (as I was the requester for this feature) I'd
*really* prefer the former option. My initial reasoning for it is that
I want to make it immediately visible to sponsors if a
On Wed, 16 Jan 2008, Michael Banck wrote:
I think Thijs meant the changelog entries 1.0.4-0ubuntu1 and
1.0.4-0ubuntu2, which are not in the .changes.
Maybe it would be alright to say Synchronize with Ubuntu (closes:
#foo) IF #foo is a please synchronise with Ubuntu bug (similar to a
new
On Mon, 21 Jan 2008, Joey Hess wrote:
The shell functions already have a fairly reasonable interface.
rm_conffile mypackage /etc/pkg/conf.1
prep_mv_conffile mypackage /etc/pkg_conf.1
mv_conffile /etc/pkg_conf.1 /etc/pkg/conf.1
This is not the best possible interface; it
On Mon, 21 Jan 2008, Roger Leigh wrote:
Maybe we could integrate those shell functions into the dpkg package
itself until dpkg is fixed to handle them better. At least, dpkg could
replace them with no-op when the proper support is in place.
A fix in dpkg would, IMO, be ideal. I think
On Tue, 22 Jan 2008, [EMAIL PROTECTED] wrote:
I looked at the output of this command:
c++filt libgtkmathview0c2a_i386 | grep MISSING
I see lots of mentions of SmartPtr and a few of TemplateBuilder.
ComputerModernShaper seems to be gone.
It's not gone... if you check carefully you'll
On Fri, 25 Jan 2008, Michael Banck wrote:
On Fri, Jan 25, 2008 at 10:51:05AM +0100, Lucas Nussbaum wrote:
On 25/01/08 at 08:01 +, Steve Langasek wrote:
As a second runner up, quilt is ok by me. :)
I made some stats (see [1]). 7.8% of our packages use quilt, while 14.4%
use
On Mon, 28 Jan 2008, Russ Allbery wrote:
I agree with Lars that we should move toward requiring it to work.
What I'd like to see is a Debian source package format that supports
essentially quilt metadata -- in other words, a series file and a set of
patches. It's a very minor addition to
On Tue, 29 Jan 2008, Russ Allbery wrote:
I wouldn't worry about any metadata at all; dpkg-source would just apply
all the patches in the series file (or, really, we could just script a
conversion from quilt to wigpen by appending arbitrary numbers to the
patches based on the series file and
Hello,
On Mon, 28 Jan 2008, Roger Leigh wrote:
On Sun, Jan 27, 2008 at 09:08:44AM +0100, Martin Zobel-Helas wrote:
http://ftp-master.debian.org/bzr/
Why isn't this on bzr.debian.org?
Probably for the same reason that DSA tools are not on bzr.debian.org
either (but on db.debian.org). It
On Wed, 30 Jan 2008, Holger Levsen wrote:
Hi,
On Tuesday 29 January 2008 00:55, Russ Allbery wrote:
Of course, since other syslog implementations are potentially better in
larger ways, there may still be good reason to switch the default syslog
to another implementation.
It seems to
On Fri, 01 Feb 2008, Ben Finney wrote:
Daniel Leidert [EMAIL PROTECTED] writes:
And people should check the VCS history just to get the current
patch?
What is the current patch? If you mean the entire set of differences
against the upstream source, I already addressed that: simply
On Thu, 31 Jan 2008, Michael Biebl wrote:
Should, I file a lenny release goal first and wait for it's approval, or
can I take this thread as consensus that I can pursue changing the
default system-log-daemon to rsyslog?
Go ahead and keep up the good work!
Cheers,
--
Raphaël Hertzog
Le
On Fri, 01 Feb 2008, Ben Finney wrote:
Raphael, please follow the Debian Mailing List code of conduct
URL:http://www.debian.org/MailingLists#codeofconduct; in particular,
don't send individual copies of list messages unless specifically
requested.
If you were using mutt and a right
Hi,
On Fri, 01 Feb 2008, Kumar Appaiah wrote:
On 01/02/2008, Raphael Hertzog wrote:
With git I'd use a debian-patches branch that I would rebase on the
upstream branch regularly and would edit history of changes as needed so
that one commit generates one file in debian/patches/.
Dear
On Sat, 02 Feb 2008, Charles Plessy wrote:
Is there sombody working on WigPen? Is the format consensual enough
that it would be accepted in Debian?
I plan to work on it (but have not done anything yet except thinking about
it and following discussions), the format might need some tweaks
On Sat, 02 Feb 2008, Kumar Appaiah wrote:
On Fri, Feb 01, 2008 at 06:06:04PM +0100, Raphael Hertzog wrote:
No, I said rebase and not merge.
See http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
(Note that this means that nobody should derive from upstream-patched
On Mon, 04 Feb 2008, John Goerzen wrote:
On Sun February 3 2008 10:47:59 am Raphael Hertzog wrote:
On Sat, 02 Feb 2008, Kumar Appaiah wrote:
I was explaining how I would handle patches on top of upstream code. And
where you have to update the patches when the upstream code changes
Hi,
On Tue, 05 Feb 2008, Paul Wise wrote:
I was reviewing a library package RFS (libthai) and I noticed that the
shlibs pointed at version X and all the symbols in the symbols file
pointed at an earlier version. Here I assume that the shlibs should be
changed to point to the earlier version?
On Thu, 07 Feb 2008, Guillem Jover wrote:
If nobody has any objections, i'll follow Frans' advice and file a bug
against dpkg-dev.
Yes, makes sense. I've just fixed it in dpkg's git [0].
Except it will only work if the package uses 'Package-Type' and not
'X*-Package-Type'. We should maybe
Hi,
On Wed, 13 Feb 2008, Kapil Hari Paranjape wrote:
I was wondering how to interpret the GR altering upload rules
(http://www.debian.org/vote/2007/vote_002) in practical terms.
I suppose this means that one can upload a pkg-ver_multi.changes
file containing pkg-ver_arch.deb for multiple
Hello,
On Sun, 17 Feb 2008, Raphael Geissert wrote:
Rationale: the watch files are meant to keep track of upstream and if there's
a newer version not being reported by the watch file it means that it needs
to be fixed.
Please note that this situation often occurs when the maintainer
On Sun, 17 Feb 2008, Raphael Geissert wrote:
Ack, what about only reporting (thus in a non automated way) on those which
are not affected by any repackaging/similar version part?
It's might be acceptable but I'm not sure either. Some packages have
development version packaged and those
On Mon, 18 Feb 2008, Julien Cristau wrote:
On Sun, Feb 17, 2008 at 19:38:55 -0600, Raphael Geissert wrote:
If no one objects I'll start MBF within a week or, if encouraged to and
with
no objection, probably during the week.
Do we really need a mass bug filing for every single
On Mon, 18 Feb 2008, Raphael Geissert wrote:
Besides of what Stephen Gran already said on his message I believe there's
no chance of NMU's to take place if the bugs aren't reported :).
I would never NMU just to correct an harmless rpath. Thus if I NMU such a
package, it's because of something
On Wed, 20 Feb 2008, Mike Hommey wrote:
Yeah, it must be really hard to be an heavy bug filer.
* 1552 Outstanding
* 136 Forwarded
* 10 Pending Upload
* 1 Fixed in NMU
* 69 Resolved
Note that if you look at his archived bugs you have to add:
* 2010 Resolved
Some
On Thu, 21 Feb 2008, Mike Hommey wrote:
Some bugs are of dubious quality, but one must accept that in the end, it's
still impressive. :)
Note that also doesn't indicate how many were actually fixed. We have
nothing that look like bugzilla's NOTABUG or INVALID.
Indeed. One could check how
Hi,
On Thu, 21 Feb 2008, Kevin B. McCarty wrote:
I've just noticed that packages I've built recently have had the list of
Depends reorganized into ASCIIbetical order in the generated binary
.debs. I guess this was the next logical step after having dpkg-dev
re-order Build-Depends internally
On Fri, 22 Feb 2008, Norbert Preining wrote:
On Fr, 22 Feb 2008, Raphael Hertzog wrote:
I can understand it might change the list of packages pulled, but both set
are supposed to work since that what dependencies are expressing. If you
I disagree. Sometimes alternatives are something we
On Thu, 21 Feb 2008, Don Armstrong wrote:
On Thu, 21 Feb 2008, David Nusinow wrote:
We could deal with this problem if we were better at training and
recruiting people to work on such things. We've been lucky in the
XSF lately in getting enough hands to get the work done, but I don't
On Fri, 22 Feb 2008, Otavio Salvador wrote:
Sergei Golovan [EMAIL PROTECTED] writes:
Then having a unique, well-defined order of packages in Depends is a
good idea. If packages aren't sorted their order is undefined (not all
of the dependencies are added by hands, many of them come from
Hi,
On Fri, 22 Feb 2008, Mike Bird wrote:
I won't revert anything unless you come up with some proof that this
causes severe issues that will disturb the lenny release process.
Raphael,
What please is the benefit of unnecessarily reordering dependencies
and leaving everyone on
On Fri, 22 Feb 2008, Daniel Burrows wrote:
On Fri, Feb 22, 2008 at 08:50:37PM +0100, Raphael Hertzog [EMAIL PROTECTED]
was heard to say:
No, Sergei is right. The order of packages within ${shlibs:Depends} is not
defined, you're not completely avoiding the problem by reverting the
change
On Sun, 24 Feb 2008, Charles Plessy wrote:
Therefore we did not make progress since the beginning of the
discussion:
You're trying to make progress somewhere where it's not expected.
- The most efficient way to deal with changes to the sources for the
packager is to use his preferred
Hi Ian,
On Fri, 22 Feb 2008, Ian Jackson wrote:
There is in my opinion no reason why this code should not be merged
into sid's dpkg immediately - although there may be some merge
conflicts by now. (I haven't been playing merge catch-up since I
don't presently feel that my changes are going
On Sun, 24 Feb 2008, Charles Plessy wrote:
Le Sun, Feb 24, 2008 at 10:47:05AM +0100, Raphael Hertzog a écrit :
- When modifying a package that uses dpatch, quilt or simple-patchsys,
developpers have to find out by themselves if the target for patching
the sources is patch, apply
Hi,
On Sun, 24 Feb 2008, Manoj Srivastava wrote:
I like the reduced work for each upload, and since it satisfies
the use cases of being able to present upstream with a pure feature
changeset;
It doesn't satisfy it completely. You can always generate a patch for
a pure feature
Hi,
On Sun, 24 Feb 2008, Ian Jackson wrote:
Raphael Hertzog writes (Re: dpkg-buildpackage now reorganizing
debian/control Dependsfield??):
I won't revert anything unless you come up with some proof that this
causes severe issues that will disturb the lenny release process.
I
On Mon, 25 Feb 2008, Pierre Habouzit wrote:
I vote for clean history and a bissectable tree, and I think it is worth the
effort. But I am no dpkg developer, this is a thing you guys have to find
an agreement among yourselves.
You vote for the mad route. Sorry, but it makes absolutely
Hi,
On Mon, 25 Feb 2008, nic wrote:
to cut the longway short: I'm iterested, but don't know how it works or
how I could contribute.
I don't know what needs to be explained... you don't need any special
status to contribue a mascot, just find the idea, create the picture, send
it to us and wait
On Tue, 26 Feb 2008, Ian Jackson wrote:
But, is it really worth the effort to go back and edit revision logs
now ? And if I do so, will I disrupt merging any less than if I
rebase ?
As soon as you edit commits, they'll get a new id, and thus you'll disrupt
merging.
The thing that you
On Thu, 28 Feb 2008, Ian Jackson wrote:
Mark Brown writes (Re: git bikeshedding (Re: triggers in dpkg, and dpkg
maintenance)):
I've no idea if anyone involved would consider it acceptable but might
merging the triggers branch into the mainline with --squash be a
suitable comprimise? This
On Thu, 28 Feb 2008, Steve Langasek wrote:
On Thu, Jan 24, 2008 at 09:07:07PM -0600, Raphael Geissert wrote:
* New upstream version notifications
Since yesterday DEHS started sending notifications to the 'summary'
tag/keyword of the PTS when it finds a new upstream version.
Was this
On Fri, 29 Feb 2008, Martin Zobel-Helas wrote:
And/or creating a new mailing list, debian-itp, debian-devel-itp or
whatever might be a good idea. Quite a big number of mails to the
debian-devel mailing list are ITPs.
I also thought the same some time ago, on the other hand development of
On Sat, 01 Mar 2008, Manoj Srivastava wrote:
Why do we have to settle on a quilt based source package, when
my proposal meets all the requirements anyway? Why does it have to be
one or the other?
It's not going to be one or the other. Note that your changes on upstream
code can be a
On Sun, 02 Mar 2008, Robert Collins wrote:
On Sun, 2008-03-02 at 02:09 -0300, Henrique de Moraes Holschuh wrote:
And I am completely *sure* it would not be irrelevant for me were I
debugging dpkg without a full, complete, dpkg-regular-developer level of
understanding of the code. Or
On Sun, 02 Mar 2008, Henrique de Moraes Holschuh wrote:
On Sun, 02 Mar 2008, Robert Collins wrote:
Well, when I sat down some years back to do a couple of things with
dpkg; I found no need to consult change logs to understand the current
code of the time. Perhaps its quality has massively
On Wed, 05 Mar 2008, Ian Jackson wrote:
What's the difference, really? Isn't it a case of people on all sides
trying to control each other instead of cooperating?
What would you like me to do ?
Either do the supplementary work or wait patiently with some _friendly_
nagging from time to
On Wed, 05 Mar 2008, Mike Bird wrote:
Please post the URL for this policy. I apologize if you've already
posted and I missed it, but Google couldn't find it for me.
http://wiki.debian.org/Teams/Dpkg/GitUsage
Now I would appreciate if you could stop spreading lies and aggressive
remarks in
On Sun, 09 Mar 2008, Ian Jackson wrote:
With this message I am unilaterally declaring myself a maintainer of
dpkg, and also declaring that Guillem is no longer a maintainer.
For the record, Ian has been removed from the dpkg group on Alioth and
we asked for an UNACCEPT of his upload, but I'm
On Sun, 09 Mar 2008, Raphael Hertzog wrote:
[2] Reformatting changes
Guillem has been engaging in a programme of reformatting and restyling
of dpkg's code.
I agree that it's necessarily a good idea to reformat the code but you
^
not
brought up
On Sun, 09 Mar 2008, Raphael Hertzog wrote:
On Sun, 09 Mar 2008, Ian Jackson wrote:
With this message I am unilaterally declaring myself a maintainer of
dpkg, and also declaring that Guillem is no longer a maintainer.
For the record, Ian has been removed from the dpkg group on Alioth
On Sun, 09 Mar 2008, Ian Jackson wrote:
Can you tell us in which situations we have #define NULL 0
as opposed to #define NULL (void*)0 ?
Some C libraries do this for the benefit of broken old programs which
use NULL when they mean an integer or character0. C99 says it's legal
for NULL to
On Sun, 09 Mar 2008, Joey Hess wrote:
William Pitcock wrote:
On Sun, 2008-03-09 at 20:38 +0100, Raphael Hertzog wrote:
And what is the problem exactly? The delay in patch integration?
If you'd look at submitting patches to dpkg from the perspective of any
recent patch submitter, I'd
On Mon, 10 Mar 2008, Thijs Kinkhorst wrote:
On Mon, March 10, 2008 09:24, Steve Langasek wrote:
If you're opening a ticket for a security problem which is publicly
known, e.g. if it's announced on the project web site, please open a
ticket in the Security queue. These issues will be visible
On Sun, 16 Mar 2008, Thijs Kinkhorst wrote:
On Sunday 16 March 2008 00:52, Adam D. Barratt wrote:
We're aware that the Developers Reference specifies that the latter
format should be used, but it is problematic as -0.1 sorts before +b1
and, as such, the NMU will not supersede any previous
On Sun, 03 Feb 2008, Raphael Hertzog wrote:
On Sat, 02 Feb 2008, Charles Plessy wrote:
Is there sombody working on WigPen? Is the format consensual enough
that it would be accepted in Debian?
I plan to work on it (but have not done anything yet except thinking about
it and following
On Tue, 18 Mar 2008, Andreas Tille wrote:
XCBS-UpstreamBTS
or something like that and experiment with this and see how it
might evolve?
I'm opposed to this as well. Homepage and Vcs-* were almost required and
provide the basic pointers about a package but the control file is not
a
Hi,
On Wed, 19 Mar 2008, Manoj Srivastava wrote:
I am beginning to come back from a deadline crunch on my day
job, and start paying attention to my Debian packages again; so
hopefully the state of SELinux in Debian will improve -- at least, I'll
try to be more reactive in the
On Thu, 20 Mar 2008, Oohara Yuuma wrote:
This is not needed:
- updating build-essential would update it for lenny/sid only
- only oldstable (sarge) has a dpkg version that doesn't support it
Thus fixing build-essential doesn't fix it for the only case where it's
broken, when building
Hello,
yesterday I merged all the work we did in the sourcev3 branch in the
master branch of dpkg. It means it will be in the next dpkg upload.
My last call for test[1] didn't lead to any feedback at all, which is a pity
given the length of the discussion we had about patch management. I'm
On Fri, 28 Mar 2008, Raphael Hertzog wrote:
My last call for test[1] didn't lead to any feedback at all, which is a pity
given the length of the discussion we had about patch management. I'm
pretty sure people are interested in the topic... and it's important to
make sure that the new code
On Sun, 30 Mar 2008, Mike Bird wrote:
On Sun March 30 2008 13:25:15 Joey Hess wrote:
dpkg in experimental supports triggers now
THANK YOU IAN for persisting with triggers despite the tedious delays by
blistering incompetents. And thanks Joey for the interesting use cases.
Ian has nothing
On Tue, 01 Apr 2008, Lionel Elie Mamane wrote:
On Tue, Apr 01, 2008 at 08:05:06AM +0300, Guillem Jover wrote:
As per policy 3.5 I'm bringing this up here. I'd like to add lzma to
dpkg's Pre-Depends, so that we can use lzma compressed packages
after lenny w/o having to add an lzma
Hi,
On Thu, 10 Apr 2008, Charles Plessy wrote:
I made an upload this afternoon that was silently dropped.
(
http://lists.alioth.debian.org/pipermail/debian-med-packaging/2008-April/001432.html
)
After randomly checking some debian-devel-changes emails, it seems that
the accepted
On Thu, 10 Apr 2008, Raphael Hertzog wrote:
So hold on or downgrade dpkg-dev to 1.14.16.6 for now.
Anthony Towns has applied a fix to dak and Format: 1.8 is accepted now.
He also resurrected the uploads which have been rejected due to this check
only.
Cheers,
--
Raphaël Hertzog
Le best-seller
Hello,
some packages require initial configuration of an external service.
The most common case is the creation of a dedicated database (relational
or LDAP). This is usually done in the postinst.
When the database is hosted on the same server, it means that the database
server needs to be
On Wed, 16 Apr 2008, Darren Salt wrote:
I'd rather that this just got left in debian/rules, where it belongs:
xine-lib, for example, needs more than just -O0 for disabling optimisations.
You can keep it there for special cases like this one.
But I disagree that debian/rules is necessarily the
On Thu, 17 Apr 2008, Adam D. Barratt wrote:
Will the devscripts in stable be updated to handle this? If so, when?
If not, why not?
(If you're looking for an answer from the maintainers of a package it's
probably safer to ask them directly rather than assuming they read every
post on
(reply-to set to debian-devel only)
On Fri, 25 Apr 2008, James Vega wrote:
On Thu, Apr 24, 2008 at 09:42:59PM +0200, Bas Wijnen wrote:
This DEP is available on the Debian Wiki[1].
The version must be the version of the last upload, plus +nmuX, where X is a
counter starting at 1.
The
On Tue, 29 Apr 2008, Adeodato Simó wrote:
I want a consistent versioning scheme, thus +nmuX for both native and
non-natives packages.
I'd be very unhappy about that. For one, I think using such suffix in a
field that forms part of users' everyday's life is, uhm, inappropriate
or
On Mon, 05 May 2008, Niko Tyni wrote:
On Mon, May 05, 2008 at 12:23:59PM +0200, Raphael Hertzog wrote:
On Mon, 05 May 2008, Niko Tyni wrote:
# perl -le 'eval use Locale::gettext; print got: $@ if $@; exit 0';
echo $?
perl: symbol lookup error: /usr/lib/perl5/auto/Locale/gettext
On Tue, 06 May 2008, Niko Tyni wrote:
I think making liblocale-gettext-perl Pre-Depend on ${perl:Depends}
would fix this particular issue, but I'm worried that it's not the
only one. The other two XS modules that debconf-i18n depends on,
libtext-iconv-perl and libtext-charwidth-perl,
On Wed, 07 May 2008, Niko Tyni wrote:
The only room for improvement that I can see here is to always set
PERL_DL_NONLAZY=1 when executing an eval statement. This sounds a bit
intrusive, but arguably anybody using an eval wants to catch any
exceptions immediately.
I'll bring this up on p5p;
On Thu, 08 May 2008, Niko Tyni wrote:
It's the scripts that are doing the eval that must set the environment
variable, isn't it? Or do you see a way to force this from the module
side?
It's precisely those modules that are doing the eval in the
Locale::gettext case, and the examples at
Hi,
On Sat, 10 May 2008, Joerg Jaspert wrote:
X-Debian: $TOOL
X-Debian-Package: $PACKAGE
[...]
As a starting point, and as one tool generating lots of mail to
maintainers, DAK is already generating both headers, other tools
hopefully follow soon.
The PTS now provides those
On Mon, 12 May 2008, Domenico Andreoli wrote:
Afaiui dehs *only* sends emails to [EMAIL PROTECTED],
and the question was whether the pts only adds the header to e-mails
generated by its own scripts or also to stuff received by mail. (I
have no idea whether this even a correct dichotomy)
On Mon, 12 May 2008, Neil Williams wrote:
On Sun, 2008-05-11 at 22:31 +0200, Joerg Jaspert wrote:
On 11382 March 1977, Neil Williams wrote:
Package: general
Severity: normal
User: [EMAIL PROTECTED]
In preparation for a pseudo-package, buildd.emdebian.org, I'm filing
Yes, as
Hello,
I just reassigned a bug to acpid and discovered how badly maintained it
is. Despite a new maintainer in january this year, the BTS still shows
many RC bugs and a bunch with patches.
Hopefully this mail will draw some attention to the problem and some
volunteers will step up to help
On Thu, 15 May 2008, Steve Langasek wrote:
2) Introduce a default-mta package (currently) depending on exim4. All
packages requiring a MTA should depend on default-mta |
mail-transport-agent.
This will have the extra advantage that we (and others like CDDs and
derived
distros)
[Breaking the thread on purpose to start a new one]
On Fri, 16 May 2008, Lucas Nussbaum wrote:
On 16/05/08 at 15:41 +0200, Miriam Ruiz wrote:
just reviewed by just one person, but then again, I seriously think
that it would have been quite difficult to discover that there was a
problem
On Fri, 16 May 2008, Joey Hess wrote:
Raphael Hertzog wrote:
To me this one proof more than even when VCS are used to maintain
packages, our source packages must clearly identify the Debian patches
that are applied.
You're insinuatiog that a VCS does not allow easily browsing
On Fri, 16 May 2008, Joey Hess wrote:
Coming up with a complex set of requirements that everyone has to follow
up front in their workflow[1] is not going to yeld the best results, and
I think that's my core reason for disliking Raphael's proposal. Now, if
you can come up with
On Sat, 17 May 2008, Joey Hess wrote:
Raphael Hertzog wrote:
On Fri, 16 May 2008, Joey Hess wrote:
Coming up with a complex set of requirements that everyone has to follow
up front in their workflow[1] is not going to yeld the best results, and
I think that's my core reason
On Sat, 17 May 2008, Lucas Nussbaum wrote:
On 16/05/08 at 17:54 +0200, Raphael Hertzog wrote:
In the general case, I do believe that the new source package format 3.0
(quilt) will help as all Debian specific changes will always end up in
debian/patches/.
If I understand things correctly
On Sat, 17 May 2008, Joey Hess wrote:
Lucas Nussbaum wrote:
At some point, we will need to find a way to decide which v3 format we
are going to choose in adddition to the v3 (native) format (with a GR?).
We can't afford to allow several different v3 formats to coexist.
The entire point
On Sun, 18 May 2008, Andreas Tille wrote:
On Fri, 16 May 2008, Raphael Hertzog wrote:
I totally agree that we need to make our changes more visible. In the
openssl case, the patch in question is inside the .diff.gz and you don't
notice it in the unpacked source package. I tend to give a look
Hi,
On Sat, 17 May 2008, Joey Hess wrote:
The state of a bug being a divergence can just be one step in the
life-cycle of a bug.
Consider a new bug filed one a package, which turns out to be an
upstream bug, is forwarded upstream, gets patched in Debian, and then
has the patch forwarded
On Sun, 18 May 2008, Russ Allbery wrote:
Ben Finney [EMAIL PROTECTED] writes:
Your mail message individually to me is not wanted, and I have a
reasonable expectation through the mailing list code of conduct *and*
through my explicit request that you not send it.
The solution to this
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 and
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 VCS comes
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
701 - 800 of 1749 matches
Mail list logo
