Re: libprojectM Packaging Problem
Jameson wrote, at 10/11/2009 06:37 AM +9:00: I'm having trouble getting the new version of libprojectM packaged, and hope someone can shed some light on this for me. Would you upload the srpm you are trying somewhere? When I enter the commands to build it manually, it builds fine, but when trying to package it, it comes out with commands like: Which fail due to ;-fPIC. Any ideas on why this is happening? It looks to me that it's a simple matter of getting rid of the ; in the command, but I have no idea why it's there using rpmbuild, but not when I build manually. Thanks, =-Jameson Regards, Mamoru -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On 10/10/2009 11:07 PM, Jeff Garzik wrote: Just upgraded my F11 workstation, which included an upgrade to thunderbird-3.0-2.7.b4.fc11.x86_64 Without any prompting or warning, my email layout -- a key interface into my open source development workflow -- was changed to use something called "smart folders". Wrong list and a week late[1]. No need to continue the old discussion here. [1] https://www.redhat.com/archives/fedora-list/2009-October/msg00110.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
thunderbird upgrade - wtf?
Just upgraded my F11 workstation, which included an upgrade to thunderbird-3.0-2.7.b4.fc11.x86_64 Without any prompting or warning, my email layout -- a key interface into my open source development workflow -- was changed to use something called "smart folders". Also annoying, though of less impact to me personally, was the decision (again, without prompting or warning) to index all of my email -- of which there is a considerable amount. Now, I'm sure smart folders are a nifty new feature, but where was the warning about this upgrade? Why was this done late in F11, rather than F12? IMO, major MUA upgrades should be handled better than this. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Howto handle multilib conflict?
On Sat, Oct 10, 2009 at 10:17:16AM -0700, Adam Williamson wrote: > > Well, that's only valid if we actually do anything to ensure multilib > compilation actually *works*, right now all we enforce is that the > packages don't conflict (which isn't the same thing at all). It's also valid if we want to help people to be able to have multilib compilation work, even if it is not used in fedora rpm builds. I have no knowledge about this issue, but I guess that having multilib devel packages installed allows users comppiling software to easily use one or the other library, even if it involves setting some flags by hand, and, hopefully, with pkg-config setting flags by hand is not required. -- Pat -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Development packages for Thunderbird/Sunbird
Henrik /KaarPoSoft, Fri, 09 Oct 2009 18:20:44 +0200: > However, to compile blueZync, development packages for thunderbird and > sunbird are needed > (i.e. header files, idl files etc). > > As far as I can see, not such -devel packages are available for Fedora > 11 or 12. When you install xulrunner*devel what files you are missing? Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
libprojectM Packaging Problem
I'm having trouble getting the new version of libprojectM packaged, and hope someone can shed some light on this for me. When I enter the commands to build it manually, it builds fine, but when trying to package it, it comes out with commands like: cd /home/ipfreely/rpmbuild/BUILD/libprojectM-1.2.0r1295/Renderer && /usr/lib64/ccache/c++ -DUSE_FBO -DLINUX -DSTBI_NO_DDS -DUSE_THREADS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic ;-fPIC -I/home/ipfreely/rpmbuild/BUILD/libprojectM-1.2.0r1295 -DCMAKE_INSTALL_PREFIX="\"/usr\"" -o CMakeFiles/Renderer.dir/FBO.o -c /home/ipfreely/rpmbuild/BUILD/libprojectM-1.2.0r1295/Renderer/FBO.cpp Which fail due to ;-fPIC. Any ideas on why this is happening? It looks to me that it's a simple matter of getting rid of the ; in the command, but I have no idea why it's there using rpmbuild, but not when I build manually. Thanks, =-Jameson -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Development packages for Thunderbird/Sunbird
Original Message Subject: Development packages for Thunderbird/Sunbird From: Henrik /KaarPoSoft To: fedora-devel-list@redhat.com Date: 09.10.2009 18:20 I would like blueZync to work on Fedora too (currently developing on Debian and Ubuntu). Me too. I did start a packaging effort some time ago and caused a little disaster by updating libsyncml to a newer version to build blueZync. Our problem was that nothing else could be built against the new version of libsyncml. As far as I can see, not such -devel packages are available for Fedora 11 or 12. That is correct. Can anybody guide me as to how to kindly request such packages for Fedora? The best would be to file a bug against both thunderbird and sunbird and kindly state what you would need for building blueZync. If you as the developer did that, that would be great. As soon as the development files are available I'd be glad working with you on getting blueZync into Fedora. Felix -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer MIA: Claudio Tomasoni
Am Samstag, den 10.10.2009, 21:41 +0200 schrieb Chitlesh GOORAH: > On Fri, Oct 9, 2009 at 9:34 PM, Christoph Wickert wrote: > > I am starting the AWOL procedure [1] for Claudio Tomasoni, because he > > didn't respond to a bug I opened 5 months ago [2]. Chitlesh even tried > > to contact him for more than 7 months [3]. We should prepare for taking > > over Claudio's packages [4]. > > I'm willing to take over : > https://admin.fedoraproject.org/pkgdb/packages/name/octaviz > https://admin.fedoraproject.org/pkgdb/packages/name/qtoctave Great, but there are still two weeks left. > Chitlesh Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer MIA: Claudio Tomasoni
On Fri, Oct 9, 2009 at 9:34 PM, Christoph Wickert wrote: > I am starting the AWOL procedure [1] for Claudio Tomasoni, because he > didn't respond to a bug I opened 5 months ago [2]. Chitlesh even tried > to contact him for more than 7 months [3]. We should prepare for taking > over Claudio's packages [4]. I'm willing to take over : https://admin.fedoraproject.org/pkgdb/packages/name/octaviz https://admin.fedoraproject.org/pkgdb/packages/name/qtoctave Chitlesh -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Howto handle multilib conflict?
Michael Schwendt wrote, at 10/11/2009 01:09 AM +9:00: On Sat, 10 Oct 2009 17:32:40 +0200, Patrice wrote: On Sat, Oct 10, 2009 at 05:21:37PM +0200, Christoph Wickert wrote: Timestamp differences do NOT cause file conflicts. Indeed, obviously this has changed. Changes like this should be announced somewhere, What is the source of these rumours that file timestamp differences would cause conflicts? I guess these rumors came because sometimes some programs creating document files (mostly html files) or so embeded the timestamp of the date in those files and that actually caused multilib conflict (i.e. not the timestamp of the files but the embedded strings in those files). Regards, Mamoru -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Howto handle multilib conflict?
On Sat, 2009-10-10 at 10:17 -0700, Adam Williamson wrote: > I guess the point is that if we actually intend to support 'you can > cross-compile with any -devel package from another arch that's included gah, I know I don't really mean cross-compile, it's been pointed out to me before that it's the wrong term. you know what I mean. sorry. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Howto handle multilib conflict?
On Sat, 2009-10-10 at 18:05 +0200, Michael Schwendt wrote: > On Sat, 10 Oct 2009 07:47:59 -0700, Adam wrote: > > > Of course, that turns the larger question into 'why do we put i686 > > -devel packages in the x86-64 repo, not just the lib packages', > > Because not all files in -devel packages cover multiple target > platforms. Example: You could not build for i686 with headers that > are specific to x86_64, and you would also need the .so symlinks for > libraries in the appropriate libdir. Well, that's only valid if we actually do anything to ensure multilib compilation actually *works*, right now all we enforce is that the packages don't conflict (which isn't the same thing at all). I hope I'm not dragging him into the conversation unwillingly, but Colin Walters raised those points on IRC: well, what's the ultimate goal? just avoiding the OS exploding if you happen to somehow get an i386 -devel? or actually be able to compile 32 bit on 64 hosts? those are pretty different things ... people keep trying to scope creep multilib to include compilation, which we need to clamp down on, and tell them to use mock well last time we tried to make major changes to our multilib strategy, Jeremy was the one to play Captain No and he's gone now, so I guess the point is that if we actually intend to support 'you can cross-compile with any -devel package from another arch that's included in the repository' we may need more strict policies / work to ensure that's actually possible, and if we intend *not* to support that, but rather tell people to use mock, there's no reason to include -devel packages in multilib. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Howto handle multilib conflict?
On Sat, 10 Oct 2009 17:32:40 +0200, Patrice wrote: > On Sat, Oct 10, 2009 at 05:21:37PM +0200, Christoph Wickert wrote: > > > > > > Timestamp differences do NOT cause file conflicts. > > > > Indeed, obviously this has changed. Changes like this should be > > announced somewhere, What is the source of these rumours that file timestamp differences would cause conflicts? > > I guess Kevin and me are not the only one packagers > > who still believe they have to care for timestamps. > > I am not sure that timestamps created conflicts in the past. If they have ever lead to conflicts, then only as a result of a temporary bug. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Howto handle multilib conflict?
On Sat, 10 Oct 2009 07:47:59 -0700, Adam wrote: > Of course, that turns the larger question into 'why do we put i686 > -devel packages in the x86-64 repo, not just the lib packages', Because not all files in -devel packages cover multiple target platforms. Example: You could not build for i686 with headers that are specific to x86_64, and you would also need the .so symlinks for libraries in the appropriate libdir. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Howto handle multilib conflict?
On Sat, Oct 10, 2009 at 05:21:37PM +0200, Christoph Wickert wrote: > > > > Timestamp differences do NOT cause file conflicts. > > Indeed, obviously this has changed. Changes like this should be > announced somewhere, I guess Kevin and me are not the only one packagers > who still believe they have to care for timestamps. I am not sure that timestamps created conflicts in the past. However in rpm -V there were marked as being modified. Maybe this is what changed. In any case I think that we should care for timestamps even if they are not reasons for conflicts. Some packagers disagree, though, that timestamps are useful and should be correct. -- Pat -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Howto handle multilib conflict?
Am Samstag, den 10.10.2009, 11:30 +0300 schrieb Panu Matilainen: > On Sat, 10 Oct 2009, Christoph Wickert wrote: > > > > If the contents of the file is the same and they only their timestamps > > differ, you can touch them reversely after install as in > > http://cvs.fedoraproject.org/viewvc/rpms/exo/devel/exo.spec?r1=1.38&r2=1.39 > > Timestamp differences do NOT cause file conflicts. Indeed, obviously this has changed. Changes like this should be announced somewhere, I guess Kevin and me are not the only one packagers who still believe they have to care for timestamps. > Content (and permission) differences do. I took a look at the files from exo and they did differ. Tanks for the pointer. > - Panu - Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Sat, 2009-10-10 at 15:02 +, Scott Tsai wrote: > On Fri, 09 Oct 2009 07:57:51 -0700, Adam Williamson wrote: > > > It would be nice to have more comprehensive 3D tests. > > I think it's worth packaging the "piglit" OopenGL test suite: > http://cgit.freedesktop.org/piglit > and using it in graphics test days. > > According tho this blog post by Eric Anholt and the git commit log, > upstream open source graphics driver developers are still constantly > adding tests to it: > http://anholt.livejournal.com/41522.html Good point. I think Francois Cami had some plans to this effect, but he's been away from the project for a few months lately, so maybe I'll do it instead. Thanks for the reminder. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How about releasing an update of xorg-x11-drv-intel for Fedora 11
On Fri, 09 Oct 2009 07:57:51 -0700, Adam Williamson wrote: > It would be nice to have more comprehensive 3D tests. I think it's worth packaging the "piglit" OopenGL test suite: http://cgit.freedesktop.org/piglit and using it in graphics test days. According tho this blog post by Eric Anholt and the git commit log, upstream open source graphics driver developers are still constantly adding tests to it: http://anholt.livejournal.com/41522.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Howto handle multilib conflict?
On Fri, 2009-10-09 at 22:25 -0400, Seth Vidal wrote: > > On Fri, 9 Oct 2009, Adam Williamson wrote: > > > On Fri, 2009-10-09 at 16:41 -0700, Toshio Kuratomi wrote: > > > >>> It's not to be considered a bug, AFAIK. We don't stipulate that > >>> development packages be installable side-by-side in this way, we only > >>> stipulate that for library packages where there's a need for it. There's > >>> no particular use case where you absolutely need both -devel packages > >>> installed at once. > >>> > >> I believe this is incorrect. devel packages are supposed to be multilib > >> installable. There's two things that are two files that conflict above and > >> there's two different fixes for each. > > > > I'm happy to be wrong :), but is this documented anywhere? That's why I > > thought the opposite was the case, I couldn't find anything to this > > effect in the packaging documentation when I was starting out. > > > > Well, I know it is documented that file conflicts are never allowed, ever, > at all w/o an explicit conflicts: in the spec file. Ah, yeah. That would cover it without any need for a specific multilib policy, for sure. (I checked, and libotf-devel i686 is in the x86-64 repo). Of course, that turns the larger question into 'why do we put i686 -devel packages in the x86-64 repo, not just the lib packages', but it does explain for sure that I was wrong in my initial reply, sorry for that! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
cups/guttenprint color schemes wrong for Epson Stylus CX3500 and other printers
Maybe off topic but, how to correct color schemes for Epson Printers? Default is horrible (excess of red, wrong gamma/brightness, etc). I guess someone must have dealt with that. Best regards CdAB signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20091010 changes
Compose started at Sat Oct 10 06:15:04 UTC 2009 Broken deps for i386 -- konversation-1.2-1.fc12.i686 requires kdelibs4 >= 0:4.3.2 sugar-toolkit-0.86.0-1.fc12.i686 requires python-json Broken deps for x86_64 -- konversation-1.2-1.fc12.x86_64 requires kdelibs4 >= 0:4.3.2 sugar-toolkit-0.86.0-1.fc12.x86_64 requires python-json Broken deps for ppc -- konversation-1.2-1.fc12.ppc requires kdelibs4 >= 0:4.3.2 sugar-toolkit-0.86.0-1.fc12.ppc requires python-json Broken deps for ppc64 -- konversation-1.2-1.fc12.ppc64 requires kdelibs4 >= 0:4.3.2 python-mwlib-0.11.2-3.20090522hg2956.fc12.ppc64 requires LabPlot sugar-toolkit-0.86.0-1.fc12.ppc64 requires python-json Removed package gai Removed package gai-pal Removed package gai-temp Removed package python-json Updated Packages: NetworkManager-0.7.996-4.git20091002.fc12 - * Fri Oct 02 2009 Dan Williams - 0.7.996-4.git20091002 - install: fix -gnome package %pre script failures (rh #526519) - nm: fix failures validating private keys when using the NSS crypto backend - applet: fix crashes when clicking on menu but not associated (rh #526535) - editor: fix crash editing wired 802.1x settings - editor: fix secrets retrieval when editing connections Terminal-0.4.2-2.fc12 - * Thu Oct 08 2009 Christoph Wickert - 0.4.2-2 - Fix locale problems in the UI (bugzilla.xfce.org #5842) chromium-bsu-0.9.14-6.fc12 -- * Fri Oct 09 2009 Hans de Goede 0.9.14-6 - Switch to quesoglc instead of ftgl (glc is the upstream default) - This fixes chromium-bsu not finding its font, as quesoglc properly uses fontconfig instead of using a hardcoded path to the font (#526995) dopewars-1.5.12-9.1033svn.fc12 -- * Fri Oct 09 2009 Jussi Lehtola - 1.5.12-8.1033svn - Update to svn release to address security issues. * Fri Oct 09 2009 Jussi Lehtola - 1.5.12-9.1033svn - Increment release to be able to tag in F-12. dracut-002-13.4.git8f397a9b.fc12 * Fri Oct 09 2009 Harald Hoyer 002-13.2 - do not fail, if libdmraid-events-isw.so is not present * Fri Oct 09 2009 Harald Hoyer 002-13.3 - removed one wildcard of libdmraid-events-isw.so install * Fri Oct 09 2009 Jesse Keating - 002-13.4 - Requires(pre) on plymouth to ensure plymouth is installed before kernel drupal-service_links-6.x.1.0-5.fc12 --- * Fri Oct 09 2009 Jon Ciesla - 6.x.1.0-5 - Patch for CVE-2009-3648 from madirish.net, BZ 528200, 528201. gcc-4.4.1-20.fc12 - * Thu Oct 08 2009 Jakub Jelinek 4.4.1-20 - update from gcc-4_4-branch - PRs c++/39863, c++/41038 - avoid redundant DW_AT_const_value when abstract origin already has one (#527430) - another VTA debug stmt renaming bugfix (#521991) * Mon Oct 05 2009 Jakub Jelinek 4.4.1-19 - update from gcc-4_4-branch - PRs fortran/41479, fortran/41515 - VTA backports - PRs debug/41353, debug/41404, rtl-optimization/41511 - another debug info fix for decls passed by reference (#527057, PR debug/41558) - don't emit DW_AT_name on DW_TAG_const_type (#526970) - avoid invalid folding of casts to addresses of first fields (#527121, PR middle-end/41317) * Thu Oct 01 2009 Jakub Jelinek 4.4.1-18 - update from gcc-4_4-branch - PRs ada/41100, target/22093 - VTA backports - PRs debug/41438, debug/41474, target/41279, testsuite/41444 - fix VTA ICE on Linux kernel (#521991) - AMD Orochi -mfma4 support - don't run install-info if info files are missing because of --excludedocs (#515921, #515960, #515962, #515965, #516000, #516008, #516014) gdm-2.28.0-9.fc12 - * Fri Oct 09 2009 Matthias Clasen - 1:2.28.0-8 - Move bubbles to the lower right on the login screen * Fri Oct 09 2009 Ray Strode 2.28.0-9 - Fix Other... user. * Wed Oct 07 2009 Ray Strode - 1:2.28.0-7 - Fix gdm-password / xguest interaction (bug 524421) gtk2-2.18.2-2.fc12 -- * Fri Oct 09 2009 Matthias Clasen - 2.18.2-2 - Make selecting the final char work again (#528072) konversation-1.2-1.fc12 --- * Fri Oct 09 2009 Rex Dieter - 1.2-1 - konversation-1.2 (final) libcap-ng-0.6.2-3.fc12 -- * Fri Oct 09 2009 Steve Grubb 0.6.2-3 - Apply patch to retain setpcap only if clearing bounding set libv4l-0.6.2-1.fc12 --- * Fri Oct 09 2009 Hans de Goede 0.6.2-1 - New upstream release 0.6.2 libvirt-0.7.1-11.fc12 - * Fri Oct 09 2009 Mark McLoughlin - 0.7.1-11 - Fix libvirtd memory leak during error reply sending (#528162) - Add several PCI hot-unplug typo fixes from upstream libvoikko-2.2.1-1.fc12 ---
Re: Howto handle multilib conflict?
On 10/10/2009 01:48 AM, Orcan Ogetbil wrote: On Fri, Oct 9, 2009 at 7:29 PM, Christoph Wickert wrote: Am Freitag, den 09.10.2009, 18:56 -0400 schrieb Neal Becker: What if the generated docbook documents are different due to different "id"s? Do we need to separate the docs into a noarch subpackage? Nope, this doesn't actually help. The actual fix would be to fix docbook[1] rsp. these docbook-documents' sources to not apply "ids" rsp. to produce "deterministic ids". An alternative work-around would be to "filter out/process" (e.g. by using sed) these "id"s, such the generated docs can be generated deterministically. Last resort would be to move such docs into arch' dependent directories in arch-dependent packages. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Howto handle multilib conflict?
On Sat, 10 Oct 2009, Christoph Wickert wrote: Am Freitag, den 09.10.2009, 18:56 -0400 schrieb Neal Becker: Just received: https://bugzilla.redhat.com/show_bug.cgi?id=528237 yum install libotf-devel.i586 libotf-devel.x86_64 yields: Transaction Check Error: file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64 file /usr/share/doc/libotf-devel-0.9.8/example/Makefile from install of libotf-devel-0.9.8-2.fc11.i586 conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64 What is the recommended way to resolve this? If the contents of the file is the same and they only their timestamps differ, you can touch them reversely after install as in http://cvs.fedoraproject.org/viewvc/rpms/exo/devel/exo.spec?r1=1.38&r2=1.39 Timestamp differences do NOT cause file conflicts. Content (and permission) differences do. - Panu - -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
