Review swaps

[Hans de Goede]

Hi,

I'm looking for someone to swap 2 reviews with, I would like to see the 
following reviewed:

cortado - Java media framework:
https://bugzilla.redhat.com/show_bug.cgi?id=649781

CEGUI library 0.6 for apps which need this specific version:
https://bugzilla.redhat.com/show_bug.cgi?id=650643

Regards,

Hans
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Review swaps

[Peter Lemenkov]

2010/11/17 Hans de Goede :
> Hi,
>
> I'm looking for someone to swap 2 reviews with, I would like to see the 
> following reviewed:
>
> cortado - Java media framework:
> https://bugzilla.redhat.com/show_bug.cgi?id=649781

I'll take this.


-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding patches in a SPEC

[Martin Sourada]

On Tue, 2010-11-16 at 17:17 -0500, Eric "Sparks" Christensen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 11/16/2010 04:28 PM, Martin Sourada wrote:
> > On Tue, 2010-11-16 at 11:18 -0500, Eric "Sparks" Christensen wrote:
> >> On Tue, Nov 16, 2010 at 11:04, Patrick MONNERAT  wrote:
> >>> On Tue, 2010-11-16 at 17:48 +0200, Andy Shevchenko wrote:
>  You need to do patch on top of source tree container
> 
>  mycoolpkg-5.3/
>  /Makefile
>  /source.c
>  ...
>  mycoolpkg-5.3.new/
> /Makefile
> /source.c
>  ...
> 
>  run  diff -ruN -p mycoolpkg-5.3 mycoolpkg-5.3.new
> 
> >>>
> >>> ... and use %patch0 -p 1 ...
> >>
> >> Okay, I ran the above diff and created a nice patch:
> >>
> >> diff -ruN -p gpredict-1.2/Makefile gpredict-1.2.new/Makefile
> >> --- gpredict-1.2/Makefile   2010-11-15 20:07:20.676418835 -0500
> >> +++ gpredict-1.2.new/Makefile   2010-11-16 11:04:49.677590541 -0500
> >> @@ -168,7 +168,7 @@ OTOOL64 =
> >>  PACKAGE = gpredict
> >>  PACKAGE_BUGREPORT =
> >>  PACKAGE_CFLAGS = -pthread -I/usr/include/gtk-2.0
> >> -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
> >> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0
> >> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
> >> -I/usr/include/pixman-1 -I/usr/include/freetype2
> >> -I/usr/include/libpng12 -I/usr/include/goocanvas-1.0
> >> -PACKAGE_LIBS = -pthread -lgoocanvas -lgtk-x11-2.0 -lgdk-x11-2.0
> >> -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
> >> -lm -lcairo -lpng12 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0
> >> -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lcurl
> >> +PACKAGE_LIBS = -lm -pthread -lgoocanvas -lgtk-x11-2.0 -lgdk-x11-2.0
> >> -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
> >> -lm -lcairo -lpng12 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0
> >> -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lcurl
> >>  PACKAGE_NAME =
> >>  PACKAGE_STRING =
> >>  PACKAGE_TARNAME =
> >>
> >> I changed the SPEC to say "%patch0 -p 1".  I get the same error (below):
> >>
> >> [u...@server rpmbuild]$ rpmbuild -ba SPECS/gpredict.spec
> >> Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.wAGj7E
> >> + umask 022
> >> + cd /home/christensene/rpmbuild/BUILD
> >> + LANG=C
> >> + export LANG
> >> + unset DISPLAY
> >> + cd /home/christensene/rpmbuild/BUILD
> >> + rm -rf gpredict-1.2
> >> + /usr/bin/gzip -dc /home/user/rpmbuild/SOURCES/gpredict-1.2.tar.gz
> >> + /bin/tar -xf -
> >> + STATUS=0
> >> + '[' 0 -ne 0 ']'
> >> + cd gpredict-1.2
> >> + /bin/chmod -Rf a+rX,u+w,g-w,o-w .
> >> + echo 'Patch #0 (gpredict-1.2-DSO.patch):'
> >> Patch #0 (gpredict-1.2-DSO.patch):
> >> + /bin/cat /home/user/rpmbuild/SOURCES/gpredict-1.2-DSO.patch
> >> + /usr/bin/patch -s -p1 --fuzz=0
> >> The text leading up to this was:
> >> --
> >> |diff -ruN -p gpredict-1.2/Makefile gpredict-1.2.new/Makefile
> >> |--- gpredict-1.2/Makefile  2010-11-15 20:07:20.676418835 -0500
> >> |+++ gpredict-1.2.new/Makefile  2010-11-16 11:04:49.677590541 -0500
> >> --
> > That might be because the Makefile actually isn't there -- it's usually
> > created from Makefile.in after calling ./configure. IMHO you have
> > several options
> >   * use sed to make the change, after running configure
> >   * patch Makefile.in instead of Makefile
> >   * patch Makefile.am and reconfigure (autoreconf --force,
> > or ./autogen.sh, depending how autotools are handled in
> > gpredict)
> > 
> > And anyway, why are you trying to patch it this way? Unless I missed
> > something you're adding -lm to PACKAGE_LIBS which is however already
> > present (prior to -lcairo) there.
> > 
> > Martin
> > 
> 
> I ran into the following error when I was building the SRPM:
> 
> /usr/bin/ld: solar.o: undefined reference to symbol 'sincos@@GLIBC_2.2.5'
> /usr/bin/ld: note: 'sincos@@GLIBC_2.2.5' is defined in DSO
> /lib64/libm.so.6 so try adding it to the linker command line
> /lib64/libm.so.6: could not read symbols: Invalid operation
> collect2: ld returned 1 exit status
> make[4]: *** [test-002] Error 1
> make[4]: *** Waiting for unfinished jobs
> /usr/bin/ld: solar.o: undefined reference to symbol 'sincos@@GLIBC_2.2.5'
> /usr/bin/ld: note: 'sincos@@GLIBC_2.2.5' is defined in DSO
> /lib64/libm.so.6 so try adding it to the linker command line
> /lib64/libm.so.6: could not read symbols: Invalid operation
> 
> 
> I was told that I needed to add the -lm to the PACKAGE_LIBS which is
> what I was trying to do.  If this is NOT what I need to do or I need to
> fix this in a different manner I'm open to suggestions.
> 
Well, the thing is, unless I read the patch incorrectly, that -lm
already is in PACKAGE_LIBS, so this error is even more confusing. Does
it build with the patched Makefile (i.e. does running make after editing
the Makefile works)?

Actually, I've just searched a bit over the net, t

Re: sched_autogroup interactivity patch for the desktop

[Michał Piotrowski]

Hi,

2010/11/16 Ilyes Gouta :
> Hi,
> http://linux.slashdot.org/story/10/11/16/1330233/The-200-Line-Linux-Kernel-Patch-That-Does-Wonders
> patch: http://marc.info/?l=linux-kernel&m=128978361700898&w=2
> Can we have this patch back ported into the current kernel for Fedora 14 and
> possibly posted as an update? :)

Let me guess - Canonical already announced (or will do so within the
next few hours) that they will use this patch in the new Ubuntu :)

> Would be wonderful!

Surely this would be

> -Ilyes
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

Best regards,
Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[nodata]

On 17/11/10 08:57, Hans de Goede wrote:
> Hi all,
>
> For those who do not know it yet, recent Fedora glibc updates include
> an optimized memcpy (which gets used on some processors) which breaks the
> 64 bit adobe flash plugin.
>
> The problem has been analyzed and is known, as well as a fix for it, see:
> https://bugzilla.redhat.com/show_bug.cgi?id=638477
>
> The problem still exists however. The glibc developers say that this is
> not a glibc bug, but a flash plugin bug. And technically they are 100%
> correct, and the adobe flash plugin is a buggy  (no surprise there).
> To be specific the flash plugin is doing overlapping memcpy-s which is
> clearly not how memcpy is supposed to be used. But the way the flash
> plugin does overlapping memcpy's happens to work fine as long as one as
> the c library does the memcpy-s in forward direction. And the new memcpy
> implementation does the memcpy in backward direction.
>
> The glibc developers being technically 100% correct is not helping our
> end users in this case though. So we (The Fedora project) need to come up
> with a solution to help our end users, many of whom want to use the adobe
> flash plugin.
>
> This solution could be reverting the problem causing glibc change, or
> maybe changing it to do forward memcpy's while still using the new SSE
> instructions, or something more specific to the flash plugin, as long
> as it will automatically fix things with a yum upgrade without requiring
> any further user intervention.
>
> I would also like to point out that if this were to happen in Ubuntu
> which we sometimes look at jealously for getting more attention / users
> then us, the glibc change would likely be reverted immediately, as that
> is the right thing to do from an end user pov.
>
> I've filed a ticket for FESCo to look into this, as I believe this
> makes us look really bad, and the glibc maintainers do not seem to be
> willing to fix it without some sort of intervention:
> https://fedorahosted.org/fesco/ticket/501
>
> Regards,
>
> Hans

Is someone talking to Adobe about this?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[drago01]

On Wed, Nov 17, 2010 at 10:17 AM, nodata  wrote:
> On 17/11/10 08:57, Hans de Goede wrote:
>> Hi all,
>>
>> For those who do not know it yet, recent Fedora glibc updates include
>> an optimized memcpy (which gets used on some processors) which breaks the
>> 64 bit adobe flash plugin.
>>
>> The problem has been analyzed and is known, as well as a fix for it, see:
>> https://bugzilla.redhat.com/show_bug.cgi?id=638477
>>
>> The problem still exists however. The glibc developers say that this is
>> not a glibc bug, but a flash plugin bug. And technically they are 100%
>> correct, and the adobe flash plugin is a buggy  (no surprise there).
>> To be specific the flash plugin is doing overlapping memcpy-s which is
>> clearly not how memcpy is supposed to be used. But the way the flash
>> plugin does overlapping memcpy's happens to work fine as long as one as
>> the c library does the memcpy-s in forward direction. And the new memcpy
>> implementation does the memcpy in backward direction.
>>
>> The glibc developers being technically 100% correct is not helping our
>> end users in this case though. So we (The Fedora project) need to come up
>> with a solution to help our end users, many of whom want to use the adobe
>> flash plugin.
>>
>> This solution could be reverting the problem causing glibc change, or
>> maybe changing it to do forward memcpy's while still using the new SSE
>> instructions, or something more specific to the flash plugin, as long
>> as it will automatically fix things with a yum upgrade without requiring
>> any further user intervention.
>>
>> I would also like to point out that if this were to happen in Ubuntu
>> which we sometimes look at jealously for getting more attention / users
>> then us, the glibc change would likely be reverted immediately, as that
>> is the right thing to do from an end user pov.
>>
>> I've filed a ticket for FESCo to look into this, as I believe this
>> makes us look really bad, and the glibc maintainers do not seem to be
>> willing to fix it without some sort of intervention:
>> https://fedorahosted.org/fesco/ticket/501
>>
>> Regards,
>>
>> Hans
>
> Is someone talking to Adobe about this?

Yes, see https://bugs.adobe.com/jira/browse/FP-5739
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Changes in Java packaging guidelines - RFC

[Mat Booth]

On 17 November 2010 05:29, Kevin Kofler  wrote:
> Ville Skyttä wrote:
>> I'd get rid of the versioned javadoc dir altogether, and simply install to
>> %{_javadocdir}/%{name}.  Unversioned is good for bookmarking and javadoc
>> crosslinking.
>
> One thing you have to be careful of, no matter which way you decide, is that
> you MUST NOT change a directory to a symlink or the other way round or RPM
> will get terribly confused on upgrades.
>
> (There are bizarre (and easy to get wrong) scriptlet workarounds that can be
> used, but avoiding the mess in the first place is probably the best
> solution.)
>
>        Kevin Kofler
>

Is this a bug in rpm?


-- 
Mat Booth
http://fedoraproject.org/get-fedora
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: sched_autogroup interactivity patch for the desktop

[Ilyes Gouta]

Hi,

I've been reading http://lkml.org/lkml/2010/11/16/402 and actually Lennart
has put some solid thoughts and arguments there and IMHO it was *somehow*
pretty convincing that this should be done at user-space, in conjunction
with tools such as systemd, albeit introducing more complexity in form of
configuration infrastructure and whatnot.

Having this being done automatically by the kernel looks really easy and yet
promising. The downside of it is that it just feels like it's something
rigged towards a special class of applications (TTY based, build jobs) and
would act behind the scene without user-space knowing (explicitly) about
this classification, cgroups being spawned and subtasks associated to them.

Still, It would be nice to have this differentiation in place, being
implemented in either forms, since it brings a certain win for the desktop
user and developer. I think having a term open for churning code is part (or
a possible user-case) of the desktop experience :)

-Ilyes

2010/11/17 Michał Piotrowski 

> Hi,
>
> 2010/11/16 Ilyes Gouta :
> > Hi,
> >
> http://linux.slashdot.org/story/10/11/16/1330233/The-200-Line-Linux-Kernel-Patch-That-Does-Wonders
> > patch: http://marc.info/?l=linux-kernel&m=128978361700898&w=2
> > Can we have this patch back ported into the current kernel for Fedora 14
> and
> > possibly posted as an update? :)
>
> Let me guess - Canonical already announced (or will do so within the
> next few hours) that they will use this patch in the new Ubuntu :)
>
> > Would be wonderful!
>
> Surely this would be
>
> > -Ilyes
> > --
> > devel mailing list
> > devel@lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
> >
>
> Best regards,
> Michal
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Michel Alexandre Salim]

On Wed, 17 Nov 2010 10:20:35 +0100, drago01 wrote:

> On Wed, Nov 17, 2010 at 10:17 AM, nodata  wrote:
>> On 17/11/10 08:57, Hans de Goede wrote:
>>> Hi all,
>>>
>>> For those who do not know it yet, recent Fedora glibc updates include
>>> an optimized memcpy (which gets used on some processors) which breaks
>>> the 64 bit adobe flash plugin.
>>>
>>> The problem has been analyzed and is known, as well as a fix for it,
>>> see: https://bugzilla.redhat.com/show_bug.cgi?id=638477
>>>
...
>> I've filed a ticket for FESCo to look into this, as I believe this
>>> makes us look really bad, and the glibc maintainers do not seem to be
>>> willing to fix it without some sort of intervention:
>>> https://fedorahosted.org/fesco/ticket/501
>>>
>>> Regards,
>>>
>>> Hans
>>
>> Is someone talking to Adobe about this?
> 
> Yes, see https://bugs.adobe.com/jira/browse/FP-5739

So this problem would not have been there in the first place had the 
Flash plugin just reuse some other MP3 decoding library (e.g. through 
Gstreamer) rather than rolling out their own, right?


-- 
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email:  sali...@fedoraproject.org  | GPG key ID: 78884778
Jabber: hir...@jabber.ccc.de   | IRC: hir...@irc.freenode.net

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[nodata]

