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"
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 maili
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 in
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 changel
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
On 09/07/2011 12:42 PM, Josh Boyer wrote:
> On Wed, Sep 7, 2011 at 12:32 PM, Genes MailLists 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 su
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:
>
>
> 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 develo
On Wed, Sep 7, 2011 at 12:32 PM, Genes MailLists 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
> comments
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
devel@l
On Wed, Sep 7, 2011 at 8:05 AM, Richard W.M. Jones 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 wrote:
>>
>> > Well, yes, that parallel came up in my mind too, but really, the two
>> > aren't particularly similar. I don't
On Wed, Sep 7, 2011 at 8:05 AM, Richard W.M. Jones 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 in my other
On Tue, Sep 6, 2011 at 7:27 PM, Jef Spaleta 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 as the key ident
On Tue, Sep 06, 2011 at 03:27:15PM -0800, Jef Spaleta wrote:
> On Tue, Sep 6, 2011 at 3:09 PM, Adam Williamson 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 gl
On Tue, Sep 6, 2011 at 3:09 PM, Adam Williamson 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 convenient to its main
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 packa
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 include
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 Fedo
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).
>
>
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 expe
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 fr
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:
>
> http://pkgs.fedoraproject.org/gitweb/?p=
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 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 usu
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,
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 p
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,
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 a
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...
http://pkgs.fedoraproject.org/gitweb/?p=g
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
http://www.happyassassi
On Thu, 2011-09-01 at 10:09 +0200, Andreas Schwab wrote:
> Jakub Jelinek 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.
>
> Ther
Jakub Jelinek 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 information
by t
On Thu, Sep 01, 2011 at 09:34:10AM +0200, Andreas Schwab wrote:
> Adam Williamson 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 usele
Adam Williamson 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 report, so that i
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?
> https://bugzilla.redhat.com/show_bug.cgi?
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
--
d
On Wed, 2011-08-31 at 11:27 +0200, Andreas Schwab wrote:
> Adam Williamson 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 relia
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
run
{ and then run Firefox for couple of hours it fails }
is pretty certain way h
Adam Williamson 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
> icmp-admin-prohib
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 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
On Wed, 31 Aug 2011 12:00:43 +0200
Andreas Schwab wrote:
> Zoltan Boszormenyi 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...
If this wo
Zoltan Boszormenyi 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 DBE3 3813 BB5D
2011-08-31 11:27 keltezéssel, Andreas Schwab írta:
> Adam Williamson 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:
Adam Williamson 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
>
> "I can 10
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
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
devel@lists
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 develope
47 matches
Mail list logo
