in form of fuzzed samples provided by the Google security
team, analyzing the crash and proposing and committing the fix with a
well-documenting commit message. All those patches are easily
identifiable by grepping for the string CC: libav-stable in git log
--grep.
It would be a really great help
John Dong escribió:
Can you clarify these two points? To my 2AM mind it reads as if the
It's because my 7AM mind needs some coffee :-)
let me rephrase it this way:
- if modification has already been done, stick to what the Debian
maintainer or Ubuntu is already doing. That mean use the existing
Thanks; that is much clearer! I agree with the general idea here. Any
specific patchsys we would like ubuntu devs to add in particular?
On Oct 7, 2009, at 2:13 AM, fabrice coutade...@gmail.com wrote:
John Dong escribió:
Can you clarify these two points? To my 2AM mind it reads as if the
On Wednesday 07 October 2009 08:13:36 fabrice wrote:
- if it's a Debian package and no previous modifications has been done,
modify directly the source, and do not introduce a patch system
If it is a small patch and it is applicaple in Debian+upstream, don't add a
patch system. But if the patch
that's a case-by-case decision:
Adding a patch system for a one-line change seems like overkill to me.
OTOH a patch system can help if you have several changes, which target
different bugs, because you can then split these in separate patches which
targetting one bug.
Cheers,
Stefan
On Wed, 07 Oct 2009 07:02:58 +0200 fabrice coutade...@gmail.com wrote:
Hi,
We were having a discussion yesterday on IRC about the sense of adding a
patch system to a package that don't have one when modifying the
upstream source code.
My understanding of the general rules is:
- if it's a Debian
fabrice coutade...@gmail.com writes:
let me rephrase it this way:
- if modification has already been done, stick to what the Debian
maintainer or Ubuntu is already doing. That mean use the existing patch
system, if any, or modify directly the source if some modifications has
already been
On Wed, 07 Oct 2009 10:40:53 +0200 Reinhard Tartler siret...@ubuntu.com
wrote:
- if it's an Ubuntu (-0ubuntuX) package and no previous modifications
has been done, adding a patch system is preferred
May I ask why?
Espc. since uploads are auto-imported these days into a bzr branch, and
Can you clarify these two points? To my 2AM mind it reads as if the
latter says Same rules except completely different rules :)
On Oct 7, 2009, at 1:02 AM, fabrice wrote:
- if it's a Debian package and no previous modifications has been
done,
modify directly the source, and do not
One other option for dealing with getting fixes back to Debian that I don't
recall seeing mentioned in this thread is to join a packaging team in Debian
relevant to an interest area and then just push relevant fixes into the team
VCS. I did that with Debian Python Modules Team myself just
On 18/06/08 at 13:34 -0500, Nicolas Valcarcel wrote:
On Wed, 2008-06-18 at 18:48 +0200, Lucas Nussbaum wrote:
On 18/06/08 at 10:12 -0500, Nicolas Valcarcel wrote:
Thanks for the examples, now i'm clearer on what you meant.
I also think this will we great, but to have a wiki page for
basically the same thing (it documents the changes in the patches, which
is not suitable if the changes are made directly in the source, without
using a patch system), but that policy doesn't seem to be in widespread
use, unfortunately.
I didn't knew about that page and i'm sure a lot
the same thing (it documents the changes in the patches, which
is not suitable if the changes are made directly in the source, without
using a patch system), but that policy doesn't seem to be in widespread
use, unfortunately.
I didn't knew about that page and i'm sure a lot of people
= -B $(shell dpkg-architecture -qDEB_BUILD_ARCH)
Everybody can see that you set ARCHFLAG (not ARCH_FLAG, btw). Why was
that necessary? Which problem is it fixing? Is Debian affected as well?
+ * debian/patches/03_missing_includes.dpatch: Added. Fixes FTBFS
Under which conditions does it FTBFS
://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines
about
basically the same thing (it documents the changes in the patches,
which
is not suitable if the changes are made directly in the source,
without
using a patch system), but that policy doesn't seem to be in
widespread
On Wed, 2008-06-18 at 01:25 -0700, Bryce Harrington wrote:
On Wed, Jun 18, 2008 at 09:44:56AM +0200, Lucas Nussbaum wrote:
For example, instead of:
+ * debian/control: add missing libxext-dev build-dependency (fixes FTBFS).
You could write:
+ * debian/control: add missing libxext-dev
as well?
+ * debian/patches/03_missing_includes.dpatch: Added. Fixes FTBFS
Under which conditions does it FTBFS? Is Debian affected as well, or
likely to become affected as well?
+ * Merge from debian unstable, remaining changes:
+- Use dpatch
+- debian/patches
On Wed, 2008-06-18 at 09:13 -0700, Jordan Mantha wrote:
This of course assumes the person writing the changelog entry actually
knows the answer to those questions. As you say, it requires a lot of
effort on the part of the DD. I think it probably takes at least the
same if not more effort on
On 18/06/08 at 10:12 -0500, Nicolas Valcarcel wrote:
Thanks for the examples, now i'm clearer on what you meant.
I also think this will we great, but to have a wiki page for every
package and to edit it with every change it's not the best to do IMHO.
On the other hand we can open a bug for
On 18/06/08 at 09:13 -0700, Jordan Mantha wrote:
On Wed, Jun 18, 2008 at 12:44 AM, Lucas Nussbaum
[EMAIL PROTECTED] wrote:
On 17/06/08 at 20:11 -0500, Nicolas Valcarcel wrote:
On Tue, Jun 17, 2008 at 5:52 AM, Lucas Nussbaum [EMAIL PROTECTED]
snip
Linking to bugs is a good thing, but many
On Wed, 2008-06-18 at 18:48 +0200, Lucas Nussbaum wrote:
On 18/06/08 at 10:12 -0500, Nicolas Valcarcel wrote:
Thanks for the examples, now i'm clearer on what you meant.
I also think this will we great, but to have a wiki page for every
package and to edit it with every change it's not
Lucas Nussbaum wrote:
I didn't mean that there should be one wiki page per package. Only that
there should be one wiki page (or one section on the same wiki page) for
each class of change. In the case of libext-dev, there was probably at
least 20 packages affected by that change, where the
On 18/06/08 at 21:22 +0200, Emilio Pozuelo Monfort wrote:
Lucas Nussbaum wrote:
I didn't mean that there should be one wiki page per package. Only that
there should be one wiki page (or one section on the same wiki page) for
each class of change. In the case of libext-dev, there was
the patches on patches.u.c
should not replace submitting patches to the BTS. Most Debian Developers
will probably only rarely have a look at the bugs in LP. If I hear
Ubuntu Developers saying but there was no need to report it to Debian,
you already should have known about it since there was a link on
PTS
to Debian. But those changes should not replace
submitting bugs to the Debian BTS, like the patches on patches.u.c
should not replace submitting patches to the BTS. Most Debian Developers
will probably only rarely have a look at the bugs in LP. If I hear
Ubuntu Developers saying but there was no need
On Tuesday 17 June 2008 21:11, Nicolas Valcarcel wrote:
Hi,
On Tue, Jun 17, 2008 at 5:52 AM, Lucas Nussbaum [EMAIL PROTECTED]
There's a wiki page on
https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines about
basically the same thing (it documents the changes in the patches
Assuming I have patched a package in universe to fix a bug, and have
also created a package for the bugfix, where is the best place to put
it to get someone to check and upload it?
REVU?
sponsors-queue?
Assuming you just want the .diff.gz, would you want to see the source
directly patched, or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeffrey Ratcliffe ha scritto:
For my information - for both cases:
1. in case of a new upstream version, where do I post the diff.gz?
2. otherwise, where do I post the debdiff?
You can file a new bug in Launchpad [1] or attach diff.gz/debdiff to
Hi,
Am Donnerstag, 7. Februar 2008 11:15 schrieb Luca Falavigna:
[..]
If changes you introduce touch files provided upstream, adopting a patch
system is advisable, no need of it if changes are limited to debian/
directory.
Just for clarification: If the package you touch comes from debian,
On 07/02/2008, Stefan Potyra [EMAIL PROTECTED] wrote:
Just for clarification: If the package you touch comes from debian, and there
is no patch system present in the debian version, please don't start to
introduce one. This will make future merges more easy (valid in both
directions).
So in
On 07/02/2008, Luca Falavigna [EMAIL PROTECTED] wrote:
You can file a new bug in Launchpad [1] or attach diff.gz/debdiff to
existing bug reports [2], if your patch fixes some of them.
[1] https://launchpad.net/ubuntu/+source/packagename/+filebug
[2]
to send patches along.
That way it is visible for everyone interested in the package, even if
they are not listed in the package responsible section (like,
Uploaders), and not get stuck and hidden in someone's private mailbox. :)
Isaac Clerencia wrote:
On Saturday, 5 May 2007, Emilio Pozuelo
would have expected out of courtsey
and getting changes pushed back upstream), but I thought I'd make you
aware of the issue in case this wrong approach is used in other MOTU
patches, too.
Just checking, but you do know about
http://packages.qa.debian.org/w/wesnoth.html - the section that says
in there, though, which I would have expected out of courtsey
and getting changes pushed back upstream), but I thought I'd make you
aware of the issue in case this wrong approach is used in other MOTU
patches, too.
Just checking, but you do know about
http://packages.qa.debian.org/w/wesnoth.html
since these patches often don't really apply to
Debian like in the case of spl: http://packages.qa.debian.org/s/spl.html
The person who does the changes in Ubuntu should propably pretty well
know if something would be helpful to Debian as well and push it back
to Debian in the sense
that you have to check if there are patches, but that Debian's
systems don't make this easier. Perhaps it would be good if they would
send a message to the maintainer when there's a new patch, or have a
general overview page where, amongst other information, all patches
are displayed.
Well, just my 5
* Sarah Hobbs [EMAIL PROTECTED] [2007-10-24 14:12:39 CEST]:
Sheesh. Was just a suggestion. It wasn't a You must do this, or
else. No need to start getting antagonistic at me.
Sheesh, sorry for have you hit on your wrong foot. It wasn't a I deny
to do so, so no need to get pouting at me. It
are team
maintained these days, or even just in the case of a handover of
packages, I would encourage to use the Debian BTS to send patches along.
That way it is visible for everyone interested in the package, even if
they are not listed in the package responsible section (like,
Uploaders
Gerfried Fuchs wrote:
Hi!
[going as Bcc to the MOTUs which are listed in the changelog of wesnoth
explicitly]
I just recently gone through the MOTU patches of wesnoth again, and
noticed one thing that looks pretty strange to me and one thing that is
just wrong and should get
, dead or
unresponsive ;-)
Of course, I can add these as patches against /dev/null, but that honestly
seems a bit awkward.
I don't think that's awkward - I've done it many times and patches from
debian/patches have the advantage that you can aggregate added files in
meaningful blocks
Is there a consensus on what to do when you are adding files to a package? I
am thinking for example on a situation where I am authoring a complete
autotools system to a software package, and upstream is, say, dead or
unresponsive ;-)
Of course, I can add these as patches against /dev/null
;-)
Of course, I can add these as patches against /dev/null, but that honestly
seems a bit awkward.
An alternative is to put the files in debian/ and let debian/rules move
them to their proper place in the directory tree.
What say you, oh MOTUs?
Cheers,
Morten aka mok0
One other alternative
segfault in libgtkmozembed.so
(IIRC). This was before applying the patches, though, so it is
possible that the segfault is gone now -- I'm out of time and
energy to check that.
Could someone verify that firefox-dev is a sufficient build-dependency?
I've posted the patches that Michael
Hello everybody,
in the final days before release, we should all make sure to check the
list of bugs with patches attached:
For Ubuntu this is a list of 630 bugs: http://tinyurl.com/rrk2j
For Universe it's a list of 157 bugs: http://tinyurl.com/mbk73
The same goes for a lot of bugs
44 matches
Mail list logo