On 17/11/10 10:20, drago01 wrote:
> On Wed, Nov 17, 2010 at 10:17 AM, nodata  wrote:
>> On 17/11/10 08:57, Hans de Goede wrote:
>>> Hi all,
>>>
>>> For those who do not know it yet, recent Fedora glibc updates include
>>> an optimized memcpy (which gets used on some processors) which breaks the
>>> 64 bit adobe flash plugin.
>>>
>>> The problem has been analyzed and is known, as well as a fix for it, see:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=638477
>>>
>>> The problem still exists however. The glibc developers say that this is
>>> not a glibc bug, but a flash plugin bug. And technically they are 100%
>>> correct, and the adobe flash plugin is a buggy  (no surprise there).
>>> To be specific the flash plugin is doing overlapping memcpy-s which is
>>> clearly not how memcpy is supposed to be used. But the way the flash
>>> plugin does overlapping memcpy's happens to work fine as long as one as
>>> the c library does the memcpy-s in forward direction. And the new memcpy
>>> implementation does the memcpy in backward direction.
>>>
>>> The glibc developers being technically 100% correct is not helping our
>>> end users in this case though. So we (The Fedora project) need to come up
>>> with a solution to help our end users, many of whom want to use the adobe
>>> flash plugin.
>>>
>>> This solution could be reverting the problem causing glibc change, or
>>> maybe changing it to do forward memcpy's while still using the new SSE
>>> instructions, or something more specific to the flash plugin, as long
>>> as it will automatically fix things with a yum upgrade without requiring
>>> any further user intervention.
>>>
>>> I would also like to point out that if this were to happen in Ubuntu
>>> which we sometimes look at jealously for getting more attention / users
>>> then us, the glibc change would likely be reverted immediately, as that
>>> is the right thing to do from an end user pov.
>>>
>>> I've filed a ticket for FESCo to look into this, as I believe this
>>> makes us look really bad, and the glibc maintainers do not seem to be
>>> willing to fix it without some sort of intervention:
>>> https://fedorahosted.org/fesco/ticket/501
>>>
>>> Regards,
>>>
>>> Hans
>>
>> Is someone talking to Adobe about this?
>
> Yes, see https://bugs.adobe.com/jira/browse/FP-5739

Adobe benefits from Flash in Linux. So it seems sensible to:

1. Get Adobe to commit to a fix soon WITH A $DATE
2. Agree to patch the change until $DATE
3. Adobe updates Flash, we revert the patch, everyone is happy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide report: 20101117 changes

[Rawhide Report]

Compose started at Wed Nov 17 08:15:16 UTC 2010

Broken deps for x86_64
--
balsa-2.4.7-2.fc14.x86_64 requires libnotify.so.1()(64bit)
beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit)
beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit)
bognor-regis-0.6.11-1.fc15.i686 requires libnotify.so.1
bognor-regis-0.6.11-1.fc15.x86_64 requires libnotify.so.1()(64bit)
db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0
dh-make-0.55-2.fc15.noarch requires debhelper
eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit)
gedit-vala-0.10.2-2.fc15.i686 requires libvala-0.10.so.0
gedit-vala-0.10.2-2.fc15.x86_64 requires libvala-0.10.so.0()(64bit)
gnome-applet-sensors-2.2.7-3.fc15.i686 requires libnotify.so.1
gnome-applet-sensors-2.2.7-3.fc15.x86_64 requires 
libnotify.so.1()(64bit)
1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
gnome-gmail-notifier-0.10.1-1.fc14.x86_64 requires 
libnotify.so.1()(64bit)
gnome-pilot-eds-2.32.0-1.fc14.x86_64 requires 
libcamel-1.2.so.19()(64bit)
gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires 
libbrasero-burn.so.1()(64bit)
gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires 
libbrasero-media.so.1()(64bit)
gnome-python2-evince-2.32.0-1.fc14.x86_64 requires 
libevdocument.so.3()(64bit)
gnome-python2-evince-2.32.0-1.fc14.x86_64 requires 
libevview.so.3()(64bit)
gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires 
libcamel-1.2.so.19()(64bit)
gnome-python2-totem-2.32.0-1.fc14.x86_64 requires 
libgnome-media-profiles.so.0()(64bit)
gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 
0:2.0.0.0
gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit)
gpx-viewer-0.2.0-3.fc14.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
gpx-viewer-0.2.0-3.fc14.x86_64 requires 
libchamplain-gtk-0.6.so.0()(64bit)
gshutdown-0.2-6.fc12.x86_64 requires libnotify.so.1()(64bit)
gsql-0.2.1-4.fc12.i686 requires libnotify.so.1
gsql-0.2.1-4.fc12.x86_64 requires libnotify.so.1()(64bit)
gyachi-plugin-libnotify-1.2.10-3.fc14.x86_64 requires 
libnotify.so.1()(64bit)
hornsey-1.5.2-0.3.fc15.x86_64 requires libnotify.so.1()(64bit)
hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit)
ibus-fbterm-0.9.1-10.fc15.x86_64 requires libibus.so.2()(64bit)
ibus-sunpinyin-2.0.2-2.fc15.x86_64 requires libibus.so.2()(64bit)
intellij-idea-9.0.1.94.399-12.fc15.x86_64 requires commons-collections
ircp-tray-0.7.4-1.fc14.x86_64 requires libnotify.so.1()(64bit)
java-gnome-4.0.16-3.fc14.x86_64 requires libnotify.so.1()(64bit)
libnotifymm-0.6.1-8.fc14.i686 requires libnotify.so.1
libnotifymm-0.6.1-8.fc14.x86_64 requires libnotify.so.1()(64bit)
log4net-1.2.10-13.fc13.x86_64 requires mono(System) = 0:1.0.5000.0
log4net-1.2.10-13.fc13.x86_64 requires mono(System.Data) = 0:1.0.5000.0
log4net-1.2.10-13.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0
log4net-1.2.10-13.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0
log4net-1.2.10-13.fc13.x86_64 requires mono(System.Web) = 0:1.0.5000.0
lxmusic-0.4.4-1.fc14.x86_64 requires libnotify.so.1()(64bit)
mars-sim-2.84-6.fc14.noarch requires commons-collections
meego-panel-devices-0.2.4-4.fc15.x86_64 requires 
libdevkit-power-gobject.so.1()(64bit)
meego-panel-devices-0.2.4-4.fc15.x86_64 requires libnotify.so.1()(64bit)
moblin-panel-status-0.1.21-6.fc14.x86_64 requires 
libsocialweb-client.so.1()(64bit)
moblin-panel-status-0.1.21-6.fc14.x86_64 requires 
libchamplain-0.6.so.0()(64bit)
moblin-panel-status-0.1.21-6.fc14.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Drawing) = 
0:1.0.5000.0
mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Windows.Forms) = 
0:1.0.5000.0
mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System) = 0:1.0.5000.0
mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0
mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0
nagios-plugins-snmp-disk-proc-1.2-6.fc13.x86_64 requires 
libnetsnmp.so.20()(64bit)
1:nant-0.85-34.fc13.x86_64 requires mono(ICSharpCode.SharpZipLib) = 
0:0.84.0.0
network-manager-netbook-1.7.1-0.1.fc14.x86_64 requires 
libnotify.so.1()(64bit)
nntpgrab-gui-0.6.90-3.fc15.x86_64 requires libnotify.so.1()(64bit)
padevchooser-0.9.4-0.11.svn20070925.fc13.x86_64 requires 
libnotify.so.1()(64bit)
pcmanx-gtk2-0.3.9-6.20100618svn.fc14.i686 requires libnotify.so.1
pcmanx-gtk2-0.3.9-6.20100618svn.fc14.x86_64 requires 
li

Re: sched_autogroup interactivity patch for the desktop

[Josh Boyer]

On Wed, Nov 17, 2010 at 5:03 AM, Ilyes Gouta  wrote:
> Hi,
> I've been reading http://lkml.org/lkml/2010/11/16/402 and actually Lennart
> has put some solid thoughts and arguments there and IMHO it was *somehow*
> pretty convincing that this should be done at user-space, in conjunction
> with tools such as systemd, albeit introducing more complexity in form of
> configuration infrastructure and whatnot.
> Having this being done automatically by the kernel looks really easy and yet
> promising. The downside of it is that it just feels like it's something
> rigged towards a special class of applications (TTY based, build jobs) and
> would act behind the scene without user-space knowing (explicitly) about
> this classification, cgroups being spawned and subtasks associated to them.
> Still, It would be nice to have this differentiation in place, being
> implemented in either forms, since it brings a certain win for the desktop
> user and developer. I think having a term open for churning code is part (or
> a possible user-case) of the desktop experience :)

Being entirely serious, you should have sent this email on the thread
you indicated.  Sending it to this list isn't going to really benefit
the discussion that needs to happen.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Review swap

[Jiri Popelka]

Hi,

I have two easy python modules to review.

python-cups - Python bindings for the CUPS API, known as pycups
https://bugzilla.redhat.com/show_bug.cgi?id=648986

python-smbc - Python bindings for the libsmbclient API from Samba, known 
as pysmbc
https://bugzilla.redhat.com/show_bug.cgi?id=648987

Anyone interested in review swap ?

Jiri

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding patches in a SPEC

[Eric "Sparks" Christensen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/17/2010 03:57 AM, Martin Sourada wrote:
> On Tue, 2010-11-16 at 17:17 -0500, Eric "Sparks" Christensen wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 11/16/2010 04:28 PM, Martin Sourada wrote:
>>> On Tue, 2010-11-16 at 11:18 -0500, Eric "Sparks" Christensen wrote:
 On Tue, Nov 16, 2010 at 11:04, Patrick MONNERAT  wrote:
> On Tue, 2010-11-16 at 17:48 +0200, Andy Shevchenko wrote:
>> You need to do patch on top of source tree container
>>
>> mycoolpkg-5.3/
>> /Makefile
>> /source.c
>> ...
>> mycoolpkg-5.3.new/
>>/Makefile
>>/source.c
>> ...
>>
>> run  diff -ruN -p mycoolpkg-5.3 mycoolpkg-5.3.new
>>
>
> ... and use %patch0 -p 1 ...

 Okay, I ran the above diff and created a nice patch:

 diff -ruN -p gpredict-1.2/Makefile gpredict-1.2.new/Makefile
 --- gpredict-1.2/Makefile   2010-11-15 20:07:20.676418835 -0500
 +++ gpredict-1.2.new/Makefile   2010-11-16 11:04:49.677590541 -0500
 @@ -168,7 +168,7 @@ OTOOL64 =
  PACKAGE = gpredict
  PACKAGE_BUGREPORT =
  PACKAGE_CFLAGS = -pthread -I/usr/include/gtk-2.0
 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0
 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
 -I/usr/include/pixman-1 -I/usr/include/freetype2
 -I/usr/include/libpng12 -I/usr/include/goocanvas-1.0
 -PACKAGE_LIBS = -pthread -lgoocanvas -lgtk-x11-2.0 -lgdk-x11-2.0
 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
 -lm -lcairo -lpng12 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0
 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lcurl
 +PACKAGE_LIBS = -lm -pthread -lgoocanvas -lgtk-x11-2.0 -lgdk-x11-2.0
 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
 -lm -lcairo -lpng12 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0
 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lcurl
  PACKAGE_NAME =
  PACKAGE_STRING =
  PACKAGE_TARNAME =

 I changed the SPEC to say "%patch0 -p 1".  I get the same error (below):

 [u...@server rpmbuild]$ rpmbuild -ba SPECS/gpredict.spec
 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.wAGj7E
 + umask 022
 + cd /home/christensene/rpmbuild/BUILD
 + LANG=C
 + export LANG
 + unset DISPLAY
 + cd /home/christensene/rpmbuild/BUILD
 + rm -rf gpredict-1.2
 + /usr/bin/gzip -dc /home/user/rpmbuild/SOURCES/gpredict-1.2.tar.gz
 + /bin/tar -xf -
 + STATUS=0
 + '[' 0 -ne 0 ']'
 + cd gpredict-1.2
 + /bin/chmod -Rf a+rX,u+w,g-w,o-w .
 + echo 'Patch #0 (gpredict-1.2-DSO.patch):'
 Patch #0 (gpredict-1.2-DSO.patch):
 + /bin/cat /home/user/rpmbuild/SOURCES/gpredict-1.2-DSO.patch
 + /usr/bin/patch -s -p1 --fuzz=0
 The text leading up to this was:
 --
 |diff -ruN -p gpredict-1.2/Makefile gpredict-1.2.new/Makefile
 |--- gpredict-1.2/Makefile  2010-11-15 20:07:20.676418835 -0500
 |+++ gpredict-1.2.new/Makefile  2010-11-16 11:04:49.677590541 -0500
 --
>>> That might be because the Makefile actually isn't there -- it's usually
>>> created from Makefile.in after calling ./configure. IMHO you have
>>> several options
>>>   * use sed to make the change, after running configure
>>>   * patch Makefile.in instead of Makefile
>>>   * patch Makefile.am and reconfigure (autoreconf --force,
>>> or ./autogen.sh, depending how autotools are handled in
>>> gpredict)
>>>
>>> And anyway, why are you trying to patch it this way? Unless I missed
>>> something you're adding -lm to PACKAGE_LIBS which is however already
>>> present (prior to -lcairo) there.
>>>
>>> Martin
>>>
>>
>> I ran into the following error when I was building the SRPM:
>>
>> /usr/bin/ld: solar.o: undefined reference to symbol 'sincos@@GLIBC_2.2.5'
>> /usr/bin/ld: note: 'sincos@@GLIBC_2.2.5' is defined in DSO
>> /lib64/libm.so.6 so try adding it to the linker command line
>> /lib64/libm.so.6: could not read symbols: Invalid operation
>> collect2: ld returned 1 exit status
>> make[4]: *** [test-002] Error 1
>> make[4]: *** Waiting for unfinished jobs
>> /usr/bin/ld: solar.o: undefined reference to symbol 'sincos@@GLIBC_2.2.5'
>> /usr/bin/ld: note: 'sincos@@GLIBC_2.2.5' is defined in DSO
>> /lib64/libm.so.6 so try adding it to the linker command line
>> /lib64/libm.so.6: could not read symbols: Invalid operation
>>
>>
>> I was told that I needed to add the -lm to the PACKAGE_LIBS which is
>> what I was trying to do.  If this is NOT what I need to do or I need to
>> fix this in a different manner I'm open to suggestions.
>>
> Well, the thing is, unless I read the patch incorrectly, that -lm
> already is in PACKAGE_LIBS, so this error is even more confusing. Does
> it build with the patched Mak

Re: Fedora 15, new and exciting plans (biosdevname)

[Jon Masters]

On Tue, 2010-11-16 at 09:24 -0500, Matthew Miller wrote:
> On Sun, Nov 14, 2010 at 07:53:40AM -0600, Matt Domsch wrote:
> > > > biosdevname installed by default, used in the installer and at runtime
> > > > to rename Dell and HP server onboard NICs from non-deterministic
> > > > "ethX" to clearly labeled "lomX" matching the chassis silkscreen.
> > >   But why ???lomX??? for all? Isn't Lights-Out-Management available only 
> > > on first
> > > ethernet port and often on dedicated port?
> > This has nothing to do with Lights-Out-Management.  LOM also == LAN on
> > Motherboard.
> 
> Since you're already silkscreening this on the chassis of your systems,
> clearly this ship is well out of the harbor, but that confusion seems like a
> completely legitimate concern. Seems like it could easily result in
> management interfaces getting plugged into the wrong networks.
> 
> Also, I gotta say, it really shouldn't be LAN on Motherboard, since it's
> just an adapter, not actually a whole lan. It should clearly be NIC on
> Motherboard, or "nom". And then you could silkscreen lolcats on to the
> servers, which I think would be a win for everyone.

I've had a few off-list conversations with various community members
about this. One thing that came up was that the alternative namespace is
necessary, but also that "lom" is a sub-optimal choice. One idea that
did come up was simply to call them "net" (net0, etc.) or perhaps "net"
followed by another letter like "netm" or something. To avoid
bikeshedding this to death though, I think Matt's "lom" naming is fine
for the moment unless we happen to all agree on something else.

Meanwhile, there are two other things I'm keeping ticking over:

1). Potential kernel-based solutions to augment this (but not otherwise
affect what would be in F-15). More on that another time.
2). Naming of non-network devices. Both DMTF and other groups (ACPI,
PCI, etc.) looking at the problem of persistent device to slot mappings
have all looked at more than network. While Matt is (rightfully) looking
at networking in F-15, we need to remember this problem actually will in
future also necessitate work on other non-network devices, too.

