[ Bcced to -devel and -dpkg, discussion should happen on -policy ]
Hello,
we have an unfortunate situation where the practice in dpkg-buildpackage
and the policy do not match fully.
I tried to summarize the problem here:
http://wiki.debian.org/Teams/Dpkg/DebianRules
I want to resolve this probl
On Mon, 09 Mar 2009, Jan Hauke Rahm wrote:
> On Mon, Mar 09, 2009 at 01:09:34AM -0700, Russ Allbery wrote:
> > If you're trying to recreate the tarball from a set of files, this doesn't
> > work as well, but that also has other problems (it doesn't give you a
> > reproducible tarball). I suspect t
On Mon, 09 Mar 2009, James Westby wrote:
> On Sun, 2009-03-08 at 17:11 +0100, Raphael Hertzog wrote:
> > There's nothing to specify here, dpkg-source uses all additional tarballs
> > that match the regexp (exactly like it identifies the .orig tarball
> > currentl
On Sun, 08 Mar 2009, Russ Allbery wrote:
> Raphael Hertzog writes:
>
> > In practice, there's one exception, the debian tarball can contain
> > binary files that are installed outside of the debian dir. Those are
> > necessary listed in debian/source/include_binarie
On Sun, 08 Mar 2009, James Westby wrote:
> * Building a 3.0 (native) package worked fine.
> * Building a 3.0 (quilt) package worked ok. There are two things that
> will need work here though:
> - If there are more tarballs required than .orig.tar.gz and
> .debian.tar.gz then it w
As requested I created a wiki page to track this project:
http://wiki.debian.org/Projects/DebSrc3.0
In the section "Validation of all tools with new source formats"
there's a list of apps to test with new source formats. Feel free to
complete the list with more apps to test and feel free to do the
On Fri, 06 Mar 2009, Michael Biebl wrote:
> I think the wiki page you mentioned with up-to-date information regarding this
> topic would really be a good idea.
Yeah, I've noted that and will set it up.
> >> Build-Depends, it would imho be useful if lintian issued a warning, that
> >> this
> >>
On Fri, 06 Mar 2009, Ben Finney wrote:
> Raphael Hertzog writes:
>
> > On Fri, 06 Mar 2009, Ben Finney wrote:
> > > More specifically, I'm not the one using Quilt *at all*. The patches
> > > are created from my VCS, stored in the ‘debian/patches/’ directo
On Fri, 06 Mar 2009, Ben Finney wrote:
> More specifically, I'm not the one using Quilt *at all*. The patches
> are created from my VCS, stored in the ‘debian/patches/’ directory
> separate from the upstream source, so there isn't anything for them to
> be applied to until the package gets built wi
On Fri, 06 Mar 2009, Ben Finney wrote:
> > Furthermore, I believe that consistency is important and that we're
> > better with all patches formatted in the same way. Quilt make it
> > easy to refresh any patch to the expected format with "quilt refresh
> > -p1" (or -pab).
>
> I'm a complete neophy
On Fri, 06 Mar 2009, Lucas Nussbaum wrote:
> > Did you also test if they produce the same content?
>
> Many packages don't produce the same content after each build, because
> of timestamps written in some files, for example. I could easily check
> that they provide the same binary packages accord
On Thu, 05 Mar 2009, Luk Claes wrote:
> > as announced earlier during the lenny dev cycle, I would like to switch to
> > the new source package formats ("3.0 (quilt)" and "3.0 (native)") during
> > the squeeze cycle so that we can benefit from the numerous improvements.
> > For this kind of importa
On Fri, 06 Mar 2009, Ben Finney wrote:
> > Note however that while dpkg-source parses correctly series files
> > with explicit options used for patch application (stored on each
> > line after the patch filename and one or more spaces), it does
> > ignore those options and always expect patches tha
On Fri, 06 Mar 2009, Michael Biebl wrote:
> Raphael Hertzog wrote:
> >
> > I will do (thanks to Lucas Nussbaum) another archive rebuild in the
> > upcoming weeks to see if we have new failures. Hopefully the release team
> > can grant the status of release goal to this
On Fri, 06 Mar 2009, Michael Biebl wrote:
> dpkg-gencontrol: warning: unknown information field 'Format' in input data in
> general section of control info file
>
> Should I file a bug against dpkg-dev for that?
>
> And another minor issue: vim doesn't know about the new Format field in
> debian/
Hello,
as announced earlier during the lenny dev cycle, I would like to switch to
the new source package formats ("3.0 (quilt)" and "3.0 (native)") during
the squeeze cycle so that we can benefit from the numerous improvements.
For this kind of important change, it's best to start early in the rel
On Tue, 03 Mar 2009, Guillem Jover wrote:
> On Tue, 2009-03-03 at 09:02:18 +0100, Raphael Hertzog wrote:
> > It's already there:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514316
> >
> > I would happily include such a file, though it probably needs some
On Mon, 02 Mar 2009, Steve Langasek wrote:
> On Mon, Mar 02, 2009 at 10:02:11PM -0500, Joey Hess wrote:
> >
> > Insert the typical winge here about dpkg conffile renaming code
> > being deployed via cut-n-paste from a wiki page instead of any
> > of our better technologies, such as a utility, with
Hi,
I plan to ask the removal of gnomeicu that neither Sebastien
or me are using. I saved it for lenny, but I don't think it's worth
keeping for Squeeze. Hence I will request its removal in a few days
unless someone pops up and adopts it.
http://gnomeicu.sourceforge.net
http://sourceforge.net/mai
On Sun, 01 Mar 2009, Steve Langasek wrote:
> > shlibs.local was initially a poor solution for a less than ideal
> > dpkg-shlibdeps that couldn't cope with shlibs just produced by the
> > packages being built.
>
> Are you sure this was the reason? shlibs.local support was added to
> dpkg-shlibdeps
On Sat, 28 Feb 2009, Loïc Minier wrote:
> I had a case recently where this wasn't too convenient with the ffmpeg
> package: it depends on a bunch of libs split in their own packages in
> the same source. The goal was to have a =binary:Version dep for ffmpeg
> on these libs, and use a relaxed v
On Sat, 28 Feb 2009, Julien BLACHE wrote:
> Raphael Hertzog wrote:
>
> Hi,
>
> >> debian/shlibs.local should help for that.
> >
> > Except symbols files have priority over shlibs and there's no
> > symbols.local.
>
> I sense a lac
On Sat, 28 Feb 2009, Julien BLACHE wrote:
> Sam Hartman wrote:
> > I probably could hack something that would work: use symbols files
> > that point at the split library packages internally and just before
> > the debs are constructed run a sed script on symbols and shlibs.
>
> debian/shlibs.loca
On Fri, 27 Feb 2009, Joerg Jaspert wrote:
> Like the other poster, cli is very confusing. If we have enough
> packages (get me a list/matches :) ), im not against a section for it,
> but cli wouldnt be my favorite name for it.
I would suggest "c-sharp" for the section.
Cheers,
--
Raphaël Hertzog
On Wed, 18 Feb 2009, Iulian Udrea wrote:
> 2009/2/18 Marc Singer
> > Is your package patch available so I can review it?
> >
> > Also, it doesn't look like you're a DD. Why are you so keen to
> > maintain it?
*shrug*
Have you never been excited about being able to contribute to
Debian? (I foun
On Tue, 17 Feb 2009, Josselin Mouette wrote:
> Le mardi 17 février 2009 à 13:03 +0100, Julien Cristau a écrit :
> > dpkg-source -b, for one. You can't put a symlink in the diff.gz.
>
> Is that still a problem with the quilt source package format?
No. (But I don't like the idea of having debian/r
On Mon, 16 Feb 2009, Kari Pahula wrote:
> Currently, Debian Policy doesn't match with the current practice in
> section 7.7.
>
> > The Build-Depends-Indep and Build-Conflicts-Indep fields must be
> > satisfied when any of the following targets is invoked: build,
> > build-indep, binary and binary-
On Fri, 30 Jan 2009, Adam D. Barratt wrote:
> I'd guess Charles meant the following addition to
> README.feature-removal-schedule, from the dpkg source package:
>
> What: substvars support in dpkg-source and dpkg-genchanges
> Status: deprecated
> When: lenny+1
> Warning: program
> Why:
> substvar
On Mon, 26 Jan 2009, Stefano Zacchiroli wrote:
> On Mon, Jan 26, 2009 at 09:59:04AM +0100, Lucas Nussbaum wrote:
> > The goals of "nocheck" are different, and more useful, are bypassing
> > the test suite allows faster builds in all cases.
>
> The goals of Build-Depends-Test are the same of "noche
On Tue, 20 Jan 2009, Peter Palfrader wrote:
> On Tue, 20 Jan 2009, Stefano Zacchiroli wrote:
>
> > A question on this: would the BTS re-read the fixed changelog in
> > future uploads to update the version graph anyhow, or will it do that
> > only if the .changes file will contain all relevant entr
On Sat, 17 Jan 2009, Sandro Tosi wrote:
> In recent bts-link runs, we noticed some errors. The log is available
> at [2]: please take the time to give it a look, search for your
> packages and check the situation. There are errors in that log that
> might be ok, but others can refer to broken links
On Wed, 07 Jan 2009, Joerg Jaspert wrote:
>
> > I don't remember using sections in over 4 years of Debian usage, though
> > I had already used GNU/Linux for a few months before I switched to
> > Debian. But I doubt even a user new to GNU/Linux would use them much.
>
> Everyone that uses a tool li
On Sun, 28 Dec 2008, Steve Langasek wrote:
> Therefore I think it's neither necessary nor appropriate for libpam-modules
> to avoid a pre-dependency on debconf.
>
> Is it ok to make libpam-modules Pre-Depends: debconf (>= 0.5) | debconf-2.0
> for lenny?
I think so. We already have many predepende
On Mon, 29 Dec 2008, Anthony Towns wrote:
> Anyway, given the last proposal I made [0] went nowhere, unless people
> want to come up with their own proposals, or want to second the above as
> a draft proposal to be improved and voted on, I suspect nothing much will
> change, and we'll have this dis
On Fri, 19 Dec 2008, Josselin Mouette wrote:
> Le vendredi 19 décembre 2008 à 11:39 -0200, Martin Langhoff a écrit :
> > The mission of Debian is not "spot the bigot". Debian embraces people
> > of many beliefs, customs and ways of life under one shared belief --
> > about an OS.
>
> Precisely. An
Hello,
it's been a long time since I have been able to send out the last issue of
"Misc devel news". I would like all developers to (regularly) make the
effort to share some words about the cool stuff they are doing or are
planning to do so that we can have something at least twice a month or so.
On Sun, 23 Nov 2008, Federico Di Gregorio wrote:
> Il giorno dom, 23/11/2008 alle 17.32 +, Steve Kemp ha scritto:
> > On Sun Nov 23, 2008 at 17:59:13 +0100, Josselin Mouette wrote:
> >
> > > - Send your private Debian GPG Key to [EMAIL PROTECTED] Include
> > >the brand of your perfume and
On Tue, 18 Nov 2008, Samuel Thibault wrote:
> > Loadlin-packager: CCed you, as you want to stop building the byhand
> > component.
>
> Well loadlin should at least be kept on the installation CDs. And to my
> knowledge the CD image build system fetches it from ftp mirrors...
Indeed, at least the
On Tue, 21 Oct 2008, Thomas Bushnell BSG wrote:
> On Tue, 2008-10-21 at 20:24 +0200, Pierre Habouzit wrote:
> > On Tue, Oct 21, 2008 at 05:52:28PM +, Manoj Srivastava wrote:
> > > This is the part I am not comfortable with. I do not think the
> > > delegates have the powers to decide w
On Thu, 02 Oct 2008, Adeodato Simó wrote:
> > - Forwarded message from Ole Marggraf <[EMAIL PROTECTED]> -
>
> > On rebooting, this leaves the
> > system in a very ugly state if the user does not know that all he
> > needs to do is to move the new /etc/init.d/udev.dkpg-new to
> > /etc/init.
On Mon, 29 Sep 2008, Cyril Brulebois wrote:
> Norbert Preining <[EMAIL PROTECTED]> (29/09/2008):
> > > I am using debian-people for distributing packages for testing and
> > > backport reasons, and up to now (before the move) I could dput them
> > > from there. But ravel does not have dput installe
retitle 489132 upgrade apt/aptitude first
thanks
On Wed, 17 Sep 2008, Sven Joachim wrote:
> Is it still correct that dpkg needs to be upgraded first before doing a
> dist-upgrade from Etch? With perl-base 5.10.0-14 pre-depending on a
> fixed version of dpkg, that should not be the case anymore, A
On Fri, 12 Sep 2008, Josselin Mouette wrote:
> Le vendredi 12 septembre 2008 à 10:00 +0200, Raphael Hertzog a écrit :
> > IMO a solution that install modules manually (i.e. without dpkg) is not
> > acceptable.
>
> Why? I think this is the only sane way to go for drivers
Hi,
On Thu, 11 Sep 2008, David Paleino wrote:
> Hello *,
> some time ago I filed a RFS [1] for DKMS [2], and Daniel Baumann
> asked
> me what advantages it had over module-assistant.
> After some talking with upstream, here I have the answer.
If you decided to package it, you must have had your
On Thu, 11 Sep 2008, David Paleino wrote:
> On Thu, 11 Sep 2008 19:50:35 +0200, David Paleino wrote:
>
> > On Thu, 11 Sep 2008 19:43:39 +0200, Josselin Mouette wrote:
> > > You’d run into the same issue as module-assistant has: a package being
> > > installed cannot launch installation of other pa
On Mon, 08 Sep 2008, Paul Wise wrote:
> On Mon, Sep 8, 2008 at 4:12 AM, Franklin PIAT <[EMAIL PROTECTED]> wrote:
>
> > and a sponsor for some space on alioth?
>
> That should not be nessecary, you can create a login and register a
> project (which is then manually approved) without being a DD.
P
On Wed, 27 Aug 2008, Ian Jackson wrote:
> I'm hoping to shortly turn on the automatic bug filing mechanism.
> I'm writing now to give people a chance to object :-).
[...]
> very few other packages. Most autopkgtest reports are FTBFS problems.
I object filing FTBFS automatically. In some cases, th
On Tue, 22 Jul 2008, Christoph Haas wrote:
> - Propose a new optional debian/control field "X-Screenshot:" pointing to
> an URL serving an image file (PNG, JPG)
> [debian-devel-announce as soon as we are ready?]
You don't need/want such a field. It serves no practical purpose. There's
no reaso
On Sun, 20 Jul 2008, Michael Tautschnig wrote:
> I just added a symbols control file to the latest upload of the diagnostics
> library. I started out with a single libdiagnostics0.symbols file, which
> caused
> an FTBFS on all archs [0]. So we all know that C++ name mangling has its
> downsides, b
On Sun, 13 Jul 2008, Andreas Tille wrote:
> Sure, that's why I issued this provocation to "trigger" something I
> could listen to. The only other information about triggers on this list
> was a flamewar which circled basically around formatting of dpkg code
> issues. Did I missed some announcemen
On Tue, 08 Jul 2008, Charles Plessy wrote:
> The more we signal to non-biologists that the package is not for them,
> the less we can tell biologists what it does. Couldn't we rely on
> Debtags to indicate the field of the package to our users?
No. Debtags is meant for searching, it's not meant to
On Sun, 06 Jul 2008, Iñaki Baz Castillo wrote:
> > Note that /etc/init.d/skeleton, on which many init scripts in Debian are
> > based, handles this case correctly without using --oknodo.
>
> Are you sure? These are the "start" and "stop" sections of skeleton
> file in a Debian Etch:
No those are
(some of the answers/facts have already been given, but I reply anyway to
also give my personal opinion)
On Sat, 05 Jul 2008, Jay Berkenbilt wrote:
> * I like to have an exact copy of the downloaded source tarball with
>the same md5 checksum, gpg detached signature, etc. Using the
That shou
On Sat, 05 Jul 2008, Marc Haber wrote:
> On Sat, Jul 05, 2008 at 10:58:35AM +0200, Raphael Hertzog wrote:
> > THanks, I could come up with a transition plan myself if needed. But
> > compare your suggestions with: "someone goes over all init scripts, file
> > bugs
On Fri, 04 Jul 2008, Vincent Danjean wrote:
> Steve Langasek wrote:
> >> I'm reluctant to change the default behaviour of start-stop-daemon at this
> >> point. What do other people think of making --oknodo the default behaviour
> >> and adding a new option to force the current default behaviour (ex
On Fri, 04 Jul 2008, Iñaki Baz Castillo wrote:
> # lighttpd running:
> ~# /etc/init.d/lighttpd start ; echo $?
> * Starting web server lighttpd
> [fail]
> 1
[...]
> > Iñaki, if you ever encounter
> > bad init scripts, please report bugs against the offending packages.
>
> In the above case which
Reply-To:
In-Reply-To: <[EMAIL PROTECTED]>
reassign 426877 debian-policy 3.8.0.1
retitle 426877 Clarify what "sensible behaviour" is for init scripts
thanks
Ok, this confirms my initial feeling. Changing this in dpkg would require
a wide-scale testing and much effort for little gains since the p
On Fri, 04 Jul 2008, Ben Finney wrote:
> [Followup on debian-devel, instead of debian-devel-announce. Raphael,
> did you intentionally set Mail-Followup-To to debian-devel-announce or
> was that an oversight?]
Well, mutt adds it automatically as I have it configured to recognize all
debian-* as ma
On Thu, 03 Jul 2008, Ian Jackson wrote:
> Here is a summary of the problem:
FWIW, the summary is right according to my understanding.
> * This problem is clearly release critical. I don't think documenting
> a release critical bug of this severity in the release notes is
> acceptable. Furth
On Thu, 03 Jul 2008, Bryan Donlan wrote:
> On Thu, Jul 3, 2008 at 6:25 AM, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> > Package: release-notes
> > Severity: important
> >
> > To work-around a problem that can happen in the perl 5.10 upgrade (see
> > #4797
(Cc -devel to seek input)
On Thu, 31 May 2007, Iñaki Baz Castillo wrote:
> Acording to the LSB specifications for init scripts [1]:
>
> "For all other init-script actions, the init script shall return an exit
> status of zero if the action was successful. Otherwise, the exit status
> shall be non
Package: release-notes
Severity: important
To work-around a problem that can happen in the perl 5.10 upgrade (see
#479711), the perl scripts contained in dpkg (update-alternatives,
dpkg-divert) have been modified... but for the work-around to be used, the
new dpkg must obviously be installed first
On Wed, 25 Jun 2008, Mathieu Malaterre wrote:
> On Wed, Jun 25, 2008 at 8:28 AM, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> > On Tue, 24 Jun 2008, Steve Langasek wrote:
> >> Joey Hess has done some work to allow debhelper to handle the case of files
> >> und
On Wed, 25 Jun 2008, Robert Collins wrote:
> On Tue, 2008-06-24 at 18:05 -0700, Steve Langasek wrote:
> > On Wed, Jun 25, 2008 at 02:00:17AM +0200, Rafael Laboissiere wrote:
> >
> > > It is okay to have the debian directory in your tarball but, if you go
> > > down
> > > this road, it will be des
On Tue, 24 Jun 2008, Steve Langasek wrote:
> Joey Hess has done some work to allow debhelper to handle the case of files
> under debian/ that should be ignored (since they can't be deleted as part of
> a diff); I'm afraid I don't know the current state of this work and haven't
> heard of it being m
On Tue, 24 Jun 2008, Steve Langasek wrote:
> On Tue, Jun 24, 2008 at 05:58:11PM +0200, Thomas Hood wrote:
> > On 15 June the resolvconf package was removed from testing due to an RC bug.
>
> > A fixed version of the package has been uploaded and is now in unstable.
>
> > I would like to request t
On Mon, 23 Jun 2008, Russ Allbery wrote:
> > I've found no similar text for run-time relationships.
> >
> > Should the policy be updated on this?
>
> It probably should if all of the software or at least most (plus all of
> the package installation software) supports them properly. Does it?
No.
On Fri, 13 Jun 2008, Andreas Tille wrote:
> On Fri, 13 Jun 2008, Sandro Tosi wrote:
>
>>> I'll proceed in the following way for debian/control: rename
>>> cl-hunchentoot to hunchentoot and then create the transitional binary
>>> package cl-hunchentoot which depends on hunchentoot.
>>>
>>> Is this O
Hi,
On Thu, 05 Jun 2008, Lucas Nussbaum wrote:
> - I'd like to send an email to people subscribed to packages on the
> PTS (summary keyword). If you are maintaining packages in Debian,
> you will only receive one email, with the info for the packages you
> maintain and those you are subscrib
On Tue, 03 Jun 2008, Thibaut Paumard wrote:
> Le 3 juin 08 à 08:45, Raphael Hertzog a écrit :
>> Hello,
>>
>> please see the attached message. The Debian Gnome team needs help to
>> properly maintain the update-manager/update-notifier packages.
>
> I'm giving
-manager.html
http://packages.qa.debian.org/u/update-notifier.html
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
--- Begin Message ---
Hey,
On Mon, 2008-06-02 at 16:33 +0200, Raphael Hertzog wrote:
> Josselin told t
On Fri, 30 May 2008, Joerg Jaspert wrote:
> On 11401 March 1977, Raphael Hertzog wrote:
>
> >> Some time after this mail we will give a few tasks to those who
> >> volunteer to test their ability and then (maybe) have a few new members
> >> in our team in the no
On Fri, 30 May 2008, Joerg Jaspert wrote:
> Some time after this mail we will give a few tasks to those who
> volunteer to test their ability and then (maybe) have a few new members
> in our team in the not too distant future.
I would suggest that developing a patch for
http://bugs.debian.org/cgi-
On Sun, 25 May 2008, Mark Brown wrote:
> On Sun, May 25, 2008 at 01:07:56PM +0100, Neil Williams wrote:
>
> > So I am running the relevant autotools at build time but I still get the
> > warning.
>
> If you run autotools at build time you should also ensure that the
> changes which autotools make
On Thu, 22 May 2008, Martín Ferrari wrote:
> Upstream-Bug-Browser:
> http://rt.cpan.org/Public/Dist/Display.html?Name=WWW-Curl
> Upstream-Bug-Submitter:
> http://rt.cpan.org/Public/Bug/Report.html?Queue=WWW-Curl
>
> Which were furiously rejected by many people, in the usual and
> friendly tone c
On Wed, 21 May 2008, Andreas Tille wrote:
> Hmmm, do you regard it as realistic that all maintainers will change to
> a new format in Lenny+1? I do not think of maintainers who are in principle
> not happy about this format but those who maintain packages that might stay
> untouched perfectly fine
On Wed, 21 May 2008, Andreas Tille wrote:
> Subject: Please provide an option to list patches outside debian directory
>
> Please add a --verbose/-v option to 'dpkg-source -x' that performs
>
> lsdiff -z -x '*/debian/*' *.diff.gz
>
> to point potential maintainers / bug fixers to patches
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
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
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
> >>
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
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
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 forward
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/patche
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 s
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
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
> >
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 protocols/inte
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 VC
[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
> > probl
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
> >
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 maintai
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 fili
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 dichot
On Sun, 11 May 2008, Thijs Kinkhorst wrote:
> On Sunday 11 May 2008 15:07, Raphael Hertzog wrote:
> > The PTS add those headers to all mails that it forwards. So there's no
> > need to change anything to scripts that only send mails through the PTS.
>
> How would the
On Sun, 11 May 2008, Andreas Metzler wrote:
> >> Just want to know if I have to make dehs add those headers.
>
> > "have to" sounds like it's a great ordeal ;-) But yes, please.
>
> Afaiui dehs *only* sends emails to [EMAIL PROTECTED],
> and the question was whether the pts only adds the header t
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 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 examp
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
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-charwi
801 - 900 of 1357 matches
Mail list logo
