On 08/30/2015 03:44 AM, Kevin Kofler wrote:
Marcin Juszkiewicz wrote:
Ever heard of quilt? It even has handling of sane spec files built-in.
Sorry, but I'm opposed to requiring a specific tool to generate patches.
Patches are made in many ways in the real world: plain diff, svn diff, git
On 2015-08-28, 17:09 GMT, Marcin Juszkiewicz wrote:
You mean mass bug reporting for each package where spec file lacks
information about patches?
No, just for the package where you are bothered by the lack of
information. What I meant is that in the end all those tens of
thousands of patches
Marcin Juszkiewicz wrote:
I would say that it is a bit better. Now I at least know that it is
related to Python 2.5 (which we no longer ship)
It means the problem first showed up with 2.5, but chances are all later 2.x
(and maybe also 3.x) are affected too.
Kevin Kofler
--
devel
Michael Catanzaro wrote:
It works well in practice. It's not hard to write, and it more helpful
than the Fedora tradition of just adding a link to the upstream bug.
Maintainers in openSUSE understand that it is required.
To be honest, I don't see why we need to REQUIRE patch descriptions to
Marcin Juszkiewicz wrote:
Ever heard of quilt? It even has handling of sane spec files built-in.
Sorry, but I'm opposed to requiring a specific tool to generate patches.
Patches are made in many ways in the real world: plain diff, svn diff, git
diff, … Requiring a tool that forces a specific
Marcin Juszkiewicz mjuszkiew...@redhat.com wrote:
Are there any plans on adding/enforcing such requirements at least for new
patches?
Maintainers are not the only persons who work on their packages. Sometimes
some
random developers go though random packages for several reasons (fixing
W dniu 28.08.2015 o 14:32, Björn Persson pisze:
Marcin Juszkiewicz mjuszkiew...@redhat.com wrote:
Have you read the existent policy on this?
http://fedoraproject.org/wiki/Packaging:Guidelines#Patch_Guidelines
Yes, I have read it. But lot of maintainers did not.
Example specfile:
Source1:
Hi
I am building software for misc distributions for over 11 years. And so
far Fedora packages are the worst of those I played with (mostly
OpenEmbedded and Debian).
Why? Because patches are mess. Let's take random one:
@@ -108,7 +108,7 @@
M = int(max(r, g, b))
On 08/28/2015 02:11 PM, Marcin Juszkiewicz wrote:
Hi
I am building software for misc distributions for over 11 years. And so
far Fedora packages are the worst of those I played with (mostly
OpenEmbedded and Debian).
Why? Because patches are mess. Let's take random one:
@@ -108,7 +108,7
On Fri, Aug 28, 2015 at 8:44 AM, Florian Weimer fwei...@redhat.com wrote:
On 08/28/2015 02:11 PM, Marcin Juszkiewicz wrote:
Hi
I am building software for misc distributions for over 11 years. And so
far Fedora packages are the worst of those I played with (mostly
OpenEmbedded and
W dniu 28.08.2015 o 14:51, Neal Gompa pisze:
If patches are exported from Mercurial or Git, you'd have all the
information you'd want.
Fully agree. Only info about upstream status is missing.
However, most people I know aren't working from the hg/git
repository when making packages. That
W dniu 28.08.2015 o 14:44, Florian Weimer pisze:
On 08/28/2015 02:11 PM, Marcin Juszkiewicz wrote:
Who knows what it does and why? For some reason it has a name
'64bitfix' but why it is needed? Did upstream ever saw it? No
idea.
In reality, here's what the Debian version of this patch
Marcin Juszkiewicz wrote:
In Debian (or in OpenEmbedded) it is solved by implementing DEP-3 [1]
which is set of requirements about extra metadata in patches such as:
- Description or Subject (required)
- Origin (required except if Author is present)
- Bug-Vendor or Bug (optional)
-
On Fri, 2015-08-28 at 14:40 +0200, Kevin Kofler wrote:
I am opposed to any such scheme, because it means we could no longer
produce
our patches with diff without hand-editing them.
Such information, if needed, belongs into specfile comments.
Let's do that then. openSUSE already has
W dniu 28.08.2015 o 14:40, Kevin Kofler pisze:
Marcin Juszkiewicz wrote:
In Debian (or in OpenEmbedded) it is solved by implementing DEP-3 [1]
which is set of requirements about extra metadata in patches such as:
- Description or Subject (required)
- Origin (required except if Author is
On 2015-08-28, 13:01 GMT, Marcin Juszkiewicz wrote:
Yes, I have read it. But lot of maintainers did not.
Example specfile:
Source1:%{name}.score
Patch0: %{name}-0.7.1-userpmopts.patch
Patch1: %{name}-0.7.1-64bitfix.patch
Patch2:
W dniu 28.08.2015 o 18:02, Matěj Cepl pisze:
On 2015-08-28, 13:01 GMT, Marcin Juszkiewicz wrote:
Yes, I have read it. But lot of maintainers did not.
Example specfile:
Source1:%{name}.score
Patch0: %{name}-0.7.1-userpmopts.patch
Patch1: %{name}-0.7.1-64bitfix.patch
Marcin Juszkiewicz wrote:
W dniu 28.08.2015 o 14:32, Björn Persson pisze:
Marcin Juszkiewicz mjuszkiew...@redhat.com wrote:
Have you read the existent policy on this?
http://fedoraproject.org/wiki/Packaging:Guidelines#Patch_Guidelines
Yes, I have read it. But lot of maintainers did
18 matches
Mail list logo