Jon.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 654301] New: False-positive related to XS code - please update to 0.11 or later

[bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

Summary: False-positive related to XS code - please update to 0.11 or later

https://bugzilla.redhat.com/show_bug.cgi?id=654301

   Summary: False-positive related to XS code - please update to
0.11 or later
   Product: Fedora
   Version: rawhide
  Platform: Unspecified
OS/Version: Unspecified
Status: NEW
  Severity: medium
  Priority: low
 Component: perl-Test-LeakTrace
AssignedTo: cw...@alumni.drew.edu
ReportedBy: p...@city-fan.org
 QAContact: extras...@fedoraproject.org
CC: cw...@alumni.drew.edu,
fedora-perl-devel-l...@redhat.com
Classification: Fedora


Upstream issue resolved in 0.11:

https://rt.cpan.org/Public/Bug/Display.html?id=58133

I need this fixed for my Package::Stash::XZ submission.

Latest upstream release is 0.13.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Guidelines Change] Changes to the Packaging Guidelines

[Tom "spot" Callaway]

Here are the list of recent changes to the Fedora Packaging Guidelines:

D Packaging Guidelines have been added:
https://fedoraproject.org/wiki/Packaging:D

---

The Java Packaging Guidelines have been revised:
https://fedoraproject.org/wiki/Packaging:Java
Diff:
https://fedoraproject.org/w/index.php?title=Packaging%3AJava&diff=206526&oldid=154023

---

The Guideline that explains how and when to require base packages has
been substantially revised.  The old language focused on -devel packages
and left other subpackages to the imagination of the reader.  The update
has more generic advice and uses -devel and -libs packages as examples.

http://fedoraproject.org/wiki/Packaging/Guidelines#RequiringBasePackage

---

The perl guidelines have been updated with additional examples and
clarifications.  Specifically, the Directory ownership, requires and
provides, and testing sections have seen wording changes:

https://fedoraproject.org/wiki/Packaging:Perl

---

A guideline was added explaining the %pretrans scriptlet and requiring
that if used it must be written in Lua.

https://fedoraproject.org/wiki/Packaging/Guidelines#The_.25pretrans_scriptlet

---

A note was added about additional checks obtained by running rpmlint on
installed packages.

https://fedoraproject.org/wiki/Packaging/Guidelines#Use_rpmlint

---

These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).

Many thanks to Alexander Kurtakov, Jonathan Mercier, Stanislav
Ochotnicky and all of the members of the FPC, for assisting in drafting,
refining, and passing these guidelines.

As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
http://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure

Thanks,

~spot
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 654301] False-positive related to XS code - please update to 0.11 or later

[bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=654301

--- Comment #3 from Fedora Update System  2010-11-17 
10:09:19 EST ---
perl-Test-LeakTrace-0.13-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/perl-Test-LeakTrace-0.13-1.fc13

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 654301] False-positive related to XS code - please update to 0.11 or later

[bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=654301

--- Comment #2 from Fedora Update System  2010-11-17 
10:09:12 EST ---
perl-Test-LeakTrace-0.13-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/perl-Test-LeakTrace-0.13-1.fc14

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Fixing the glibc adobe flash incompatibility

[Magnus Glantz]

On 11/17/2010 11:36 AM, nodata wrote:
> On 17/11/10 10:20, drago01 wrote:
>> On Wed, Nov 17, 2010 at 10:17 AM, nodata   wrote:
>>> On 17/11/10 08:57, Hans de Goede wrote:
 Hi all,

 For those who do not know it yet, recent Fedora glibc updates include
 an optimized memcpy (which gets used on some processors) which breaks the
 64 bit adobe flash plugin.

 The problem has been analyzed and is known, as well as a fix for it, see:
 https://bugzilla.redhat.com/show_bug.cgi?id=638477

 The problem still exists however. The glibc developers say that this is
 not a glibc bug, but a flash plugin bug. And technically they are 100%
 correct, and the adobe flash plugin is a buggy  (no surprise there).
 To be specific the flash plugin is doing overlapping memcpy-s which is
 clearly not how memcpy is supposed to be used. But the way the flash
 plugin does overlapping memcpy's happens to work fine as long as one as
 the c library does the memcpy-s in forward direction. And the new memcpy
 implementation does the memcpy in backward direction.

 The glibc developers being technically 100% correct is not helping our
 end users in this case though. So we (The Fedora project) need to come up
 with a solution to help our end users, many of whom want to use the adobe
 flash plugin.

 This solution could be reverting the problem causing glibc change, or
 maybe changing it to do forward memcpy's while still using the new SSE
 instructions, or something more specific to the flash plugin, as long
 as it will automatically fix things with a yum upgrade without requiring
 any further user intervention.

 I would also like to point out that if this were to happen in Ubuntu
 which we sometimes look at jealously for getting more attention / users
 then us, the glibc change would likely be reverted immediately, as that
 is the right thing to do from an end user pov.

 I've filed a ticket for FESCo to look into this, as I believe this
 makes us look really bad, and the glibc maintainers do not seem to be
 willing to fix it without some sort of intervention:
 https://fedorahosted.org/fesco/ticket/501

 Regards,

 Hans
>>> Is someone talking to Adobe about this?
>> Yes, see https://bugs.adobe.com/jira/browse/FP-5739
> Adobe benefits from Flash in Linux. So it seems sensible to:
>
> 1. Get Adobe to commit to a fix soon WITH A $DATE
> 2. Agree to patch the change until $DATE
> 3. Adobe updates Flash, we revert the patch, everyone is happy
I've e-mailed a with Shu Wang at Adobe (who is the assigned contact for 
this issue) about a date when they can have this fixed.
You've got the e-mail thread regarding this below:

On 11/17/2010 10:19 AM, Shu Wang wrote:
> Hi Magnus,
>
> Maybe months. Thanks.
>
> Best regards.
> Shu
>
>
> -Original Message-
> From: Magnus Glantz [mailto:the-mail-address-is-not-this-...@redhat.com]
> Sent: Wednesday, November 17, 2010 5:15 PM
> To: Shu Wang
> Subject: Re: FP-5739 "Strange sound on mp3 flash website with Fedora 14 
> x86_64"
>
> Hi Shu,
>
> That's is great to hear. Would you guess it's a matter of days, weeks or
> months before this can get fixed?
> If it will take a long time for you to fix this, Fedora may need to look
> at some way to work around this bug.
>
> Best regards,
> Magnus
>
> On 11/17/2010 10:06 AM, Shu Wang wrote:
>> Hi Magnus,
>>
>> Thanks very much for your information. Flash Player team is investigating on 
>> it. It is in progress. Thanks.
>>
>> Best regards,
>> Shu
>>
>>
>>
>> -Original Message-
>> From: Magnus Glantz [mailto:the-mail-address-is-not-this-...@redhat.com]
>> Sent: Wednesday, November 17, 2010 4:47 PM
>> To: Shu Wang
>> Subject: FP-5739 "Strange sound on mp3 flash website with Fedora 14 x86_64"
>>
>> Hello Shu,
>>
>> I humbly wonder if you may have a time estimate on fixing FP-5739.
>> It is seriously is affecting the ability to listen to sounds played in
>> Flash for the users of Fedora.
>>
>> The issue has been traced to Adobe Flash by maintainers of glibc at Red
>> Hat, Linus Torvalds and others.
>> You may read more about this issue here:
>> https://bugzilla.redhat.com/show_bug.cgi?id=638477
>>

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Colin Walters]

On Wed, Nov 17, 2010 at 2:57 AM, Hans de Goede  wrote:
>
> I would also like to point out that if this were to happen in Ubuntu
> which we sometimes look at jealously for getting more attention / users
> then us, the glibc change would likely be reverted immediately, as that
> is the right thing to do from an end user pov.

Hardly; we could for example equally as well patch firefox to load
flash with a compatibility wrapper.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Try-Tiny/f14/master] Update to 0.07

[Paul Howarth]

Summary of changes:

  505f548... Update to 0.07 (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Try-Tiny] Created tag perl-Try-Tiny-0.07-1.fc14

[Paul Howarth]

The lightweight tag 'perl-Try-Tiny-0.07-1.fc14' was created pointing to:

 505f548... Update to 0.07
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Try-Tiny/f13/master] (6 commits) ...Merge branch 'master' into f13

[Paul Howarth]

Summary of changes:

  c1bbc6c... - update by Fedora::App::MaintainerTools 0.004 - PERL_INSTA (*)
  34a9d28... - Mass rebuild with perl-5.12.0 (*)
  2dc9161... dist-git conversion (*)
  505f548... Update to 0.07 (*)
  1750396... Merge branch 'master' (early part) into f13
  c3ccc63... Merge branch 'master' into f13

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Try-Tiny/f13/master: 5/6] Merge branch 'master' (early part) into f13

[Paul Howarth]

commit 1750396595bf83880f0e69425b016dfe91d42c6e
Merge: fbf7a39 2dc9161
Author: Paul Howarth 
Date:   Wed Nov 17 15:31:35 2010 +

Merge branch 'master' (early part) into f13

Conflicts:
.gitignore
perl-Try-Tiny.spec

 .gitignore |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --cc .gitignore
index 13e3751,4ef0f65..73d408c
--- a/.gitignore
+++ b/.gitignore
@@@ -1,1 -1,1 +1,1 @@@
- Try-Tiny-0.02.tar.gz
 -Try-Tiny-0.04.tar.gz
++/Try-Tiny-0.04.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Try-Tiny/f13/master: 6/6] Merge branch 'master' into f13

[Paul Howarth]

commit c3ccc6364cdf0186d12511878274363961e271ea
Merge: 1750396 505f548
Author: Paul Howarth 
Date:   Wed Nov 17 15:32:59 2010 +

Merge branch 'master' into f13

Conflicts:
.gitignore
perl-Try-Tiny.spec

 .gitignore |2 +-
 perl-Try-Tiny.spec |   26 --
 sources|2 +-
 3 files changed, 18 insertions(+), 12 deletions(-)
