On Tue, Sep 06, 2011 at 03:27:15PM -0800, Jef Spaleta wrote:
On Tue, Sep 6, 2011 at 3:09 PM, Adam Williamson awill...@redhat.com wrote:
Well, yes, that parallel came up in my mind too, but really, the two
aren't particularly similar. I don't think there's any intent to
obfuscate in the
On Tue, Sep 6, 2011 at 7:27 PM, Jef Spaleta jspal...@gmail.com wrote:
As more projects become git based over time, the preferred form for code
development might actually be a bisectable git checkout
+100 -- some of the git primitives seem to be here to stay - a hash
identifying a commit or tree
On Wed, Sep 7, 2011 at 8:05 AM, Richard W.M. Jones rjo...@redhat.com wrote:
Wishlist item:
At the same time that RPM allows you to bundle a git repo, perhaps we
can finally get rid of %changelog?
I suspect that fedpkg is a better integration point. Between the
fedora patches branch discussed
On Wed, Sep 7, 2011 at 8:05 AM, Richard W.M. Jones rjo...@redhat.com wrote:
On Tue, Sep 06, 2011 at 03:27:15PM -0800, Jef Spaleta wrote:
On Tue, Sep 6, 2011 at 3:09 PM, Adam Williamson awill...@redhat.com wrote:
Well, yes, that parallel came up in my mind too, but really, the two
aren't
On 09/07/2011 09:57 AM, Josh Boyer wrote:
%changelog isn't for developers. It's for users to see what the
developers changed in the package.
Would a git-shortlog suffice for %changelog ? Assuming appropriate
comments are required for fedora's git repo.
--
devel mailing list
On Wed, Sep 7, 2011 at 12:32 PM, Genes MailLists li...@sapience.com wrote:
On 09/07/2011 09:57 AM, Josh Boyer wrote:
%changelog isn't for developers. It's for users to see what the
developers changed in the package.
Would a git-shortlog suffice for %changelog ? Assuming appropriate
On 09/07/2011 12:42 PM, Josh Boyer wrote:
Unless of course you meant have fedpkg automatically stick a
git-shortlog into the %changelog section of the spec file on commit
or something. Then.. maybe.
Yah I meant this one .. :-)
And yes, this assumes in all cases that developers are
Genes MailLists wrote:
Would a git-shortlog suffice for %changelog ?
It would need to be git-short-shortlog (hypothetically) as filling a
rpm changelog with hundreds of lines of commits is not very helpful.
I've always considered the rpm changelog to be a changelog of the spec
itself and a
On 09/07/2011 12:42 PM, Josh Boyer wrote:
On Wed, Sep 7, 2011 at 12:32 PM, Genes MailListsli...@sapience.com wrote:
On 09/07/2011 09:57 AM, Josh Boyer wrote:
%changelog isn't for developers. It's for users to see what the
developers changed in the package.
Would a git-shortlog
On 09/07/2011 11:12 AM, Michael Cronenworth wrote:
Genes MailLists wrote:
Would a git-shortlog suffice for %changelog ?
It would need to be git-short-shortlog (hypothetically) as filling a
rpm changelog with hundreds of lines of commits is not very helpful.
I've always considered the rpm
Rich Megginson on 09/07/2011 12:44 PM wrote:
git log --oneline TAG-OF-PREVIOUS-RELEASE.. | cat
the | cat (or | more) is needed because git log will truncate lines
This is not what I meant.
Upstream may have had 20-30 commits inbetween tags. I wouldn't want to
see 20-30 lines of RPM
On 09/07/2011 01:50 PM, Michael Cronenworth wrote:
Rich Megginson on 09/07/2011 12:44 PM wrote:
git log --oneline TAG-OF-PREVIOUS-RELEASE.. | cat
the | cat (or | more) is needed because git log will truncate lines
This is not what I meant.
Upstream may have had 20-30 commits inbetween
Genes MailLists on 09/07/2011 12:57 PM wrote:
Seems pretty useful for users to see what changed - curious why not?
Users are not programmers. Commits may range from merge from branch
such-n-such to ran indent to clean up formatting which has extremely
little value to users.
--
devel mailing
Am 07.09.2011 20:00, schrieb Michael Cronenworth:
Genes MailLists on 09/07/2011 12:57 PM wrote:
Seems pretty useful for users to see what changed - curious why not?
Users are not programmers. Commits may range from merge from branch
such-n-such to ran indent to clean up formatting which has
On Sat, 2011-09-03 at 20:56 +0200, Roberto Ragusa wrote:
On 09/03/2011 07:31 PM, Adam Williamson wrote:
To look at things at a higher level: it's clearly the goal of the
guidelines that any interested party (with sufficient basic knowledge)
who comes along and checks a Fedora package out
On Tue, Sep 6, 2011 at 3:09 PM, Adam Williamson awill...@redhat.com wrote:
Well, yes, that parallel came up in my mind too, but really, the two
aren't particularly similar. I don't think there's any intent to
obfuscate in the case of the glibc spec, it's simply done the way that
seemed
On Fri, Sep 02, 2011 at 10:28:19PM +0200, Jakub Jelinek wrote:
On Fri, Sep 02, 2011 at 01:20:19PM -0700, Adam Williamson wrote:
Is there a specific reason glibc does this?
Yes.
Can it not have a set of patches, one per change, as is usual practice?
Fedora glibc sources are from git,
Dne 3.9.2011 10:38, Richard W.M. Jones napsal(a):
https://rwmj.wordpress.com/2011/08/09/nice-rpm-git-patch-management-trick/
This method is quite probably simpler than the one you're using now.
I am in the process of pushing our less interesting Xorg patches
upstream, and I had a great
On Sat, Sep 03, 2011 at 09:38:46AM +0100, Richard W.M. Jones wrote:
Fedora glibc sources are from git, and the bit diff is just generated
diff between the upstream snapshot and corresponding Fedora snapshot,
sans a few Fedora-only directories (which are packaged as extra tarball).
That's
On Sat, 2011-09-03 at 13:43 +0200, Jakub Jelinek wrote:
On Sat, Sep 03, 2011 at 09:38:46AM +0100, Richard W.M. Jones wrote:
Fedora glibc sources are from git, and the bit diff is just generated
diff between the upstream snapshot and corresponding Fedora snapshot,
sans a few Fedora-only
On 09/03/2011 07:31 PM, Adam Williamson wrote:
To look at things at a higher level: it's clearly the goal of the
guidelines that any interested party (with sufficient basic knowledge)
who comes along and checks a Fedora package out of git should be able to
_understand it_, and this includes
On Wed, 2011-08-31 at 08:50 +0200, Andreas Schwab wrote:
Please wait until I am finished working on it. This is not a bug that
can be easily reproduced.
I note that this is fixed in -7: thanks. However, checking how it was
fixed was rather painful...
On Fri, Sep 02, 2011 at 01:20:19PM -0700, Adam Williamson wrote:
Is there a specific reason glibc does this?
Yes.
Can it not have a set of patches, one per change, as is usual practice?
Fedora glibc sources are from git, and the bit diff is just generated
diff between the upstream snapshot
On Fri, 2011-09-02 at 22:28 +0200, Jakub Jelinek wrote:
On Fri, Sep 02, 2011 at 01:20:19PM -0700, Adam Williamson wrote:
Is there a specific reason glibc does this?
Yes.
Can it not have a set of patches, one per change, as is usual practice?
Fedora glibc sources are from git, and the
On Fri, 2011-09-02 at 13:43 -0700, Adam Williamson wrote:
On Fri, 2011-09-02 at 22:28 +0200, Jakub Jelinek wrote:
On Fri, Sep 02, 2011 at 01:20:19PM -0700, Adam Williamson wrote:
Is there a specific reason glibc does this?
Yes.
Can it not have a set of patches, one per change, as
On Fri, 2011-09-02 at 22:28 +0200, Jakub Jelinek wrote:
On Fri, Sep 02, 2011 at 01:20:19PM -0700, Adam Williamson wrote:
Is there a specific reason glibc does this?
Yes.
Can it not have a set of patches, one per change, as is usual practice?
Fedora glibc sources are from git, and the
On Sep 2, 2011, at 3:39 PM, Simo Sorce wrote:
On Fri, 2011-09-02 at 22:28 +0200, Jakub Jelinek wrote:
On Fri, Sep 02, 2011 at 01:20:19PM -0700, Adam Williamson wrote:
Is there a specific reason glibc does this?
Yes.
Can it not have a set of patches, one per change, as is usual practice?
On Fri, 02 Sep 2011 23:02:04 +0200, Adam Williamson wrote:
about the 'fedora' branch of upstream glibc.
GDB uses a similar style for the merged patchsets in the Archer repository:
http://pkgs.fedoraproject.org/gitweb/?p=gdb.git;a=blob_plain;f=gdb-archer.patch;hb=f16
Given that this
On Sat, 2011-09-03 at 00:50 +0200, Jan Kratochvil wrote:
On Fri, 02 Sep 2011 23:02:04 +0200, Adam Williamson wrote:
about the 'fedora' branch of upstream glibc.
GDB uses a similar style for the merged patchsets in the Archer repository:
Adam Williamson awill...@redhat.com writes:
But I did mention all the various bug reports - Arch and upstream - in
my ML post on the topic: subject glibc causing crashes in most
anything that does DNS lookups in F16.
That is useless. Please always put such important information in the
bug
On Thu, Sep 01, 2011 at 09:34:10AM +0200, Andreas Schwab wrote:
Adam Williamson awill...@redhat.com writes:
But I did mention all the various bug reports - Arch and upstream - in
my ML post on the topic: subject glibc causing crashes in most
anything that does DNS lookups in F16.
That
Jakub Jelinek ja...@redhat.com writes:
It is also in bugzilla, just not in
https://bugzilla.redhat.com/show_bug.cgi?id=730856
but in https://bugzilla.redhat.com/show_bug.cgi?id=732857
which has been marked as duplicate of that.
There should have been a comment pointing out this important
On Thu, 2011-09-01 at 10:09 +0200, Andreas Schwab wrote:
Jakub Jelinek ja...@redhat.com writes:
It is also in bugzilla, just not in
https://bugzilla.redhat.com/show_bug.cgi?id=730856
but in https://bugzilla.redhat.com/show_bug.cgi?id=732857
which has been marked as duplicate of that.
On Thu, 2011-09-01 at 09:48 -0700, Adam Williamson wrote:
and I'm _not_ being paid to
maintain gedit.
Er...glibc. though I'm not paid to maintain gedit either. =)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
Please wait until I am finished working on it. This is not a bug that
can be easily reproduced.
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
And now for something completely different.
--
devel mailing list
On Wed, 2011-08-31 at 08:50 +0200, Andreas Schwab wrote:
Please wait until I am finished working on it. This is not a bug that
can be easily reproduced.
The Arch report claims a fully reliable reproducer:
https://bugs.archlinux.org/task/24615
I can 100% reliably reproduce it by creating an
Adam Williamson awill...@redhat.com writes:
On Wed, 2011-08-31 at 08:50 +0200, Andreas Schwab wrote:
Please wait until I am finished working on it. This is not a bug that
can be easily reproduced.
The Arch report claims a fully reliable reproducer:
https://bugs.archlinux.org/task/24615
2011-08-31 11:27 keltezéssel, Andreas Schwab írta:
Adam Williamson awill...@redhat.com writes:
On Wed, 2011-08-31 at 08:50 +0200, Andreas Schwab wrote:
Please wait until I am finished working on it. This is not a bug that
can be easily reproduced.
The Arch report claims a fully reliable
Zoltan Boszormenyi zbos...@freemail.hu writes:
The I can 100%... is not the first sentence of the comment
but it's all in there.
I'm taking about the redhat bug. How do I get to know about all this if
nobody tells me?
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8
On Wed, 31 Aug 2011 12:00:43 +0200
Andreas Schwab wrote:
Zoltan Boszormenyi zbos...@freemail.hu writes:
The I can 100%... is not the first sentence of the comment
but it's all in there.
I'm taking about the redhat bug. How do I get to know about all this
if nobody tells me?
Yep...
On Wed, 31 Aug 2011 12:11:54 +0200
Thomas Spura wrote:
On Wed, 31 Aug 2011 12:00:43 +0200
Andreas Schwab wrote:
Zoltan Boszormenyi zbos...@freemail.hu writes:
The I can 100%... is not the first sentence of the comment
but it's all in there.
I'm taking about the redhat bug.
Adam Williamson awill...@redhat.com writes:
The Arch report claims a fully reliable reproducer:
https://bugs.archlinux.org/task/24615
I can 100% reliably reproduce it by creating an iptables reject rule
for DNS packets:
# iptables -A OUTPUT -p udp --dport 53 -j REJECT --reject-with
Dne 31.8.2011 08:50, Andreas Schwab napsal(a):
Please wait until I am finished working on it. This is not a bug that
can be easily reproduced.
I don't have a good reproducer, but I believe this one
firefox -g
runENTER
{ and then run Firefox for couple of hours it fails }
is pretty certain
On Wed, 2011-08-31 at 11:27 +0200, Andreas Schwab wrote:
Adam Williamson awill...@redhat.com writes:
On Wed, 2011-08-31 at 08:50 +0200, Andreas Schwab wrote:
Please wait until I am finished working on it. This is not a bug that
can be easily reproduced.
The Arch report claims a fully
Adam Williamson wrote:
glibc maintainers / developers, if you don't want me to do this, please
start giving a crap about your bugs.
Speaking of critical glibc bugs, what about this one?
https://bugzilla.redhat.com/show_bug.cgi?id=733462
IMHO, that's also a blocker.
Kevin Kofler
--
On Wed, 2011-08-31 at 19:16 +0200, Kevin Kofler wrote:
Adam Williamson wrote:
glibc maintainers / developers, if you don't want me to do this, please
start giving a crap about your bugs.
Speaking of critical glibc bugs, what about this one?
Hey, it's been a quiet week so far...
I'm intending to update glibc for F16 using provenpackager privileges
tomorrow to fix https://bugzilla.redhat.com/show_bug.cgi?id=730856 using
the patch submitted upstream at
http://sourceware.org/bugzilla/show_bug.cgi?id=13013 , if the glibc
upstream
47 matches
Mail list logo
