Re: Another glibc change that nearly got pushed into F16
On 10/26/11 12:32 PM, Jared K. Smith wrote: On Wed, Oct 26, 2011 at 11:47 AM, Richard W.M. Jonesrjo...@redhat.com wrote: https://fedorahosted.org/fesco/ticket/682 I've made another attempt to reach out the the glibc maintainer directly again this morning to hopefully answer the questions in that ticket as soon as possible, and remind him of the seriousness of the situation. I'll update the ticket if I hear anything. So, how's that coming along? - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another glibc change that nearly got pushed into F16
I forgot to add that it's probably a good idea to recompile any package that was compiled against the -13 glibc package. Strictly speaking, any package that uses a function that is defined with __THROW or __NTH in the glibc header files, but it's probably easier to compile every package. Is there a Koji query to get a list of such packages? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another glibc change that nearly got pushed into F16
On 10/26/2011 10:45 AM, Richard W.M. Jones wrote: I forgot to add that it's probably a good idea to recompile any package that was compiled against the -13 glibc package. Strictly speaking, any package that uses a function that is defined with __THROW or __NTH in the glibc header files, but it's probably easier to compile every package. Is there a Koji query to get a list of such packages? which means delay f16, create a stable glibc, test it, then make a massrebuild and test again the result... -- Levente Si vis pacem para bellum! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another glibc change that nearly got pushed into F16
On Wed, 2011-10-26 at 10:48 +0200, Farkas Levente wrote: On 10/26/2011 10:45 AM, Richard W.M. Jones wrote: I forgot to add that it's probably a good idea to recompile any package that was compiled against the -13 glibc package. Strictly speaking, any package that uses a function that is defined with __THROW or __NTH in the glibc header files, but it's probably easier to compile every package. Is there a Koji query to get a list of such packages? which means delay f16, create a stable glibc, test it, then make a massrebuild and test again the result... Richard, could you please open a FESCo ticket with as much information as you have on this issue? This is something we need to track closely, I think. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another glibc change that nearly got pushed into F16
Richard W.M. Jones rjo...@redhat.com writes: I forgot to add that it's probably a good idea to recompile any package that was compiled against the -13 glibc package. BTW, if this is the case, why is 2.14.90-13 still in rawhide? Shouldn't we assume that every build done recently in rawhide is tainted? I've spent the past couple of days trying to rebuild every libpng-using Fedora package using mock's fedora-rawhide-x86_64 environment. A distressingly large fraction of them FTBFS with /usr/include/glib-2.0/glib/gmacros.h:32:2: error: #error Only glib.h can be included directly. or close variants of that. I assume this is another manifestation of the same bug being discussed here ... or have the glibc guys managed to break the world in two different ways in the same release? regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another glibc change that nearly got pushed into F16
On Wed, Oct 26, 2011 at 10:06:31AM -0400, Tom Lane wrote: /usr/include/glib-2.0/glib/gmacros.h:32:2: error: #error Only glib.h can be included directly. or close variants of that. I assume this is another manifestation of the same bug being discussed here ... or have the glibc guys managed to break the world in two different ways in the same release? You are confusing glibc with glib here, the above very much looks like a glib bug, nothing to do with glibc. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another glibc change that nearly got pushed into F16
On Wed, 2011-10-26 at 16:12 +0200, Jakub Jelinek wrote: On Wed, Oct 26, 2011 at 10:06:31AM -0400, Tom Lane wrote: /usr/include/glib-2.0/glib/gmacros.h:32:2: error: #error Only glib.h can be included directly. or close variants of that. I assume this is another manifestation of the same bug being discussed here ... or have the glibc guys managed to break the world in two different ways in the same release? You are confusing glibc with glib here, the above very much looks like a glib bug, nothing to do with glibc. Its not a bug, just a change. Including individual glib headers has been discouraged for a long time. In GLib 2.31, it has been outlawed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another glibc change that nearly got pushed into F16
Matthias Clasen mcla...@redhat.com writes: On Wed, 2011-10-26 at 16:12 +0200, Jakub Jelinek wrote: On Wed, Oct 26, 2011 at 10:06:31AM -0400, Tom Lane wrote: /usr/include/glib-2.0/glib/gmacros.h:32:2: error: #error Only glib.h can be included directly. You are confusing glibc with glib here, the above very much looks like a glib bug, nothing to do with glibc. I stand corrected ... too early in the morning ... Its not a bug, just a change. Including individual glib headers has been discouraged for a long time. In GLib 2.31, it has been outlawed. Hmm. You'd better start filing FTBFS reports against your dependent packages, then, so they don't get blindsided by this. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another glibc change that nearly got pushed into F16
On Wed, Oct 26, 2011 at 09:30:21AM -0400, Stephen Gallagher wrote: On Wed, 2011-10-26 at 10:48 +0200, Farkas Levente wrote: On 10/26/2011 10:45 AM, Richard W.M. Jones wrote: I forgot to add that it's probably a good idea to recompile any package that was compiled against the -13 glibc package. Strictly speaking, any package that uses a function that is defined with __THROW or __NTH in the glibc header files, but it's probably easier to compile every package. Is there a Koji query to get a list of such packages? which means delay f16, create a stable glibc, test it, then make a massrebuild and test again the result... Richard, could you please open a FESCo ticket with as much information as you have on this issue? This is something we need to track closely, I think. https://fedorahosted.org/fesco/ticket/682 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another glibc change that nearly got pushed into F16
On Wed, Oct 26, 2011 at 11:47 AM, Richard W.M. Jones rjo...@redhat.com wrote: https://fedorahosted.org/fesco/ticket/682 I've made another attempt to reach out the the glibc maintainer directly again this morning to hopefully answer the questions in that ticket as soon as possible, and remind him of the seriousness of the situation. I'll update the ticket if I hear anything. -- Jared Smith Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Another glibc change that nearly got pushed into F16
It's rather too complex to explain the change here, so I suggest you go and read these first: http://permalink.gmane.org/gmane.comp.version-control.git/184205 http://permalink.gmane.org/gmane.comp.version-control.git/184209 https://bugzilla.redhat.com/show_bug.cgi?id=747377#c22 https://bugzilla.redhat.com/show_bug.cgi?id=747377#c24 Now, I'm _not_ saying that the glibc change is wrong. In fact, it enables extra gcc optimizations, which is great. But in this case it looks like we're going to have to review all use of thread mutexes in the whole of Fedora. Maybe not the kind of thing we had in mind for Fedora 16 at this point. I think it's great that Thomas Rast, Jim Meyering, and Jakub Jelinek found the problem after probably a couple of man-days of effort, but really development and bug fixing like this belongs in Rawhide. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another glibc change that nearly got pushed into F16
On Tue, 2011-10-25 at 18:54 +0100, Richard W.M. Jones wrote: It's rather too complex to explain the change here, so I suggest you go and read these first: http://permalink.gmane.org/gmane.comp.version-control.git/184205 http://permalink.gmane.org/gmane.comp.version-control.git/184209 https://bugzilla.redhat.com/show_bug.cgi?id=747377#c22 https://bugzilla.redhat.com/show_bug.cgi?id=747377#c24 Now, I'm _not_ saying that the glibc change is wrong. In fact, it enables extra gcc optimizations, which is great. But in this case it looks like we're going to have to review all use of thread mutexes in the whole of Fedora. Maybe not the kind of thing we had in mind for Fedora 16 at this point. I think it's great that Thomas Rast, Jim Meyering, and Jakub Jelinek found the problem after probably a couple of man-days of effort, but really development and bug fixing like this belongs in Rawhide. Well, -13 is what we currently have in stable, and we're past freeze. So unless this isn't broken in -13, to make sure this only 'nearly' gets pushed into F16, we're going to need a non-broken -14 and that bug is going to need to be proposed as a blocker or NTH. Otherwise it'll only get fixed with a 0-day. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another glibc change that nearly got pushed into F16
On Tue, Oct 25, 2011 at 12:17:54PM -0700, Adam Williamson wrote: On Tue, 2011-10-25 at 18:54 +0100, Richard W.M. Jones wrote: It's rather too complex to explain the change here, so I suggest you go and read these first: http://permalink.gmane.org/gmane.comp.version-control.git/184205 http://permalink.gmane.org/gmane.comp.version-control.git/184209 https://bugzilla.redhat.com/show_bug.cgi?id=747377#c22 https://bugzilla.redhat.com/show_bug.cgi?id=747377#c24 Now, I'm _not_ saying that the glibc change is wrong. In fact, it enables extra gcc optimizations, which is great. But in this case it looks like we're going to have to review all use of thread mutexes in the whole of Fedora. Maybe not the kind of thing we had in mind for Fedora 16 at this point. I think it's great that Thomas Rast, Jim Meyering, and Jakub Jelinek found the problem after probably a couple of man-days of effort, but really development and bug fixing like this belongs in Rawhide. Well, -13 is what we currently have in stable, and we're past freeze. Doh. So unless this isn't broken in -13, to make sure this only 'nearly' gets pushed into F16, we're going to need a non-broken -14 and that bug is going to need to be proposed as a blocker or NTH. My non-expert advice would be that this should be a blocker. It would be better if experts in POSIX arcana could weigh in on this subject though. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another glibc change that nearly got pushed into F16
On Tue, Oct 25, 2011 at 8:17 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2011-10-25 at 18:54 +0100, Richard W.M. Jones wrote: It's rather too complex to explain the change here, so I suggest you go and read these first: http://permalink.gmane.org/gmane.comp.version-control.git/184205 http://permalink.gmane.org/gmane.comp.version-control.git/184209 https://bugzilla.redhat.com/show_bug.cgi?id=747377#c22 https://bugzilla.redhat.com/show_bug.cgi?id=747377#c24 Now, I'm _not_ saying that the glibc change is wrong. In fact, it enables extra gcc optimizations, which is great. But in this case it looks like we're going to have to review all use of thread mutexes in the whole of Fedora. Maybe not the kind of thing we had in mind for Fedora 16 at this point. I think it's great that Thomas Rast, Jim Meyering, and Jakub Jelinek found the problem after probably a couple of man-days of effort, but really development and bug fixing like this belongs in Rawhide. Well, -13 is what we currently have in stable, and we're past freeze. So unless this isn't broken in -13, to make sure this only 'nearly' gets pushed into F16, we're going to need a non-broken -14 and that bug is going to need to be proposed as a blocker or NTH. Otherwise it'll only get fixed with a 0-day. As long as its not the broken one shipped as 0-day :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