---
diff --cc perl-Try-Tiny.spec
index 8cc1f3a,8250d13..15695d8
--- a/perl-Try-Tiny.spec
+++ b/perl-Try-Tiny.spec
@@@ -47,11 -46,21 +46,18 @@@ rm -rf %{buildroot
  
  %files
  %defattr(-,root,root,-)
- %doc Changes 
- %{perl_vendorlib}/*
- %{_mandir}/man3/*.3*
+ %doc Changes
+ %{perl_vendorlib}/Try/
+ %{_mandir}/man3/Try::Tiny.3pm*
  
  %changelog
+ * Mon Nov  1 2010 Paul Howarth  0.07-1
+ - update to 0.07:
+   - allow multiple finally blocks
+   - pass the error, if any, to finally blocks when called
+   - documentation fixes and clarifications
+ - this release by RJBS -> update source URL
+ 
 -* Fri May 07 2010 Marcela Maslanova  - 0.04-2
 -- Mass rebuild with perl-5.12.0
 -
  * Tue Mar 02 2010 Chris Weyl  0.04-1
  - update by Fedora::App::MaintainerTools 0.004
  - PERL_INSTALL_ROOT => DESTDIR
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Try-Tiny] Created tag perl-Try-Tiny-0.07-1.fc13

[Paul Howarth]

The lightweight tag 'perl-Try-Tiny-0.07-1.fc13' was created pointing to:

 c3ccc63... Merge branch 'master' into f13
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Fixing the glibc adobe flash incompatibility

[Andrew Haley]

On 11/17/2010 03:17 PM, Magnus Glantz wrote:
> On 11/17/2010 11:36 AM, nodata wrote:
>> On 17/11/10 10:20, drago01 wrote:
>>> On Wed, Nov 17, 2010 at 10:17 AM, nodata   wrote:
 On 17/11/10 08:57, Hans de Goede wrote:
> Hi all,
>
> For those who do not know it yet, recent Fedora glibc updates include
> an optimized memcpy (which gets used on some processors) which breaks the
> 64 bit adobe flash plugin.
>
> The problem has been analyzed and is known, as well as a fix for it, see:
> https://bugzilla.redhat.com/show_bug.cgi?id=638477
>
> The problem still exists however. The glibc developers say that this is
> not a glibc bug, but a flash plugin bug. And technically they are 100%
> correct, and the adobe flash plugin is a buggy  (no surprise there).
> To be specific the flash plugin is doing overlapping memcpy-s which is
> clearly not how memcpy is supposed to be used. But the way the flash
> plugin does overlapping memcpy's happens to work fine as long as one as
> the c library does the memcpy-s in forward direction. And the new memcpy
> implementation does the memcpy in backward direction.
>
> The glibc developers being technically 100% correct is not helping our
> end users in this case though. So we (The Fedora project) need to come up
> with a solution to help our end users, many of whom want to use the adobe
> flash plugin.
>
> This solution could be reverting the problem causing glibc change, or
> maybe changing it to do forward memcpy's while still using the new SSE
> instructions, or something more specific to the flash plugin, as long
> as it will automatically fix things with a yum upgrade without requiring
> any further user intervention.
>
> I would also like to point out that if this were to happen in Ubuntu
> which we sometimes look at jealously for getting more attention / users
> then us, the glibc change would likely be reverted immediately, as that
> is the right thing to do from an end user pov.
>
> I've filed a ticket for FESCo to look into this, as I believe this
> makes us look really bad, and the glibc maintainers do not seem to be
> willing to fix it without some sort of intervention:
> https://fedorahosted.org/fesco/ticket/501
>
> Regards,
>
> Hans
 Is someone talking to Adobe about this?
>>> Yes, see https://bugs.adobe.com/jira/browse/FP-5739
>> Adobe benefits from Flash in Linux. So it seems sensible to:
>>
>> 1. Get Adobe to commit to a fix soon WITH A $DATE
>> 2. Agree to patch the change until $DATE
>> 3. Adobe updates Flash, we revert the patch, everyone is happy
> I've e-mailed a with Shu Wang at Adobe (who is the assigned contact for 
> this issue) about a date when they can have this fixed.
> You've got the e-mail thread regarding this below:

So we should be able simply to patch glibc, right?  Can't see any reason
not to.

Andrew.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Changes in Java packaging guidelines - RFC

[Toshio Kuratomi]

On Wed, Nov 17, 2010 at 09:45:35AM +, Mat Booth wrote:
> On 17 November 2010 05:29, Kevin Kofler  wrote:
> > Ville Skyttä wrote:
> >> I'd get rid of the versioned javadoc dir altogether, and simply install to
> >> %{_javadocdir}/%{name}.  Unversioned is good for bookmarking and javadoc
> >> crosslinking.
> >
> > One thing you have to be careful of, no matter which way you decide, is that
> > you MUST NOT change a directory to a symlink or the other way round or RPM
> > will get terribly confused on upgrades.
> >
> > (There are bizarre (and easy to get wrong) scriptlet workarounds that can be
> > used, but avoiding the mess in the first place is probably the best
> > solution.)
> >
> >        Kevin Kofler
> >
> 
> Is this a bug in rpm?
> 
I believe it's more along the lines of -- hard to get correct and therefore
not yet implemented feature.

-Toshio


pgpczzZ9pmcF9.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

work-around: the glibc adobe flash incompatibility

[John Reiser]

> For those who do not know it yet, recent Fedora glibc updates include
> an optimized memcpy (which gets used on some processors) which breaks the
> 64 bit adobe flash plugin.

For right now (the immediate present) a work-around is to use the 'memmove'
subroutine as the resolution of any reference to the symbol 'memcpy'.
The quick-and-dirty way to do this, is to overwrite with "memmove\0"
the unused {DT_NULL}.d_un field [which is 8 bytes on x86_64] of the
PT_DYNAMIC section, then change the {'memcpy'}.st_name field of the
DT_SYMTAB to designate the overwritten substring.  The PT_DYNAMIC
segment appears after the DT_STRTAB, so the {'memcpy'}.st_name value
[now {'memmove'}.st_name] will be some much larger index than previously.

Another way might be to re-order the DT_NEEDED entries in the PT_DYNAMIC
segment so that "ld-linux.so.2" comes first, lop off the first DT_NEEDED
by increasing the address and decreasing the size by 2*sizeof(void *),
overwriting the "ld-linux.so.2" in the DT_STRTAB with "memmove", then
setting {'memcpy'}.st_name.  ld-linux.so.2 will be there anyway.

-- 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: work-around: the glibc adobe flash incompatibility

[Chris Adams]

Once upon a time, John Reiser  said:
> For right now (the immediate present) a work-around is to use the 'memmove'
> subroutine as the resolution of any reference to the symbol 'memcpy'.
> The quick-and-dirty way to do this

It would probably be easier to use an LD_PRELOAD to load a wrapper to
change memcpy() with overlaps to memmove().  This would obviously slow
down all memcpy() calls, but maybe it could just be used for Flash (or
at least just for plugins).  Something like (untested):


/* Library preload to replacing overlapping memcpy() with memmove()
 *
 * Compile with:
 *   gcc -O2 -ldl -fpic -shared -o preload-memcpy.so preload-memcpy.c
 * Use like
 *   LD_PRELOAD=/path/to/preload-memcpy.so; export LD_PRELOAD
 *   
 */

#define _GNU_SOURCE
#include 
#include 
#include 

static void * (*real_memcpy) (void *dest, const void *src, size_t n);
void *memcpy (void *dest, const void *src, size_t n)
{
char *d = (char *) dest;
char *s = (char *) src;

if (((d < s) && ((d + n - 1) >= s)) ||
((s < d) && ((s + n - 1) >= d)))
return memmove (dest, src, n);
if (! real_memcpy)
assert (real_memcpy = dlsym (RTLD_NEXT, "memcpy"));
return real_memcpy (dest, src, n);
}


-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Jóhann B. Guðmundsson]

Dont we have an upstream mantra to uphold...

Forward all Fedora users and otherwize that experience this to Adobe..

If we are going hack around this on our side where are we going to draw 
the line..

Are we planning to start hacking around every ill written code out there?

JBG
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Matt McCutchen]

On Wed, 2010-11-17 at 16:32 +, "Jóhann B. Guðmundsson" wrote:
> Dont we have an upstream mantra to uphold...
> 
> Forward all Fedora users and otherwize that experience this to Adobe..
> 
> If we are going hack around this on our side where are we going to draw 
> the line..
> 
> Are we planning to start hacking around every ill written code out there?

Hopefully not; this is a particularly high-visibility issue.  Looking at
https://fedoraproject.org/wiki/Objectives and related pages, Fedora has
to weigh the desire for things to "just work" for the envisioned user
base against the desire not to do something technically inferior to
accommodate non-free software.  I'm happy to let FESCo decide this.

-- 
Matt

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Andrew Haley]

On 11/17/2010 04:46 PM, Matt McCutchen wrote:
> On Wed, 2010-11-17 at 16:32 +, "Jóhann B. Guðmundsson" wrote:
>> Dont we have an upstream mantra to uphold...
>>
>> Forward all Fedora users and otherwize that experience this to Adobe..
>>
>> If we are going hack around this on our side where are we going to draw 
>> the line..
>>
>> Are we planning to start hacking around every ill written code out there?
> 
> Hopefully not; this is a particularly high-visibility issue.  Looking at
> https://fedoraproject.org/wiki/Objectives and related pages, Fedora has
> to weigh the desire for things to "just work" for the envisioned user
> base against the desire not to do something technically inferior to
> accommodate non-free software.  I'm happy to let FESCo decide this.

Yes.  This is not a "one size fits all" problem, and doesn't need a
one size fits all solution.  Flash is important to our users.

Andrew.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: work-around: the glibc adobe flash incompatibility

[drago01]

On Wed, Nov 17, 2010 at 5:03 PM, John Reiser  wrote:
>> For those who do not know it yet, recent Fedora glibc updates include
>> an optimized memcpy (which gets used on some processors) which breaks the
>> 64 bit adobe flash plugin.
>
> For right now (the immediate present) a work-around is to use the 'memmove'
> subroutine as the resolution of any reference to the symbol 'memcpy'.

Ray has written a script to do exactly that
https://bugzilla.redhat.com/show_bug.cgi?id=638477#c94
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

does fedora maven eclipse plugin work?

[Marius Andreiana]

Hi,

Trying to clarify this here instead of bugzilla...

After a
yum -y install 'java-*-openjdk-devel' eclipse-anyedit eclipse-checkstyle
eclipse-dtp eclipse-emf eclipse-jdt eclipse-mylyn eclipse-mylyn-java
eclipse-platform eclipse-pydev eclipse-pydev-mylyn eclipse-subclipse
eclipse-svnkit maven-eclipse-plugin

and using eclipse with a new user account, it doesn't appear to have the
plugin setup. e.g. File -> Import -> Maven is missing. File -> New -> Other
-> Maven is also missing.

Am *I* missing something? :)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: NFS in rawhide

[Peter Jones]

> Quick question. I always had NFS starting on startup on a particular
> rawhide box. Today it didn't, and I notice that /etc/rc2|3.d/S390nfs was
> missing aswell. Did something remove these links and not replace them?

This isn't really the list for help questions.

-- 
Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: does fedora maven eclipse plugin work?

[Stanislav Ochotnicky]

On 11/17/2010 06:52 PM, Marius Andreiana wrote:
> Hi,
> 
> Trying to clarify this here instead of bugzilla...
> 
> After a
> yum -y install 'java-*-openjdk-devel' eclipse-anyedit eclipse-checkstyle
> eclipse-dtp eclipse-emf eclipse-jdt eclipse-mylyn eclipse-mylyn-java
> eclipse-platform eclipse-pydev eclipse-pydev-mylyn eclipse-subclipse
> eclipse-svnkit maven-eclipse-plugin
> 
> and using eclipse with a new user account, it doesn't appear to have the
> plugin setup. e.g. File -> Import -> Maven is missing. File -> New -> Other
> -> Maven is also missing.
> 
> Am *I* missing something? :)

I believe you are a bit mistaken. maven-eclipse-plugin is plugin *for*
maven to support creating eclipse project files from pom.xml [1]

There must be other package you are looking for, but I'll let someone
else answer that part of you inquiry (since I have no idea :-) ).


[1] http://maven.apache.org/plugins/maven-eclipse-plugin/


-- 
Stanislav Ochotnicky 
Associate Software Engineer - Base Operating Systems Brno

PGP: 71A1677C
Red Hat Inc.   http://cz.redhat.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: does fedora maven eclipse plugin work?

[Marius Andreiana]

On Wed , Nov 17, 2010 at 8:22 PM, Stanislav Ochotnicky <
sochotni...@redhat.com> wrote:

> On 11/17/2010 06:52 PM, Marius Andreiana wrote:
> > Hi,
> >
> > Trying to clarify this here instead of bugzilla...
> >
> > After a
> > yum -y install 'java-*-openjdk-devel' eclipse-anyedit eclipse-checkstyle
> > eclipse-dtp eclipse-emf eclipse-jdt eclipse-mylyn eclipse-mylyn-java
> > eclipse-platform eclipse-pydev eclipse-pydev-mylyn eclipse-subclipse
> > eclipse-svnkit maven-eclipse-plugin
> >
> > and using eclipse with a new user account, it doesn't appear to have the
> > plugin setup. e.g. File -> Import -> Maven is missing. File -> New ->
> Other
> > -> Maven is also missing.
> >
> > Am *I* missing something? :)
>
> I believe you are a bit mistaken. maven-eclipse-plugin is plugin *for*
> maven to support creating eclipse project files from pom.xml [1]
>
> There must be other package you are looking for, but I'll let someone
> else answer that part of you inquiry (since I have no idea :-) ).
>
Ah, I was looking for http://m2eclipse.sonatype.org/ , guess this isn't
packaged
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: NFS in rawhide

[Jon Masters]

On Wed, 2010-11-17 at 13:12 -0500, Peter Jones wrote:
> > Quick question. I always had NFS starting on startup on a particular
> > rawhide box. Today it didn't, and I notice that /etc/rc2|3.d/S390nfs was
> > missing aswell. Did something remove these links and not replace them?
> 
> This isn't really the list for help questions.

And I wasn't asking for help. I'm more than able to install and run my
NFS server. I was politely asking if someone poking at init scripts
affected NFS in the process. But whatever, if it's somehow bothering
that I even ask, I'll just not bother next time.

Jon.



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Petrus de Calguarium]

Hans de Goede wrote:

> The problem has been analyzed and is known, as well as a fix for it, see:
> https://bugzilla.redhat.com/show_bug.cgi?id=638477

This worked perfectly on my x86_64 system. I will try later on the i686 laptop.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: NFS in rawhide

[Ric Wheeler]

On 11/17/2010 02:02 PM, Jon Masters wrote:
> On Wed, 2010-11-17 at 13:12 -0500, Peter Jones wrote:
>>> Quick question. I always had NFS starting on startup on a particular
>>> rawhide box. Today it didn't, and I notice that /etc/rc2|3.d/S390nfs was
>>> missing aswell. Did something remove these links and not replace them?
>> This isn't really the list for help questions.
> And I wasn't asking for help. I'm more than able to install and run my
> NFS server. I was politely asking if someone poking at init scripts
> affected NFS in the process. But whatever, if it's somehow bothering
> that I even ask, I'll just not bother next time.
>
> Jon.
>

We definitely do want to know if NFS breaks in rawhide and did respond, 
definitely not a waste of time.

Thanks!

Ric

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Adobe fix on QA/QE: Fixing the glibc adobe flash incompatibility

[Magnus Glantz]

Hi guys,

I just got an e-mail from Adobe that:
1) They have a fix
2) The fix has been send to QA/QE

They say that they cannot commit to any dates, but that they are taking 
the issue seriously.

I told them that if they want volunteers trying out their fix, we can help.

Cheers,
Magnus Glantz
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: does fedora maven eclipse plugin work?

[Alexander Kurtakov]

On 09:20:18 pm Wednesday, November 17, 2010 Marius Andreiana wrote:
> On Wed , Nov 17, 2010 at 8:22 PM, Stanislav Ochotnicky <
> 
> sochotni...@redhat.com> wrote:
> > On 11/17/2010 06:52 PM, Marius Andreiana wrote:
> > > Hi,
> > > 
> > > Trying to clarify this here instead of bugzilla...
> > > 
> > > After a
> > > yum -y install 'java-*-openjdk-devel' eclipse-anyedit
> > > eclipse-checkstyle eclipse-dtp eclipse-emf eclipse-jdt eclipse-mylyn
> > > eclipse-mylyn-java eclipse-platform eclipse-pydev eclipse-pydev-mylyn
> > > eclipse-subclipse eclipse-svnkit maven-eclipse-plugin
> > > 
> > > and using eclipse with a new user account, it doesn't appear to have
> > > the plugin setup. e.g. File -> Import -> Maven is missing. File -> New
> > > ->
> > 
> > Other
> > 
> > > -> Maven is also missing.
> > > 
> > > Am *I* missing something? :)
> > 
> > I believe you are a bit mistaken. maven-eclipse-plugin is plugin *for*
> > maven to support creating eclipse project files from pom.xml [1]
> > 
> > There must be other package you are looking for, but I'll let someone
> > else answer that part of you inquiry (since I have no idea :-) ).
> 
> Ah, I was looking for http://m2eclipse.sonatype.org/ , guess this isn't
> packaged

Are you interested in helping us getting m2eclipse packaged and available on 
Fedora?
If yes please join #fedora-java on freenode.net or say so on this mailing list 
and I'll help as much as possible for this to become a reality.

Alexander Kurtakov
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: NFS in rawhide

[Jon Masters]

On Wed, 2010-11-17 at 14:14 -0500, Ric Wheeler wrote:
> On 11/17/2010 02:02 PM, Jon Masters wrote:
> > On Wed, 2010-11-17 at 13:12 -0500, Peter Jones wrote:
> >>> Quick question. I always had NFS starting on startup on a particular
> >>> rawhide box. Today it didn't, and I notice that /etc/rc2|3.d/S390nfs was
> >>> missing aswell. Did something remove these links and not replace them?
> >> This isn't really the list for help questions.
> > And I wasn't asking for help. I'm more than able to install and run my
> > NFS server. I was politely asking if someone poking at init scripts
> > affected NFS in the process. But whatever, if it's somehow bothering
> > that I even ask, I'll just not bother next time.

> We definitely do want to know if NFS breaks in rawhide and did respond, 
> definitely not a waste of time.

Yes, thanks Ric, your reply to me was most helpful.

Jon.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Bruno Wolff III]

On Wed, Nov 17, 2010 at 08:57:20 +0100,
  Hans de Goede  wrote:
> Hi all,
> 
> For those who do not know it yet, recent Fedora glibc updates include
> an optimized memcpy (which gets used on some processors) which breaks the
> 64 bit adobe flash plugin.

I saw memcpy / memmove issues affecting squashfs-tools shortly before the
F14 alpha. So we had some what of a heads up about the issue over three
months ago. It is unfortunate that we didn't catch the flash issue during
prerelease testing of F14. If this really is an important critera for
releases, maybe we should be having QA testing that flash works.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Review swap

[Jiri Popelka]

Both taken (thanks Jussi).

Jiri

On 11/17/2010 01:02 PM, Jiri Popelka wrote:
> Hi,
>
> I have two easy python modules to review.
>
> python-cups - Python bindings for the CUPS API, known as pycups
> https://bugzilla.redhat.com/show_bug.cgi?id=648986
>
> python-smbc - Python bindings for the libsmbclient API from Samba, known
> as pysmbc
> https://bugzilla.redhat.com/show_bug.cgi?id=648987
>
> Anyone interested in review swap ?
>
> Jiri
>

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Summary/Minutes from today's FESCo meeting (2010-11-17)

[Kevin Fenzi]

===
#fedora-meeting: FESCO (2010-11-17)
===

Meeting started by nirik at 18:30:00 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2010-11-17/fesco.2010-11-17-18.30.log.html

Meeting summary
---
* init process  (nirik, 18:30:01)
  * townhall with the fesco election candidates tomorrow at 1500
UTC/10AM EST.  (nirik, 18:31:54)

* Updates policy / Vision implementation status  (nirik, 18:33:09)
  * ACTION: nirik to try and remove redundant wiki pages and mark things
that are old.  (nirik, 18:37:14)
  * ACTION: ajax and nirik to try and remove redundant wiki pages and
mark things that are old.  (nirik, 18:38:43)
  * ACTION: nirik to check with the Board about the updates policy.
(nirik, 18:49:15)

* #493 Hatari update exception request  (nirik, 18:57:23)
  * AGREED: This package is granted an exception. Thanks for asking.
(nirik, 19:08:39)

* #494 F15Feature: BoxGrinder -
  http://fedoraproject.org/wiki/Features/BoxGrinder  (nirik, 19:09:10)
  * AGREED: Feature is approved.  (nirik, 19:13:00)

* #495 F15Feature: CloudFS -
  http://fedoraproject.org/wiki/Features/CloudFS  (nirik, 19:13:13)
  * AGREED: Feature is approved.  (nirik, 19:15:19)

* #496 F15Feature: ConsistentNetworkDeviceNaming -
  http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
  (nirik, 19:16:29)
  * AGREED: Feature is approved.  (nirik, 19:21:04)

* #497 F15Feature: Gnome3 -
  http://fedoraproject.org/wiki/Features/Gnome3  (nirik, 19:22:35)

* #498 F15Feature: LessFS -
  http://fedoraproject.org/wiki/Features/LessFS  (nirik, 19:39:23)
  * AGREED: Feature is approved.  (nirik, 19:42:33)

* #499 F15Feature: Ocaml3.12 -
  http://fedoraproject.org/wiki/Features/OCaml3.12  (nirik, 19:44:06)
  * AGREED: Feature is approved.  (nirik, 19:46:18)

* #500 F15Feature: Xfce48 -
  http://fedoraproject.org/wiki/Features/Xfce48  (nirik, 19:46:40)
  * AGREED: Feature is approved.  (nirik, 19:48:23)

* Open Floor  (nirik, 19:48:57)

Meeting ended at 19:55:22 UTC.




Action Items

* nirik to try and remove redundant wiki pages and mark things that are
  old.
* ajax and nirik to try and remove redundant wiki pages and mark things
  that are old.
* nirik to check with the Board about the updates policy.




Action Items, by person
---
* ajax
  * ajax and nirik to try and remove redundant wiki pages and mark
things that are old.
* nirik
  * nirik to try and remove redundant wiki pages and mark things that
are old.
  * ajax and nirik to try and remove redundant wiki pages and mark
things that are old.
  * nirik to check with the Board about the updates policy.
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* nirik (131)
* kylem (53)
* cwickert (51)
* pjones (44)
* ajax (43)
* mjg59 (38)
* notting (37)
* mclasen_ (28)
* zodbot (15)
* rwmjones (6)
* gholms (5)
* jonmasters (3)
* mdomsch (3)
* rbergeron (2)
* skvidal (2)
* mgoldmann (2)
* drago01 (2)
* rdieter (1)
* tibbs (1)
* dinnes (1)
* mclasen (0)
* SMParrish (0)
--
18:30:00  #startmeeting FESCO (2010-11-17)
18:30:00  Meeting started Wed Nov 17 18:30:00 2010 UTC.  The chair is 
nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:30:00  Useful Commands: #action #agreed #halp #info #idea #link 
#topic.
18:30:01  #meetingname fesco
18:30:01  The meeting name has been set to 'fesco'
18:30:01  #chair mclasen notting nirik SMParrish kylem ajax pjones 
cwickert mjg59
18:30:01  #topic init process
18:30:01  Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 
nirik notting pjones
18:30:21  who all is around for fesco meeting time?
18:30:24  ouch
18:30:29  Hi
18:30:30  that late already?
18:30:31  I'm right here.
18:30:38  yo
18:30:49  I'm here ..
18:31:11  just like to remind everyone we're doing a townhall with the 
fesco election candidates tomorrow at 1500 UTC/10AM EST.
18:31:11  Uh, I think so Brain, but this time, you wear the tutu.
18:31:33  kylem: thanks for organizing that.
18:31:36  np.
18:31:54  #info townhall with the fesco election candidates tomorrow at 
1500 UTC/10AM EST.
18:32:55  ok, I guess lets go ahead and dive in.
18:33:09  #topic Updates policy / Vision implementation status
18:33:09  .fesco 351
18:33:10  .fesco 382
18:33:11  nirik: #351 (Create a policy for updates) - FESCo - Trac - 
https://fedorahosted.org/fesco/ticket/351
18:33:14  nirik: #382 (Implementing Stable Release Vision) - FESCo - 
Trac - https://fedorahosted.org/fesco/ticket/382
18:33:18  Our fav tickets. ;)
18:33:33  SMParrish: any news on metics?
18:34:01  cwickert: were you working on a features repo proposal?
18:34:17  nirik, nope, no time
18:34:25  More discussion on list about older stable releases not 
finding testers...
18:34:32  nirik, have we cleaned up the wiki?
18:35:07  not sure. was I supposed to do that?
18:35:11 * nirik looks back at action items.
18:36:14  not sur

Re: Fixing the glibc adobe flash incompatibility

[Josh Boyer]

On Wed, Nov 17, 2010 at 2:28 PM, Bruno Wolff III  wrote:
> On Wed, Nov 17, 2010 at 08:57:20 +0100,
>  Hans de Goede  wrote:
>> Hi all,
>>
>> For those who do not know it yet, recent Fedora glibc updates include
>> an optimized memcpy (which gets used on some processors) which breaks the
>> 64 bit adobe flash plugin.
>
> I saw memcpy / memmove issues affecting squashfs-tools shortly before the
> F14 alpha. So we had some what of a heads up about the issue over three
> months ago. It is unfortunate that we didn't catch the flash issue during
> prerelease testing of F14. If this really is an important critera for
> releases, maybe we should be having QA testing that flash works.

I will be very, very, disappointed if that gets added as a criteria
for a Fedora release.  It would be no different than making sure the
nvidia driver works, and we certainly shouldn't be doing that either.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plan for tomorrow's FESCo meeting (2010-11-17)

[Kevin Fenzi]

On Wed, 17 Nov 2010 08:13 +0100
Kevin Kofler  wrote:

> Kevin Fenzi wrote:
> > * F12 critical path/update testing issues. (does it matter this
> > close to EOL?)
> 
> Now Fedora n-1 is F13 and we're already seeing the same sort of
> issues there (e.g. the KDE 4.5.3 (non-critpath) bugfix update has
> karma 4 on F14 and 0 on F13).

So, there are no folks in the KDE sig using F13 anymore? 

Perhaps call for testers in the users / kde lists?

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Jon Masters]

On Wed, 2010-11-17 at 08:57 +0100, Hans de Goede wrote:

> This solution could be reverting the problem causing glibc change, or
> maybe changing it to do forward memcpy's while still using the new SSE
> instructions, or something more specific to the flash plugin, as long
> as it will automatically fix things with a yum upgrade without requiring
> any further user intervention.
> 
> I would also like to point out that if this were to happen in Ubuntu
> which we sometimes look at jealously for getting more attention / users
> then us, the glibc change would likely be reverted immediately, as that
> is the right thing to do from an end user pov.
> 
> I've filed a ticket for FESCo to look into this, as I believe this
> makes us look really bad, and the glibc maintainers do not seem to be
> willing to fix it without some sort of intervention:
> https://fedorahosted.org/fesco/ticket/501

Did anyone upstream look into a compatibility environment variable that
could be exported to change the direction of the memcpy? Yes, it's a
hack, but it would allow affected users to have an option.

Alternatively, I agree that this is one case where a wrapper hack would
also work for the flash plugin. I suspect, however, that other projects
will be affected and so a generic solution would help.

Jon.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Magnus Glantz]

On 11/17/2010 09:09 PM, Josh Boyer wrote:
> On Wed, Nov 17, 2010 at 2:28 PM, Bruno Wolff III  wrote:
>> On Wed, Nov 17, 2010 at 08:57:20 +0100,
>>   Hans de Goede  wrote:
>>> Hi all,
>>>
>>> For those who do not know it yet, recent Fedora glibc updates include
>>> an optimized memcpy (which gets used on some processors) which breaks the
>>> 64 bit adobe flash plugin.
>> I saw memcpy / memmove issues affecting squashfs-tools shortly before the
>> F14 alpha. So we had some what of a heads up about the issue over three
>> months ago. It is unfortunate that we didn't catch the flash issue during
>> prerelease testing of F14. If this really is an important critera for
>> releases, maybe we should be having QA testing that flash works.
> I will be very, very, disappointed if that gets added as a criteria
> for a Fedora release.  It would be no different than making sure the
> nvidia driver works, and we certainly shouldn't be doing that either.
>
> josh
I can relate to that. I'm all for pure open source, but..

I really can't see why it would be a bad thing Fedora would do QA on a 
proprietary software that is very important for a majority of the Fedora 
users.
If we'd have an open source flash player that almost everyone could run 
as a substitute, then it would be a different situation. I would say 
that is the case regarding Nvidia.

Cheers,
Magnus

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Josh Boyer]

On Wed, Nov 17, 2010 at 3:16 PM, Jon Masters  wrote:
> On Wed, 2010-11-17 at 08:57 +0100, Hans de Goede wrote:
>
>> This solution could be reverting the problem causing glibc change, or
>> maybe changing it to do forward memcpy's while still using the new SSE
>> instructions, or something more specific to the flash plugin, as long
>> as it will automatically fix things with a yum upgrade without requiring
>> any further user intervention.
>>
>> I would also like to point out that if this were to happen in Ubuntu
>> which we sometimes look at jealously for getting more attention / users
>> then us, the glibc change would likely be reverted immediately, as that
>> is the right thing to do from an end user pov.
>>
>> I've filed a ticket for FESCo to look into this, as I believe this
>> makes us look really bad, and the glibc maintainers do not seem to be
>> willing to fix it without some sort of intervention:
>> https://fedorahosted.org/fesco/ticket/501
>
> Did anyone upstream look into a compatibility environment variable that
> could be exported to change the direction of the memcpy? Yes, it's a
> hack, but it would allow affected users to have an option.
>
> Alternatively, I agree that this is one case where a wrapper hack would
> also work for the flash plugin. I suspect, however, that other projects
> will be affected and so a generic solution would help.

Other FOSS projects?  That people can send patches to fix the broken
use of memcpy to?  Seems the generic solution is exactly that.  If
you're talking about closed source applications, then I'm confused
because I thought Fedora, as a project, did not care.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: NFS in rawhide

[Clyde E. Kunkel]

On 11/17/2010 02:26 PM, Jon Masters wrote:
> On Wed, 2010-11-17 at 14:14 -0500, Ric Wheeler wrote:
>>
>
> Yes, thanks Ric, your reply to me was most helpful.
>
> Jon.

What was the reply?

TIA

Regards,
OldFart
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Bruno Wolff III]

On Wed, Nov 17, 2010 at 09:23:49 -0500,
  "Tom \"spot\" Callaway"  wrote:
> Here are the list of recent changes to the Fedora Packaging Guidelines:
> 
> https://fedoraproject.org/wiki/Packaging:Java
> Diff:
> https://fedoraproject.org/w/index.php?title=Packaging%3AJava&diff=206526&oldid=154023

Should we do new releases for this, or just make changes when doing an
update for other reasons? In my case I have some gjc stuff, that should
be dropped according to the updated guidelines.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

RE: Fixing the glibc adobe flash incompatibility

[Ugis Fedora]

> From: jonat...@jonmasters.org
> To: devel@lists.fedoraproject.org
> Date: Wed, 17 Nov 2010 15:16:20 -0500
> Subject: Re: Fixing the glibc adobe flash incompatibility
> CC: fedora-devel-l...@redhat.com
> 
> On Wed, 2010-11-17 at 08:57 +0100, Hans de Goede wrote:
> 
> > This solution could be reverting the problem causing glibc change, or
> > maybe changing it to do forward memcpy's while still using the new SSE
> > instructions, or something more specific to the flash plugin, as long
> > as it will automatically fix things with a yum upgrade without requiring
> > any further user intervention.
> > 
> > I would also like to point out that if this were to happen in Ubuntu
> > which we sometimes look at jealously for getting more attention / users
> > then us, the glibc change would likely be reverted immediately, as that
> > is the right thing to do from an end user pov.
> > 
> > I've filed a ticket for FESCo to look into this, as I believe this
> > makes us look really bad, and the glibc maintainers do not seem to be
> > willing to fix it without some sort of intervention:
> > https://fedorahosted.org/fesco/ticket/501

Isn't only 64-bit preview release affected?
from adobe's website...http://labs.adobe.com/technologies/flashplayer10/
>>We have made this preview available so that users can test existing content 
>>and new platforms for compatibility and stability. Because this is a preview 
>>version of Flash Player, we don’t expect it >>to be as stable as a final 
>>release version of Flash Player. Use caution when installing Flash Player 
>>"Square" on production machines.
If they don't expect it to work properly why should we? 
  -- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Emmanuel Seyman]

* Magnus Glantz [17/11/2010 21:33] :
>
> I really can't see why it would be a bad thing Fedora would do QA on a 
> proprietary software that is very important for a majority of the Fedora 
> users.

1) Time spent doing QA on proprietary software is time that will not be
   spent doing QA on free software
2) Issues found in proprietary software cannot be fixed by anybody except
   the vendor

Emmanuel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Magnus Glantz]

On 11/17/2010 09:30 PM, Ugis Fedora wrote:



> From: jonat...@jonmasters.org
> To: devel@lists.fedoraproject.org
> Date: Wed, 17 Nov 2010 15:16:20 -0500
> Subject: Re: Fixing the glibc adobe flash incompatibility
> CC: fedora-devel-l...@redhat.com
>
> On Wed, 2010-11-17 at 08:57 +0100, Hans de Goede wrote:
>
> > This solution could be reverting the problem causing glibc change, or
> > maybe changing it to do forward memcpy's while still using the new SSE
> > instructions, or something more specific to the flash plugin, as long
> > as it will automatically fix things with a yum upgrade without 
requiring

> > any further user intervention.
> >
> > I would also like to point out that if this were to happen in Ubuntu
> > which we sometimes look at jealously for getting more attention / 
users
> > then us, the glibc change would likely be reverted immediately, as 
that

> > is the right thing to do from an end user pov.
> >
> > I've filed a ticket for FESCo to look into this, as I believe this
> > makes us look really bad, and the glibc maintainers do not seem to be
> > willing to fix it without some sort of intervention:
> > https://fedorahosted.org/fesco/ticket/501

Isn't only 64-bit preview release affected?

from adobe's website...
http://labs.adobe.com/technologies/flashplayer10/

>>We have made this preview available so that users can test existing 
content and new platforms for compatibility and stability. Because 
this is a preview version of Flash Player, we don’t expect it >>to be 
as stable as a final release version of Flash Player. Use caution when 
installing Flash Player "Square" on production machines.


If they don't expect it to work properly why should we?
Because a large part of the Fedora users, uses the flash plugin from 
Adobe, and if it does not work, they will go off and find a distribution 
where it does work. With less people using Fedora, the project becomes 
less successful, as less people will be contributing.
For me it's natural that we should care about the end-user experience of 
Fedora, even if that does include us caring about application outside of 
the Fedora owned repositories.


Cheers,
Magnus
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[mike cloaked]

On Wed, Nov 17, 2010 at 8:44 PM, Magnus Glantz  wrote:

> For me it's natural that we should care about the end-user experience of
> Fedora, even if that does include us caring about application outside of the
> Fedora owned repositories.

Just a thought - but for those users who use chrome/chromium as prime
browser where flash is part of the deal - would they install Adobe
flash as well?  i.e. would they even notice if Adobe flash-plugin was
not working?

-- 
mike c
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[François Cami]

On Wed, Nov 17, 2010 at 9:21 PM, Magnus Glantz  wrote:
> On 11/17/2010 09:09 PM, Josh Boyer wrote:
>> On Wed, Nov 17, 2010 at 2:28 PM, Bruno Wolff III  wrote:
>>> On Wed, Nov 17, 2010 at 08:57:20 +0100,
>>>   Hans de Goede  wrote:

 For those who do not know it yet, recent Fedora glibc updates include
 an optimized memcpy (which gets used on some processors) which breaks the
 64 bit adobe flash plugin.
>>> I saw memcpy / memmove issues affecting squashfs-tools shortly before the
>>> F14 alpha. So we had some what of a heads up about the issue over three
>>> months ago. It is unfortunate that we didn't catch the flash issue during
>>> prerelease testing of F14. If this really is an important critera for
>>> releases, maybe we should be having QA testing that flash works.
>> I will be very, very, disappointed if that gets added as a criteria
>> for a Fedora release.  It would be no different than making sure the
>> nvidia driver works, and we certainly shouldn't be doing that either.
>
> I can relate to that. I'm all for pure open source, but..
>
> I really can't see why it would be a bad thing Fedora would do QA on a
> proprietary software that is very important for a majority of the Fedora
> users.
> If we'd have an open source flash player that almost everyone could run
> as a substitute, then it would be a different situation. I would say
> that is the case regarding Nvidia.

IIRC broken proprietary drivers never stopped us from shipping, but I
could be wrong.

Furthermore, no proprietary software vendor supports Fedora timely and
fixes for issues like this one take months (from their own estimate).
So by making sure proprietary software works, we could break the
"First" Foundation.

I would also argue we would break the "Freedom" Foundation, because
proprietary software may limit what Fedora can do.

On the other hand, proprietary software-related bugs found before the
release would probably receive some attention (and could be forwarded
to the vendor accordingly), so anyone is free to test whatever they
use and file bugs.

I am not saying that we should refrain users from testing proprietary
software - but we should not make it part of the release criteria.

François
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Bruno Wolff III]

On Wed, Nov 17, 2010 at 21:46:09 +0100,
  François Cami  wrote:
> 
> IIRC broken proprietary drivers never stopped us from shipping, but I
> could be wrong.

Officially. Unofficially, it was probably a contributing factor.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Alexander Kurtakov]

On 10:51:26 pm Wednesday, November 17, 2010 Bruno Wolff III wrote:
> On Wed, Nov 17, 2010 at 09:23:49 -0500,
> 
>   "Tom \"spot\" Callaway"  wrote:
> > Here are the list of recent changes to the Fedora Packaging Guidelines:
> > 
> > https://fedoraproject.org/wiki/Packaging:Java
> > Diff:
> > https://fedoraproject.org/w/index.php?title=Packaging%3AJava&diff=206526&;
> > oldid=154023
> 
> Should we do new releases for this, or just make changes when doing an
> update for other reasons? In my case I have some gjc stuff, that should
> be dropped according to the updated guidelines.

I think that it should be fine if you do the changes when you have other 
reasons too.

Alexander Kurtakov
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Magnus Glantz]

On 11/17/2010 09:46 PM, François Cami wrote:
> On Wed, Nov 17, 2010 at 9:21 PM, Magnus Glantz  wrote:
>> On 11/17/2010 09:09 PM, Josh Boyer wrote:
>>> On Wed, Nov 17, 2010 at 2:28 PM, Bruno Wolff IIIwrote:
 On Wed, Nov 17, 2010 at 08:57:20 +0100,
Hans de Goedewrote:
> For those who do not know it yet, recent Fedora glibc updates include
> an optimized memcpy (which gets used on some processors) which breaks the
> 64 bit adobe flash plugin.
 I saw memcpy / memmove issues affecting squashfs-tools shortly before the
 F14 alpha. So we had some what of a heads up about the issue over three
 months ago. It is unfortunate that we didn't catch the flash issue during
 prerelease testing of F14. If this really is an important critera for
 releases, maybe we should be having QA testing that flash works.
>>> I will be very, very, disappointed if that gets added as a criteria
>>> for a Fedora release.  It would be no different than making sure the
>>> nvidia driver works, and we certainly shouldn't be doing that either.
>> I can relate to that. I'm all for pure open source, but..
>>
>> I really can't see why it would be a bad thing Fedora would do QA on a
>> proprietary software that is very important for a majority of the Fedora
>> users.
>> If we'd have an open source flash player that almost everyone could run
>> as a substitute, then it would be a different situation. I would say
>> that is the case regarding Nvidia.
> IIRC broken proprietary drivers never stopped us from shipping, but I
> could be wrong.
>
> Furthermore, no proprietary software vendor supports Fedora timely and
> fixes for issues like this one take months (from their own estimate).
> So by making sure proprietary software works, we could break the
> "First" Foundation.
>
> I would also argue we would break the "Freedom" Foundation, because
> proprietary software may limit what Fedora can do.
>
> On the other hand, proprietary software-related bugs found before the
> release would probably receive some attention (and could be forwarded
> to the vendor accordingly), so anyone is free to test whatever they
> use and file bugs.
>
> I am not saying that we should refrain users from testing proprietary
> software - but we should not make it part of the release criteria.
>
> François
I'm not saying that a broken Adobe Flash would stop Fedora from shipping.

But.. if we notice that it's broken, we can:
1) Notify Adobe about it, so they -can- provide a fix. If they do not 
know, they can't fix it.. The Adobe developers I e-mailed with did say 
that they took the issue seriously, they want it to work on Fedora, as 
I'm sure a lot people/companies would.
2) Create a work-around for the end-users (as has been done by several 
people in the BZ #638477-thread)
There's nothing bad about that is it?

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Jóhann B. Guðmundsson]

On 11/17/2010 08:58 PM, Magnus Glantz wrote:
> But.. if we notice that it's broken, we can:
> 1) Notify Adobe about it, so they -can- provide a fix. If they do not
> know, they can't fix it.. The Adobe developers I e-mailed with did say
> that they took the issue seriously, they want it to work on Fedora, as
> I'm sure a lot people/companies would.
> 2) Create a work-around for the end-users (as has been done by several
> people in the BZ #638477-thread)
> There's nothing bad about that is it?

3. Spend that time working on open alternative and get rid of flash for 
good

JBG
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Guidelines Change] Changes to the Packaging Guidelines

[Tom "spot" Callaway]

Here are the list of this week's changes to the Fedora Packaging Guidelines:

The FPC has taken over evaluating exceptions to the Bundled Library
Guidelines.  A list of standard questions to be answered to give the FPC
information on whether to grant exceptions has been added to the
Guidelines:

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Standard_questions

---

An exception was added to the Guidelines concerning use of
%{_sourcedir}, specifically, when there is an available list of
supplementary source files, it is permissible to use this list in
conjunction with %{sourcedir} to simplify operations on those
supplementary source files.

https://fedoraproject.org/wiki/Packaging:RPM_Source_Dir

---

rpm %post and %postun scripts have been added for the following
important pieces of GNOME3 technology: GSettings, gdk-pixbuf loaders,
GTK3 modules, and GIO modules:

https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GSettings_Schema
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#gdk-
 pixbuf_loaders
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GTK.2B_modules
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GIO_modules

---

These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).

Many thanks to Kevin Kofler, Matthias Clasen, FESCo and all of the
members of the FPC, for assisting in drafting, refining, and passing
these guidelines.

As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
http://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure

Thanks,

~spot
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: does fedora maven eclipse plugin work?

[Marius Andreiana]

On Wed, Nov 17, 2010 at 9:22 PM, Alexander Kurtakov wrote:

> Are you interested in helping us getting m2eclipse packaged and available
> on
> Fedora?

If yes please join #fedora-java on freenode.net or say so on this mailing
> list
> and I'll help as much as possible for this to become a reality.
>
Without making any promises, I'll add this to my TODO list. I'll write to
you in ~1 month requesting help on it, if nobody took it on until then.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Michael Cronenworth]

"Jóhann B. Guðmundsson" wrote:
> 3. Spend that time working on open alternative and get rid of flash for
> good

Write a cross-platform IDE for HTML5-based technologies. Of course it 
would also require a fast Javascript JIT engine, which has been frowned 
upon[1], so I don't know if there is a make-everyone-happy solution. 
Someone will have to have their feelings hurt.

[1] http://www.spinics.net/lists/fedora-devel/msg141194.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Benjamin Kreuter]

On Wednesday 17 November 2010 15:21:55 Magnus Glantz wrote:
> On 11/17/2010 09:09 PM, Josh Boyer wrote:
> > On Wed, Nov 17, 2010 at 2:28 PM, Bruno Wolff III  wrote:
> >> On Wed, Nov 17, 2010 at 08:57:20 +0100,
> >> 
> >>   Hans de Goede  wrote:
> >>> Hi all,
> >>> 
> >>> For those who do not know it yet, recent Fedora glibc updates include
> >>> an optimized memcpy (which gets used on some processors) which breaks
> >>> the 64 bit adobe flash plugin.
> >> 
> >> I saw memcpy / memmove issues affecting squashfs-tools shortly before
> >> the F14 alpha. So we had some what of a heads up about the issue over
> >> three months ago. It is unfortunate that we didn't catch the flash
> >> issue during prerelease testing of F14. If this really is an important
> >> critera for releases, maybe we should be having QA testing that flash
> >> works.
> > 
> > I will be very, very, disappointed if that gets added as a criteria
> > for a Fedora release.  It would be no different than making sure the
> > nvidia driver works, and we certainly shouldn't be doing that either.
> > 
> > josh
> 
> I can relate to that. I'm all for pure open source, but..
> 
> I really can't see why it would be a bad thing Fedora would do QA on a
> proprietary software that is very important for a majority of the Fedora
> users.

We do not want to wind up on Adobe's schedule -- the problem is on Adobe's 
end, not ours, and we cannot even send them a fix.  The behavior of memcpy for 
overlapping ranges is not even defined, so there should be nothing stopping us 
from using a new implementation of memcpy.  The fact that a lot of people use 
the Flash plugin makes it even more important for *Adobe* to fix what can only 
be described as a bug in Flash, which is the current reliance on undefined 
behavior.

-- Ben



-- 
Message sent on: Wed Nov 17 15:57:16 EST 2010


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: Ubuntu moving towards Wayland

[Kevin Kofler]

Nicolas Mailhot wrote:
> Well it would be mightily nice to have an infrastructure that can handle
> keyboard extended keys (almost every new keyboard sold in the last
> decade has one or more of those) without barfing because the original
> x11 protocol designers thought 8 bits would be enough for everyone.

This complaint is obsolete, XI2 supports 32-bit keycodes.
http://www.x.org/wiki/XI2

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

how to debug sound not working on macbook?

[Marius Andreiana]

Does anybody have suggestions how an end user could debug this?
https://bugzilla.redhat.com/show_bug.cgi?id=580703

Thanks!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Magnus Glantz]

On 11/17/2010 10:02 PM, "Jóhann B. Guðmundsson" wrote:
> On 11/17/2010 08:58 PM, Magnus Glantz wrote:
>> But.. if we notice that it's broken, we can:
>> 1) Notify Adobe about it, so they -can- provide a fix. If they do not
>> know, they can't fix it.. The Adobe developers I e-mailed with did say
>> that they took the issue seriously, they want it to work on Fedora, as
>> I'm sure a lot people/companies would.
>> 2) Create a work-around for the end-users (as has been done by several
>> people in the BZ #638477-thread)
>> There's nothing bad about that is it?
> 3. Spend that time working on open alternative and get rid of flash for
> good
>
> JBG
Absolutely. This does in a good way show the dangers of being dependent 
on a closed source piece of software, owned by a company that most 
probably won't fix something if it does not affect their business.

But first things first.
//M
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[John Reiser]

On 11/17/2010 12:41 PM, Emmanuel Seyman wrote:
> 2) Issues found in proprietary software cannot be fixed by anybody except
>the vendor

False.  In this particular case, it is possible to binary edit the plugin
libflashplayer.so so that all its calls to memcpy become calls to memmove.
The change is to copy the .st_name field from the symbol for memmove to the
.st_name field of the symbol for memcpy, which creates another instance
of memmove.   With that one 32-bit change, then the player will work.
Memmove can be a few percent slower than memcpy, but nobody will notice.

If the plugin did not have a reference to memmove already, then on x86_64
an impostor can be created by introducing the name "memmove\0" at
&{DT_NULL}.d_un.  This is a generic work-around for this particular
issue with memcpy on x86_64.

-- 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Benjamin Kreuter]

On Wednesday 17 November 2010 15:58:28 Magnus Glantz wrote:
> I'm not saying that a broken Adobe Flash would stop Fedora from shipping.
> 
> But.. if we notice that it's broken, we can:
> 1) Notify Adobe about it, so they -can- provide a fix. If they do not
> know, they can't fix it.. The Adobe developers I e-mailed with did say
> that they took the issue seriously, they want it to work on Fedora, as
> I'm sure a lot people/companies would.

Sure, but they need some incentive.  Like, Flash not working without a fix, 
and lots of people complaining about it.

> 2) Create a work-around for the end-users (as has been done by several
> people in the BZ #638477-thread)

This pretty much erases whatever incentive Adobe might have to actually fix 
the bug.  Instead of fixing their code, now what they can do is use some hack 
and not bother to update anything.  It also reduces the pressure on Adobe to 
release the Flash plugin under a libre license, since it would basically 
amount to the community doing the work to fix the problem while the software 
is still under a proprietary license.

In the grand scheme of things, this is a bug that Adobe could fix pretty 
quickly, if they feel like they have a good reason to do that.  Why not put 
the burden on them?  They release proprietary software, so they take on the 
responsibility of making sure it works on the platforms they target.

-- Ben



-- 
Message sent on: Wed Nov 17 16:10:53 EST 2010


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: Fixing the glibc adobe flash incompatibility

[Jeff Spaleta]

On Wed, Nov 17, 2010 at 8:16 PM, Jon Masters  wrote:
> Did anyone upstream look into a compatibility environment variable that
> could be exported to change the direction of the memcpy? Yes, it's a
> hack, but it would allow affected users to have an option.

Could we make use of that sort of environment variable feature more
generally as a way to build environments that test for bad memcpy
usage similar to this by flipflopping back and forth, even while we
are writing code?

-jef
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Ubuntu moving towards Wayland

[Matthew Garrett]

On Wed, Nov 17, 2010 at 10:08:10PM +0100, Kevin Kofler wrote:
> Nicolas Mailhot wrote:
> > Well it would be mightily nice to have an infrastructure that can handle
> > keyboard extended keys (almost every new keyboard sold in the last
> > decade has one or more of those) without barfing because the original
> > x11 protocol designers thought 8 bits would be enough for everyone.
> 
> This complaint is obsolete, XI2 supports 32-bit keycodes.
> http://www.x.org/wiki/XI2

...but xkb doesn't, so you can't actually do anything with them.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Matthew Garrett]

On Wed, Nov 17, 2010 at 02:41:15PM -0600, Bruno Wolff III wrote:
> On Wed, Nov 17, 2010 at 21:46:09 +0100,
>   François Cami  wrote:
> > 
> > IIRC broken proprietary drivers never stopped us from shipping, but I
> > could be wrong.
> 
> Officially. Unofficially, it was probably a contributing factor.

I believe that we've frequently shipped with a sufficiently new X that 
binary nvidia and radeon drivers fail to work.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Peter Jones]

On 11/17/2010 03:41 PM, Bruno Wolff III wrote:
> On Wed, Nov 17, 2010 at 21:46:09 +0100,
>François Cami  wrote:
>>
>> IIRC broken proprietary drivers never stopped us from shipping, but I
>> could be wrong.
> 
> Officially. Unofficially, it was probably a contributing factor.

No, I don't think so.  We've certainly shipped with code that broke any given
one of these before.

-- 
Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

File Net-SNMP-v6.0.1.tar.gz uploaded to lookaside cache by spot

[Tom Callaway]

A file has been added to the lookaside cache for perl-Net-SNMP:

6137f04f9942d703f66179f890e3d096  Net-SNMP-v6.0.1.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Net-SNMP] update to 6.0.1, which removed all occurrences of the "locked" attribute, deprecated in perl 5.12.0

[Tom Callaway]

commit 493a74751626dab9e00fc77476b015b5c7b0220e
Author: Tom "spot" Callaway 
Date:   Wed Nov 17 16:36:18 2010 -0500

update to 6.0.1, which removed all occurrences of the "locked" attribute, 
deprecated in perl 5.12.0

 .gitignore |1 +
 perl-Net-SNMP.spec |   22 ++
 sources|2 +-
 3 files changed, 12 insertions(+), 13 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 434fb04..6b56836 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 Net-SNMP-5.2.0.tar.gz
+/Net-SNMP-v6.0.1.tar.gz
diff --git a/perl-Net-SNMP.spec b/perl-Net-SNMP.spec
index 72eea53..f1bbc9a 100644
--- a/perl-Net-SNMP.spec
+++ b/perl-Net-SNMP.spec
@@ -1,12 +1,12 @@
 Name:   perl-Net-SNMP
-Version:5.2.0
-Release:6%{?dist}
+Version:6.0.1
+Release:1%{?dist}
 Summary:Object oriented interface to SNMP
 
 Group:  Development/Libraries
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Net-SNMP/
-Source0:
http://www.cpan.org/authors/id/D/DT/DTOWN/Net-SNMP-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/D/DT/DTOWN/Net-SNMP-v%{version}.tar.gz
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 BuildArch:  noarch
@@ -16,6 +16,7 @@ BuildRequires:  perl(Digest::SHA1)
 BuildRequires:  perl(ExtUtils::MakeMaker)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 #Requires:   perl(Crypt::Rijndael)
+# This is autodetected.
 #Requires:   perl(Socket6)
 
 %description
@@ -29,18 +30,10 @@ Management Protocol and related network management concepts.
 
 
 %prep
-%setup -q -n Net-SNMP-%{version}
+%setup -q -n Net-SNMP-v%{version}
 %{__perl} -pi -e 's|^#!\s+/usr/local/bin/perl|#!%{__perl}|' examples/*.pl
 chmod -c a-x examples/*.pl
 
-# Requirements: exclude perl(Socket6)
-cat <<__EOF__ > %{name}-perlreq
-#!/bin/sh
-/usr/lib/rpm/perl.req \$* | grep -v '^perl(Socket6)'
-__EOF__
-%define __perl_requires %{_builddir}/Net-SNMP-%{version}/%{name}-perlreq
-chmod +x %{__perl_requires}
-
 
 %build
 %{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -73,6 +66,11 @@ rm -rf $RPM_BUILD_ROOT
 
 
 %changelog
+* Wed Nov 17 2010 Tom "spot" Callaway  - 6.0.1-1
+- update to 6.0.1, which removed all occurrences of the "locked" attribute, 
+  deprecated in perl 5.12.0
+- okay to use Socket6 now.
+
 * Tue May 04 2010 Marcela Maslanova  - 5.2.0-6
 - Mass rebuild with perl-5.12.0
 
diff --git a/sources b/sources
index 7847218..6dc24f4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-0e717723f843ab22a93248833f3ebff7  Net-SNMP-5.2.0.tar.gz
+6137f04f9942d703f66179f890e3d096  Net-SNMP-v6.0.1.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Net-SNMP/f14/master] update to 6.0.1, which removed all occurrences of the "locked" attribute, deprecated in perl 5.12.0

[Tom Callaway]

commit 78e76d0737f2985f6c00420034e2e1d2483a7f0a
Author: Tom "spot" Callaway 
Date:   Wed Nov 17 16:36:40 2010 -0500

update to 6.0.1, which removed all occurrences of the "locked" attribute, 
deprecated in perl 5.12.0

 perl-Net-SNMP.spec |   22 ++
 sources|2 +-
 2 files changed, 11 insertions(+), 13 deletions(-)
---
diff --git a/perl-Net-SNMP.spec b/perl-Net-SNMP.spec
index 72eea53..f1bbc9a 100644
--- a/perl-Net-SNMP.spec
+++ b/perl-Net-SNMP.spec
@@ -1,12 +1,12 @@
 Name:   perl-Net-SNMP
-Version:5.2.0
-Release:6%{?dist}
+Version:6.0.1
+Release:1%{?dist}
 Summary:Object oriented interface to SNMP
 
 Group:  Development/Libraries
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Net-SNMP/
-Source0:
http://www.cpan.org/authors/id/D/DT/DTOWN/Net-SNMP-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/D/DT/DTOWN/Net-SNMP-v%{version}.tar.gz
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 BuildArch:  noarch
@@ -16,6 +16,7 @@ BuildRequires:  perl(Digest::SHA1)
 BuildRequires:  perl(ExtUtils::MakeMaker)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 #Requires:   perl(Crypt::Rijndael)
+# This is autodetected.
 #Requires:   perl(Socket6)
 
 %description
@@ -29,18 +30,10 @@ Management Protocol and related network management concepts.
 
 
 %prep
-%setup -q -n Net-SNMP-%{version}
+%setup -q -n Net-SNMP-v%{version}
 %{__perl} -pi -e 's|^#!\s+/usr/local/bin/perl|#!%{__perl}|' examples/*.pl
 chmod -c a-x examples/*.pl
 
-# Requirements: exclude perl(Socket6)
-cat <<__EOF__ > %{name}-perlreq
-#!/bin/sh
-/usr/lib/rpm/perl.req \$* | grep -v '^perl(Socket6)'
-__EOF__
-%define __perl_requires %{_builddir}/Net-SNMP-%{version}/%{name}-perlreq
-chmod +x %{__perl_requires}
-
 
 %build
 %{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -73,6 +66,11 @@ rm -rf $RPM_BUILD_ROOT
 
 
 %changelog
+* Wed Nov 17 2010 Tom "spot" Callaway  - 6.0.1-1
+- update to 6.0.1, which removed all occurrences of the "locked" attribute, 
+  deprecated in perl 5.12.0
+- okay to use Socket6 now.
+
 * Tue May 04 2010 Marcela Maslanova  - 5.2.0-6
 - Mass rebuild with perl-5.12.0
 
diff --git a/sources b/sources
index 7847218..6dc24f4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-0e717723f843ab22a93248833f3ebff7  Net-SNMP-5.2.0.tar.gz
+6137f04f9942d703f66179f890e3d096  Net-SNMP-v6.0.1.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Fixing the glibc adobe flash incompatibility

[Magnus Glantz]

On 11/17/2010 10:18 PM, Benjamin Kreuter wrote:
>> 2) Create a work-around for the end-users (as has been done by several
>> people in the BZ #638477-thread)
> This pretty much erases whatever incentive Adobe might have to actually fix
> the bug.  Instead of fixing their code, now what they can do is use some hack
> and not bother to update anything.  It also reduces the pressure on Adobe to
> release the Flash plugin under a libre license, since it would basically
> amount to the community doing the work to fix the problem while the software
> is still under a proprietary license.
But what you describe did not happen just now. There was two separate 
work-arounds (one from Linus Torvalds, replacing memcpy with a custom 
version, using LD_PRELOAD, and one from Ray Strode, replacing the memcpy 
calls in the binary with memmove, using a script) but Adobe still 
notified me today that they are QA/QE:ing a fix.
> In the grand scheme of things, this is a bug that Adobe could fix pretty
> quickly, if they feel like they have a good reason to do that.  Why not put
> the burden on them?  They release proprietary software, so they take on the
> responsibility of making sure it works on the platforms they target.
>
> -- Ben
Because Adobe is not the one that pretty quickly risks loosing users. 
Ignoring flash content on the web is not done as easy as you can change 
between two Linux distributions.

As it is (I don't like it, probably no one here likes it) a majority of 
the Fedora users are dependent on Adobe Flash working in Fedora. If it 
does not work, then a lot of things they do daily, stops working.

As long as there is no open source option for the majority of these 
users, why not QA Adobe Flash before a release? It's done easily and has 
great worth to the users.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Tom "spot" Callaway]

On 11/17/2010 03:45 PM, mike cloaked wrote:
> Just a thought - but for those users who use chrome/chromium as prime
> browser where flash is part of the deal

Flash is only bundled in Google's Chrome builds, not in the FOSS
Chromium code.

~spot
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 652158] Use of :locked is deprecated

[bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=652158

--- Comment #2 from Fedora Update System  2010-11-17 
16:46:58 EST ---
perl-Net-SNMP-6.0.1-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/perl-Net-SNMP-6.0.1-1.fc14

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Fixing the glibc adobe flash incompatibility

[Bruno Wolff III]

On Wed, Nov 17, 2010 at 16:33:59 -0500,
  Peter Jones  wrote:
> On 11/17/2010 03:41 PM, Bruno Wolff III wrote:
> > On Wed, Nov 17, 2010 at 21:46:09 +0100,
> >François Cami  wrote:
> >>
> >> IIRC broken proprietary drivers never stopped us from shipping, but I
> >> could be wrong.
> > 
> > Officially. Unofficially, it was probably a contributing factor.
> 
> No, I don't think so.  We've certainly shipped with code that broke any given
> one of these before.

I am refering to the case referred to here:
http://lists.fedoraproject.org/pipermail/devel/2006-August/088541.html

There was a lot of discussion and speculation about this at the time.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plan for tomorrow's FESCo meeting (2010-11-17)

[Kevin Kofler]

Kevin Fenzi wrote:
> So, there are no folks in the KDE sig using F13 anymore?
> 
> Perhaps call for testers in the users / kde lists?

I think this issue goes far, far beyond just KDE. There are packages which 
have few users even for Fedora n, let alone n-1.

Yet another example of the update processes delaying an update for ages is 
the recent libgsf update 
https://admin.fedoraproject.org/updates/libgsf-1.14.18-1.fc13 , which was 
stuck for a month until the maintainer sent a nagmail to this mailing list 
(a method to get provenpackager attention which doesn't really scale). 
(libgsf is critpath due to being a dependency of something critical, so it 
gets the extra-hardcore policy.)

The processes just don't work, for the EXACT reasons I had brought up back 
when they were about to be introduced. It's time to stop living in denial, 
admit that the new processes are a failure and repeal them entirely.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: how to debug sound not working on macbook?

[Jóhann B. Guðmundsson]

On 11/17/2010 09:09 PM, Marius Andreiana wrote:
> Does anybody have suggestions how an end user could debug this?
> https://bugzilla.redhat.com/show_bug.cgi?id=580703

Had you tried this already [1]

JBG

1. http://fedoraproject.org/wiki/How_to_debug_sound_problems
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: how to debug sound not working on macbook?

[fkoo...@tuxed.net]

On Wed, Nov 17, 2010 at 10:09 PM, Marius Andreiana
 wrote:
> Does anybody have suggestions how an end user could debug this?
> https://bugzilla.redhat.com/show_bug.cgi?id=580703

https://bugzilla.redhat.com/show_bug.cgi?id=590907

Regards,
François
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Genes MailLists]

  Lets also not forget that the motivation for changing memcpy was to
get some speedup - has anyone seen evidence of any significant benefit
of that glibc change?

  The BZ ref'd in this thread has linus' (simple) tests which dont
confirm any benefit of the change compared to his simpler version (which
does not go backwards).

  So why make a change which only has downside and little to no upside?

  The pragmatic side of is pushing to revert the change in glibc rather
than create workarounds for it ...

   at least for now and until there is clear evidence of significant
benefit to offset the obvious downside.


Which apps gain - and by how much in real world situations ?

   Sounds like Adobe will fix it eventually anyway and in the mean time
all will be peaceful ... and we can read/contribute to other threads!!


   gene/


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[nodata]

On 17/11/10 22:16, John Reiser wrote:
> On 11/17/2010 12:41 PM, Emmanuel Seyman wrote:
>> 2) Issues found in proprietary software cannot be fixed by anybody except
>> the vendor
>
> False.  In this particular case, it is possible to binary edit the plugin
> libflashplayer.so so that all its calls to memcpy become calls to memmove.
> The change is to copy the .st_name field from the symbol for memmove to the
> .st_name field of the symbol for memcpy, which creates another instance
> of memmove.   With that one 32-bit change, then the player will work.
> Memmove can be a few percent slower than memcpy, but nobody will notice.

Editing binaries is a bad idea and also breaks the packaging guidelines.

rpm verification will also break. It sets a bad precedent.

> If the plugin did not have a reference to memmove already, then on x86_64
> an impostor can be created by introducing the name "memmove\0" at
> &{DT_NULL}.d_un.  This is a generic work-around for this particular
> issue with memcpy on x86_64.
>

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Emmanuel Seyman]

* John Reiser [17/11/2010 22:30] :
> 
> On 11/17/2010 12:41 PM, Emmanuel Seyman wrote:
>
> > 2) Issues found in proprietary software cannot be fixed by anybody except
> >the vendor
> 
> False.  In this particular case,

FWIW, I was refering to the general case.

>  it is possible to binary edit the plugin
> libflashplayer.so so that all its calls to memcpy become calls to memmove.

With all due respects, this looks more like a hack than a fix.

Emmanuel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Gregory Maxwell]

On Wed, Nov 17, 2010 at 5:11 PM, Genes MailLists  wrote:
>
>  Lets also not forget that the motivation for changing memcpy was to
> get some speedup - has anyone seen evidence of any significant benefit
> of that glibc change?
>
>  The BZ ref'd in this thread has linus' (simple) tests which dont
> confirm any benefit of the change compared to his simpler version (which
> does not go backwards).
>
>  So why make a change which only has downside and little to no upside?
[snip]

The original testing that went with the GLIBC patches also showed no
speedup on the hardware Linus uses, but it did show an impressive
(perhaps too impressive) speedup on other hardware:

http://article.gmane.org/gmane.comp.lib.glibc.alpha/15278

But is it only me who worries that lots of people are running code
exposed to the internet that has obviously never even been run under
valgrind?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Peter Jones]

On 11/17/2010 05:11 PM, nodata wrote:
> On 17/11/10 22:16, John Reiser wrote:
>> On 11/17/2010 12:41 PM, Emmanuel Seyman wrote:
>>> 2) Issues found in proprietary software cannot be fixed by anybody except
>>>  the vendor
>>
>> False.  In this particular case, it is possible to binary edit the plugin
>> libflashplayer.so so that all its calls to memcpy become calls to memmove.
>> The change is to copy the .st_name field from the symbol for memmove to the
>> .st_name field of the symbol for memcpy, which creates another instance
>> of memmove.   With that one 32-bit change, then the player will work.
>> Memmove can be a few percent slower than memcpy, but nobody will notice.
>
> Editing binaries is a bad idea and also breaks the packaging guidelines.
>
> rpm verification will also break. It sets a bad precedent.

To be fair, we're not packaging flash in Fedora anyway.

-- 
 Peter

Computers don't make errors.  What they do, they do on purpose.
-- Dale
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: how to debug sound not working on macbook?

[Marius Andreiana]

2010/11/18 "Jóhann B. Guðmundsson" 

> On 11/17/2010 09:09 PM, Marius Andreiana wrote:
> > Does anybody have suggestions how an end user could debug this?
> > https://bugzilla.redhat.com/show_bug.cgi?id=580703
>
>
Had you tried this already [1]
>
> JBG
>
> 1. http://fedoraproject.org/wiki/How_to_debug_sound_problems
>

Just learned about this, thanks.
I've attached the required info to the bug, looks like it has been assigned
to proper maintainer now.
I tried two variations of the sound.conf, none working.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Adding patches in a SPEC

[Martin Sourada]

On Wed, 2010-11-17 at 07:39 -0500, Eric "Sparks" Christensen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 11/17/2010 03:57 AM, Martin Sourada wrote:
> > On Tue, 2010-11-16 at 17:17 -0500, Eric "Sparks" Christensen wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> On 11/16/2010 04:28 PM, Martin Sourada wrote:
> >>> On Tue, 2010-11-16 at 11:18 -0500, Eric "Sparks" Christensen wrote:
>  On Tue, Nov 16, 2010 at 11:04, Patrick MONNERAT  
>  wrote:
> > On Tue, 2010-11-16 at 17:48 +0200, Andy Shevchenko wrote:
> >> You need to do patch on top of source tree container
> >>
> >> mycoolpkg-5.3/
> >> /Makefile
> >> /source.c
> >> ...
> >> mycoolpkg-5.3.new/
> >>/Makefile
> >>/source.c
> >> ...
> >>
> >> run  diff -ruN -p mycoolpkg-5.3 mycoolpkg-5.3.new
> >>
> >
> > ... and use %patch0 -p 1 ...
> 
>  Okay, I ran the above diff and created a nice patch:
> 
>  diff -ruN -p gpredict-1.2/Makefile gpredict-1.2.new/Makefile
>  --- gpredict-1.2/Makefile   2010-11-15 20:07:20.676418835 -0500
>  +++ gpredict-1.2.new/Makefile   2010-11-16 11:04:49.677590541 -0500
>  @@ -168,7 +168,7 @@ OTOOL64 =
>   PACKAGE = gpredict
>   PACKAGE_BUGREPORT =
>   PACKAGE_CFLAGS = -pthread -I/usr/include/gtk-2.0
>  -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
>  -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0
>  -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
>  -I/usr/include/pixman-1 -I/usr/include/freetype2
>  -I/usr/include/libpng12 -I/usr/include/goocanvas-1.0
>  -PACKAGE_LIBS = -pthread -lgoocanvas -lgtk-x11-2.0 -lgdk-x11-2.0
>  -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
>  -lm -lcairo -lpng12 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0
>  -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lcurl
>  +PACKAGE_LIBS = -lm -pthread -lgoocanvas -lgtk-x11-2.0 -lgdk-x11-2.0
>  -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
>  -lm -lcairo -lpng12 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0
>  -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lcurl
>   PACKAGE_NAME =
>   PACKAGE_STRING =
>   PACKAGE_TARNAME =
> 
>  I changed the SPEC to say "%patch0 -p 1".  I get the same error (below):
> 
>  [u...@server rpmbuild]$ rpmbuild -ba SPECS/gpredict.spec
>  Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.wAGj7E
>  + umask 022
>  + cd /home/christensene/rpmbuild/BUILD
>  + LANG=C
>  + export LANG
>  + unset DISPLAY
>  + cd /home/christensene/rpmbuild/BUILD
>  + rm -rf gpredict-1.2
>  + /usr/bin/gzip -dc /home/user/rpmbuild/SOURCES/gpredict-1.2.tar.gz
>  + /bin/tar -xf -
>  + STATUS=0
>  + '[' 0 -ne 0 ']'
>  + cd gpredict-1.2
>  + /bin/chmod -Rf a+rX,u+w,g-w,o-w .
>  + echo 'Patch #0 (gpredict-1.2-DSO.patch):'
>  Patch #0 (gpredict-1.2-DSO.patch):
>  + /bin/cat /home/user/rpmbuild/SOURCES/gpredict-1.2-DSO.patch
>  + /usr/bin/patch -s -p1 --fuzz=0
>  The text leading up to this was:
>  --
>  |diff -ruN -p gpredict-1.2/Makefile gpredict-1.2.new/Makefile
>  |--- gpredict-1.2/Makefile  2010-11-15 20:07:20.676418835 -0500
>  |+++ gpredict-1.2.new/Makefile  2010-11-16 11:04:49.677590541 -0500
>  --
> >>> That might be because the Makefile actually isn't there -- it's usually
> >>> created from Makefile.in after calling ./configure. IMHO you have
> >>> several options
> >>>   * use sed to make the change, after running configure
> >>>   * patch Makefile.in instead of Makefile
> >>>   * patch Makefile.am and reconfigure (autoreconf --force,
> >>> or ./autogen.sh, depending how autotools are handled in
> >>> gpredict)
> >>>
> >>> And anyway, why are you trying to patch it this way? Unless I missed
> >>> something you're adding -lm to PACKAGE_LIBS which is however already
> >>> present (prior to -lcairo) there.
> >>>
> >>> Martin
> >>>
> >>
> >> I ran into the following error when I was building the SRPM:
> >>
> >> /usr/bin/ld: solar.o: undefined reference to symbol 'sincos@@GLIBC_2.2.5'
> >> /usr/bin/ld: note: 'sincos@@GLIBC_2.2.5' is defined in DSO
> >> /lib64/libm.so.6 so try adding it to the linker command line
> >> /lib64/libm.so.6: could not read symbols: Invalid operation
> >> collect2: ld returned 1 exit status
> >> make[4]: *** [test-002] Error 1
> >> make[4]: *** Waiting for unfinished jobs
> >> /usr/bin/ld: solar.o: undefined reference to symbol 'sincos@@GLIBC_2.2.5'
> >> /usr/bin/ld: note: 'sincos@@GLIBC_2.2.5' is defined in DSO
> >> /lib64/libm.so.6 so try adding it to the linker command line
> >> /lib64/libm.so.6: could not read symbols: Invalid operation
> >>
> >>
> >> I was told that I needed to add the -lm to the PACKAGE_LIBS which is
> >> wh

Re: Changes in Java packaging guidelines - RFC

[Ville Skyttä]

On Wednesday 17 November 2010, Kevin Kofler wrote:
> Ville Skyttä wrote:
> > I'd get rid of the versioned javadoc dir altogether, and simply install
> > to %{_javadocdir}/%{name}.  Unversioned is good for bookmarking and
> > javadoc crosslinking.
> 
> One thing you have to be careful of, no matter which way you decide, is
> that you MUST NOT change a directory to a symlink or the other way round
> or RPM will get terribly confused on upgrades.
>
> (There are bizarre (and easy to get wrong) scriptlet workarounds that can
> be used, but avoiding the mess in the first place is probably the best
> solution.)

In this case it's the unversioned dir we want to stay around, so the 
scriptlet doesn't have to be any more bizarre than something like this which 
IMO isn't that bad (certainly not bad enough to stop implementing the above 
plan IMO), and would only be needed in *-javadoc that created an unversioned 
symlink, either owned by the package as usual or created "in the wild" in 
%post:

%pretrans javadoc -p 
-- TODO: remove this scriptlet in F-17
os.remove("%{_javadocdir}/%{name}")

The F-17 in the comment assumes this stuff is first introduced in F-15, and 
that direct upgrades from F-N to F-(N+2) (i.e. skip over one release but not 
more) should be supported.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Genes MailLists]

On 11/17/2010 05:20 PM, Gregory Maxwell wrote:

> The original testing that went with the GLIBC patches also showed no
> speedup on the hardware Linus uses, but it did show an impressive
> (perhaps too impressive) speedup on other hardware:
> 
> http://article.gmane.org/gmane.comp.lib.glibc.alpha/15278


  Ok - but % speedups are just one metric - the absolute time is also
important.

 If something went from 20 ms to 60 ms its a huge % percentage speedup
but could well be irrelevant in real world app setting - so my question
is not the % speedup on the function, but the observed speedup in
application setting (flash for example).



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Updates to static library packages

[Kevin Kofler]

Siddhesh Poyarekar wrote:
> I maintain LibRaw, which is only a static library -- upstream has
> rejected the idea of maintaining dynamic libs since they would have to
> take care of ABI compatibility across releases.
> 
> I wanted to know if there are any other only-static libraries out
> there and how they maintainers manage releases. I had packaged this to
> build Shotwell 0.6.x but I understand there are a couple of other apps
> too that build against this now. Do i have to keep track of all of
> them and coordinate releases with them, i.e. announce an update, have
> them test and then push a build? Or do I just go ahead and build in
> rawhide and then wait for someone to complain?

You can just build a shared library with custom sonames (probably a new 
soname per version, unfortunately). I think that's actually the sanest 
approach to handle this problem.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Adam Jackson]

On Wed, 2010-11-17 at 15:42 -0600, Bruno Wolff III wrote:
> On Wed, Nov 17, 2010 at 16:33:59 -0500, Peter Jones  wrote:
> > On 11/17/2010 03:41 PM, Bruno Wolff III wrote:
> > > On Wed, Nov 17, 2010 at 21:46:09 +0100, François 
> > > Cami  wrote:
> > >> IIRC broken proprietary drivers never stopped us from shipping, but I
> > >> could be wrong.
> > > 
> > > Officially. Unofficially, it was probably a contributing factor.
> > 
> > No, I don't think so.  We've certainly shipped with code that broke any 
> > given
> > one of these before.
> 
> I am refering to the case referred to here:
> http://lists.fedoraproject.org/pipermail/devel/2006-August/088541.html
> 
> There was a lot of discussion and speculation about this at the time.

That was about updating FC5 after it shipped.  An OS that went gold on
20 May 2006, three months before the post you're referencing.  We've
never broken X server ABI in any Fedora release as far as I'm aware, for
basically the same reason you don't bump sonames after release.

That thread sure is a flashback though.  Turns out the things I was
saying four years ago, I still believe:

http://lists.fedoraproject.org/pipermail/devel/2006-August/088641.html

Breaking proprietary drivers has _never_ been a ship criteria while I've
been in charge.  Remember F9, when we shipped an xserver 1.5 snapshot
before all the binary drivers were ported?  I got a lot of shit for
that, that was pretty sweet.  Turns out you get criticized no matter
what you do, even if you're unflinchingly consistent for five years.

- ajax


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: Fixing the glibc adobe flash incompatibility

[Chris Adams]

Once upon a time, Gregory Maxwell  said:
> But is it only me who worries that lots of people are running code
> exposed to the internet that has obviously never even been run under
> valgrind?

Yeah, people are acting like Adobe Flash is the only program in the
world to make this (unfortunately quite easy) mistake.  ISTR some old
configure scripts (the rn/trn/perl one maybe?) that actually checked
memcpy's overlap behavior at compile time.  Somebody else has already
reported finding another program (in the Fedora distribution even) that
suffered from the same problem.

Yes, by standards, memcpy is free to explode the universe if you call it
with overlapping source and destination.  It doesn't mean it is the
right thing to do, especially for a limited performance gain (and only
on certain CPUs).  Changing its behavior is an ABI change, even if an
undocumented one.

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fixing the glibc adobe flash incompatibility

[Emmanuel Seyman]

* Peter Jones [17/11/2010 23:31] :
>
> To be fair, we're not packaging flash in Fedora anyway.

>From the post that started this thread:

 "This solution could be reverting the problem causing glibc change, or
  maybe changing it to do forward memcpy's while still using the new SSE
  instructions, or something more specific to the flash plugin, as long
  as it will automatically fix things with a yum upgrade without requiring
  ^^
  any further user intervention."

Emmanuel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel