Re: Drpython testing request. Bugzilla #821296
On 14/05/12 03:35, Adrian Alves wrote: Hello Guys, Am looking for someone to test DrPython, .. Regards, Adrian.- It is pretty unusual, to test a package before it's released. If you're looking for a reviewer, I'd like to point you to https://fedoraproject.org/wiki/Package_Review_Process#Contributor: 4. Wait for someone to review your package! If that doesn't help, you might offer: Review Swaps If nobody comments on your review request, you might want to mail to a mailing list (devel@lists.fedoraproject.org, for example) asking for a review swap. This is an offer to do a review of someone else's package in exchange for them reviewing your package. This is usually one-for-one, or can be some other private arrangement depending on the difficulty of the respective packages. Just mailing devel@lists saying: hey everybody, here's something to test might work but is usually not a good strategy. There are about 700 packages waiting to get reviewed. Just start a few and the chances for your packages will improve. -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Please add GNU id-utils to Fedora
Miloslav Trmač wrote: On Fri, May 11, 2012 at 10:14 AM, Jim Meyering j...@meyering.net wrote: Miloslav Trmač wrote: On Thu, May 10, 2012 at 9:49 PM, Greg McGary greg.mcg...@gmail.com wrote: Minor conflict: the name of one of id-utils main commands lid is also the same as an existing command, though installed in a different place. id-utils has /usr/bin/lid, while libuser has /usr/sbin/lid. Yeah, that's come up before. There's no great solution I'm afraid, one or the other will have to change Technically there is no need to change a name. In Debian, one can have two lid programs installed, one in /usr/bin and the other in /usr/sbin[*], so why not in Fedora? Apart from being confusing, it effectively overrides libuser's use of lid. Sure, a different solution would be better, but renaming a command like idutils' lid (in use by some for 15 years) does not seem reasonable. Right. Any opinions on whether this issue is big enough to NAK a review request or addition of the package to Fedora? I'm pretty sure that naming conflicts in /usr/bin have happened before in Fedora, I'm not sure how they were resolved. Even in a relatively minimal system, I see many programs installed in both /sbin and /bin, though none seem to conflict: $ comm -12 (cd /sbin;env ls -1) (cd /bin;env ls -1) authconfig authconfig-gtk authconfig-tui dracut eject halt hddtemp makemap mock ping6 poweroff preupgrade preupgrade-cli rdistd reboot setup system-config-authentication system-config-keyboard system-config-network system-config-network-cmd tmpwatch tracepath tracepath6 udevadm Odd that some point from /bin to /sbin, and others from /sbin to /bin. Some use relative symlinks, others use absolute. Compare the output of these commands: cd /sbin; ls -og $(comm -12 (cd /bin;env ls -1) (cd /sbin;env ls -1)) cd /bin; ls -og $(comm -12 (cd /bin;env ls -1) (cd /sbin;env ls -1)) ... Anyway, we can't please both sets of users at the same time. If the above-mentioned reference to previous naming conflicts in Fedora does not result in a generally-acceptable solution, what about the following? lid is renamed in both packages to lid-libuser and lid-idutils (or something), respectively. Both packages ship an alias script somewhere in /etc. A new package is created, providing a /usr/bin/lid script, that instructs the user to add the alias to their ~/.bashrc, and fails.[1] Mirek If cohabitation is not acceptable, that is a fine compromise that would let us move forward. However, it should suggest more than an alias/function addition, because those are not desirable/useful for non-command-line use e.g., via other scripts that invoke lid. Instead, suggesting to install a lid wrapper via one of these commands: f=~/bin/lid printf '#!/bin/sh\nexec lid-idutils $@\n' $f chmod a+x $f printf '#!/bin/sh\nexec lid-libuser $@\n' $f chmod a+x $f [ or use f=/usr/local/bin/lid for a system-wide choice. ] I would also request that users who encounter the failing lid script write to e.g., bug-idut...@gnu.org to inform us of their choice (either way), so that eventually, if we get stats to support a move and everyone agrees it's ok, we could phase out the always-failing lid script. [1] The script could also automatically run one of the lid's, if there were only one installed - but then merely installing a new package could break user's workflow, which I think is undesirable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Size of official media handouts (was Re: Proposed F18 feature: MiniDebugInfo)
On Fri, 2012-05-11 at 16:42 +0200, Christoph Wickert wrote: Am Mittwoch, den 09.05.2012, 11:57 -0400 schrieb Adam Jackson: On Wed, 2012-05-09 at 11:45 -0400, Matthias Clasen wrote: On Wed, 2012-05-09 at 13:35 +0200, Kevin Kofler wrote: Alexander Larsson wrote: The feature page lists some of the background and statistics. It also lists some options in how to implement this, which all have various different pros and cons. I'd like to hear what peoples opinions on these are. There is no room left on the KDE live image for installing any sort of debugging information by default. We could easily drop some of less-than-half-complete translations to make room for a bit of minidebuginfo. Last time I looked, translations, fonts, etc made up upwards of 25% of the livecd. Or we could just drop the obsolescent cdrom size limitation... I know I've said this before, but: we should break the CD size barrier precisely so people can't burn things to CDs. If you must burn to optical media, do yourself a favor and burn a DVD, the reduced seek time is entirely worth it. 1G fits on both the smallest MiniDVD format and most extant USB sticks. Let's do it already. As an ambassador and former EMEA media wrangler I tend to agree. Currently both EMEA and NA only do dual layer DVDs, both for live and the installer. EMEA did separate installer vor i386 and x86_64, but after NA had no problems with exclusively providing dual layer, we decided to do the same. This being said I don't care how big we grow as long as we can still fit all 4 desktops (GNOME, KDE, Xfce, LXDE) in 2 arches each on one multi desktop live image. A dual layer DVD has a maximum capacity of 8.5 GB, so fitting 8 x 1 GB is not a problem. We might have to drop Sugar, but if only GNOME and KDE go for 1 GB and Xfce and LXDE still target 700 MB or less, we should even be able to keep it. I understand that you want to ship isolated images for each of the desktops in this combination image, as that is what is tested, etc. However, there is gonna be a lot of duplicated bits in those images. Can't we use some form of image where the duplicated blocks can be shared. Seems like an obvious win to me. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GNOME 3.4.2 mega-update
I'm going to manage the GNOME 3.4.2 mega-update again for this release, as it's much easier to QA in one update than 30. If you're doing a GNOME 3.4.2 build please add it to the speadsheet https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc and I'll add it to the mega-update tomorrow afternoon. If you've got any questions, yell. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installer unable to detect Geforce GTX 460 v2
On Sat, 2012-05-12 at 13:38 -0700, Luya Tshimbalanga wrote: I have submitted a bug report[1] related to nouveau driver. The installer is unable to detect Nvidia Geforce GTX 460 v2 [2] which is different from the original Nvidia Geforce GTX 460, forcing the use of vesa driver. As a result, the screen is black so I cannot provide a xorg.log report let alone smolt hardware profile. I believe it should be possible to swith to tty2 (with Ctrl+Alt+F2) and use scp or some other tool to retrieve logs. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-17 Branched report: 20120514 changes
Compose started at Mon May 14 08:15:05 UTC 2012 Broken deps for x86_64 -- [LuxRender] LuxRender-blender-0.8.0-13.fc17.x86_64 requires blender(ABI) = 0:2.61 [aeolus-conductor] aeolus-conductor-0.4.0-2.fc17.noarch requires rubygem(fastercsv) aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8 [aeolus-configserver] aeolus-configserver-0.4.5-1.fc17.noarch requires ruby-nokogiri [dh-make] dh-make-0.55-4.fc17.noarch requires debhelper [dustmite] dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires libphobos2-ldc.so()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python2-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 [gnome-do-plugins] gnome-do-plugins-banshee-0.8.4-8.fc17.x86_64 requires mono(Banshee.CollectionIndexer) = 0:2.2.0.0 [gorm] gorm-1.2.13-0.2.20110331.fc17.i686 requires libobjc.so.3 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-gui.so.0.20 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-base.so.1.23 gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libobjc.so.3()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-gui.so.0.20()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-base.so.1.23()(64bit) [matreshka] matreshka-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnarl-4.6.so matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnarl-4.6.so()(64bit) matreshka-sql-core-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-core-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-sql-postgresql-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-postgresql-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-sql-sqlite-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-sqlite-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) [mcollective] mcollective-common-1.3.1-7.fc17.noarch requires ruby(abi) = 0:1.8 [moksha] moksha-0.5.0-5.fc15.noarch requires pyevent [natus] libnatus-V8-0.1.5-2.fc15.x86_64 requires libv8-3.0.0.1.so()(64bit) [ocaml-augeas] ocaml-augeas-0.4-9.fc15.x86_64 requires ocaml(runtime) = 0:3.12.0 [openvrml] libopenvrml-0.18.8-2.fc16.i686 requires libboost_thread-mt.so.1.47.0 libopenvrml-0.18.8-2.fc16.i686 requires libboost_system-mt.so.1.47.0 libopenvrml-0.18.8-2.fc16.i686 requires libboost_filesystem-mt.so.1.47.0 libopenvrml-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) libopenvrml-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) libopenvrml-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) libopenvrml-gl-0.18.8-2.fc16.i686 requires libboost_thread-mt.so.1.47.0 libopenvrml-gl-0.18.8-2.fc16.i686 requires libboost_system-mt.so.1.47.0 libopenvrml-gl-0.18.8-2.fc16.i686 requires libboost_filesystem-mt.so.1.47.0 libopenvrml-gl-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) libopenvrml-gl-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) libopenvrml-gl-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) openvrml-java-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) openvrml-java-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) openvrml-java-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) openvrml-java-0.18.8-2.fc16.x86_64 requires java-1.6.0-openjdk(x86-64) openvrml-javascript-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) openvrml-javascript-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) openvrml-javascript-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) openvrml-nodes-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) openvrml-nodes-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) openvrml-nodes-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) openvrml-xembed-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) openvrml-xembed-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit)
Re: Please add GNU id-utils to Fedora
On 05/14/2012 10:11 AM, Jim Meyering wrote: Miloslav Trmač wrote: I'm pretty sure that naming conflicts in /usr/bin have happened before in Fedora, I'm not sure how they were resolved. Even in a relatively minimal system, I see many programs installed in both /sbin and /bin, though none seem to conflict: [...] Odd that some point from /bin to /sbin, and others from /sbin to /bin. Some use relative symlinks, others use absolute. These are not comparable to the lid situation. They are either: - programs using consolehelper, the legacy privilege escalation mechanism, which depends on one of the names being a symlink to consolehelper and the other name being the program itself, or - cases where the program historically lived in one directory, then was moved to the other and a symlink in the old directory was added for backwards compat. But it is the same program. They're not comparable to the lid name conflict between two different programs. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On Mon, May 14, 2012 at 12:48:42AM -0400, Jon Masters wrote: On 05/13/2012 02:02 AM, Matthew Garrett wrote: snip From a purely practical perspective, the popularity of OS X as a development platform means that we're likely to see a gradual increase in the amount of code written to assume LLVM-specific functionality. People are just going to have to cope. I do not like this as a strategy. I feel it is necessary in the case of a core toolchain component to set some expectations early on. Those might be Fedora welcomes everyone using LLVM for everything once Red Hat hires some folks to maintain LLVM on the same level as gcc or whatever the wording needs to be. But we're not going to just cope. What's going to happen is we're going to get bitten nastily. Again, how is this different to any other niche toolchain component? I'm not in favour of people using LLVM purely because it's there, but where applications require its functionality the choice is either to use LLVM or not to ship that application. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Packaging Guidelines - creating tarball from VCS with script
Hi, I was wondering if Packaging Guidelines could be amended so that even when creating tarball from VCS, using a standalone shell script would be mandatory (see http://fedoraproject.org/wiki/Packaging:SourceURL#Using_Revision_Control ). I believe this could allow easier reviews and package updates as there would be no need to copypaste code from comments, and checking for package's checksum could be (at least partially) automated for the fedora-review tool. What do you think? Regards, -- Tomas Radej tra...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Guidelines - creating tarball from VCS with script
On 05/14/2012 03:02 PM, Tomas Radej wrote: Hi, I was wondering if Packaging Guidelines could be amended so that even when creating tarball from VCS, using a standalone shell script would be mandatory (see http://fedoraproject.org/wiki/Packaging:SourceURL#Using_Revision_Control ). I believe this could allow easier reviews and package updates as there would be no need to copypaste code from comments, and checking for package's checksum could be (at least partially) automated for the fedora-review tool. What do you think? Regards, I think this is a very good idea, and I'm going to do this for my next package. Thank you for suggesting it. Emanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Drpython testing request. Bugzilla #821296
Sorry my bad am looking for a review On Mon, May 14, 2012 at 3:19 AM, Matthias Runge mru...@matthias-runge.dewrote: On 14/05/12 03:35, Adrian Alves wrote: Hello Guys, Am looking for someone to test DrPython, .. Regards, Adrian.- It is pretty unusual, to test a package before it's released. If you're looking for a reviewer, I'd like to point you to https://fedoraproject.org/wiki/Package_Review_Process#Contributor: 4. Wait for someone to review your package! If that doesn't help, you might offer: Review Swaps If nobody comments on your review request, you might want to mail to a mailing list (devel@lists.fedoraproject.org, for example) asking for a review swap. This is an offer to do a review of someone else's package in exchange for them reviewing your package. This is usually one-for-one, or can be some other private arrangement depending on the difficulty of the respective packages. Just mailing devel@lists saying: hey everybody, here's something to test might work but is usually not a good strategy. There are about 700 packages waiting to get reviewed. Just start a few and the chances for your packages will improve. -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- 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
File IO-Socket-SSL-1.74.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-IO-Socket-SSL: 6a9bc800d136af7709b2fb8dd2e4e8a5 IO-Socket-SSL-1.74.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
Schedule for Monday's FESCo Meeting (2012-05-14)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 17:00UTC (1:00pm EDT) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = No old business this week = New business = #topic #847 Request to have guidance on growing use of LLVM .fesco 847 #topic #849 Build and host request for French live ISOs .fesco 849 #topic #850 Unmounting USB devices is unsafe in Fedora 17 .fesco 850 #topic #851 F18 Feature: procps-ng (next generation procps tools) - https://fedoraproject.org/wiki/Features/procps-ng .fesco 851 #topic #852 F18 Feature: OpenShift Origin - https://fedoraproject.org/wiki/Features/OpenShift_Origin .fesco 852 #topic #853 F18 Feature: New Installer UI - https://fedoraproject.org/wiki/Features/NewInstallerUI .fesco 853 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. 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: Size of official media handouts (was Re: Proposed F18 feature: MiniDebugInfo)
- Original Message - Am Mittwoch, den 09.05.2012, 11:57 -0400 schrieb Adam Jackson: On Wed, 2012-05-09 at 11:45 -0400, Matthias Clasen wrote: On Wed, 2012-05-09 at 13:35 +0200, Kevin Kofler wrote: Alexander Larsson wrote: The feature page lists some of the background and statistics. It also lists some options in how to implement this, which all have various different pros and cons. I'd like to hear what peoples opinions on these are. There is no room left on the KDE live image for installing any sort of debugging information by default. We could easily drop some of less-than-half-complete translations to make room for a bit of minidebuginfo. Last time I looked, translations, fonts, etc made up upwards of 25% of the livecd. Or we could just drop the obsolescent cdrom size limitation... I know I've said this before, but: we should break the CD size barrier precisely so people can't burn things to CDs. If you must burn to optical media, do yourself a favor and burn a DVD, the reduced seek time is entirely worth it. 1G fits on both the smallest MiniDVD format and most extant USB sticks. Let's do it already. As an ambassador and former EMEA media wrangler I tend to agree. Currently both EMEA and NA only do dual layer DVDs, both for live and the installer. EMEA did separate installer vor i386 and x86_64, but after NA had no problems with exclusively providing dual layer, we decided to do the same. This being said I don't care how big we grow as long as we can still fit all 4 desktops (GNOME, KDE, Xfce, LXDE) in 2 arches each on one multi desktop live image. A dual layer DVD has a maximum capacity of 8.5 GB, so fitting 8 x 1 GB is not a problem. We might have to drop Sugar, but if only GNOME and KDE go for 1 GB and Xfce and LXDE still target 700 MB or less, we should even be able to keep it. This being said I am +1 for 1 GB, but please note that I only speak for myself or the NA and EMEA ambassadors. It's probably good idea to bring it on Ambassadors list - to ask non EMEA and NA ambassadors as they are closest to real users (and theirs needs to distribute stuff). R. Kind regards, Christoph -- 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
File AnyEvent-7.01.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-AnyEvent: f26c1d03d7f5fe7d82e6885e5887bf8f AnyEvent-7.01.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: Size of official media handouts (was Re: Proposed F18 feature: MiniDebugInfo)
- Original Message - This being said I am +1 for 1 GB, but please note that I only speak Another thing - we realized that targeting 1 GB is non sense when we have 700 MB, so we moved to 1.5 GB. There was a little difference and no way to put everything on it. With 1 GB target and no 700 MB it makes sense again (and to have the bigger one unlimited). R. for myself or the NA and EMEA ambassadors. Kind regards, Christoph -- 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
[perl-AnyEvent] Update to 7.01
commit c27a78c70d2fb65fdabe53e67ff5262796e4914d
Author: Paul Howarth p...@city-fan.org
Date: Mon May 14 14:25:59 2012 +0100
Update to 7.01
- New upstream release 7.01:
- Fail with EPROTO in AnyEvent::Handle when TLS is requested but not
available, instead of throwing an exception
- Use File::Spec to get the tmpdir in t/*, to avoid needless failures on
(most, not mine :) windows boxes
- New handle read types: tls_detect and tls_autostart
- BR: perl(File::Spec)
perl-AnyEvent.spec | 12 +++-
sources|2 +-
2 files changed, 12 insertions(+), 2 deletions(-)
---
diff --git a/perl-AnyEvent.spec b/perl-AnyEvent.spec
index daba971..12990ae 100644
--- a/perl-AnyEvent.spec
+++ b/perl-AnyEvent.spec
@@ -4,7 +4,7 @@
%global debug_package %{nil}
Name: perl-AnyEvent
-Version:7.0
+Version:7.01
Release:1%{?dist}
Summary:Framework for multiple event loops
Group: Development/Libraries
@@ -27,6 +27,7 @@ BuildRequires: perl(Task::Weaken)
BuildRequires: perl(Time::HiRes)
# Test suite requirements
+BuildRequires: perl(File::Spec)
BuildRequires: perl(Net::SSLeay)
BuildRequires: perl(Test::More)
@@ -118,6 +119,15 @@ make test
%changelog
+* Sun May 13 2012 Paul Howarth p...@city-fan.org - 7.01-1
+- Update to 7.01:
+ - Fail with EPROTO in AnyEvent::Handle when TLS is requested but not
+available, instead of throwing an exception
+ - Use File::Spec to get the tmpdir in t/*, to avoid needless failures on
+(most, not mine :) windows boxes
+ - New handle read types: tls_detect and tls_autostart
+- BR: perl(File::Spec)
+
* Thu Apr 26 2012 Paul Howarth p...@city-fan.org - 7.0-1
- Update to 7.0
- Package generates no debuginfo, so avoid creation of debuginfo sub-package
diff --git a/sources b/sources
index 63e168b..da5fe40 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-af64802330543c2fae3ceedc52370738 AnyEvent-7.0.tar.gz
+f26c1d03d7f5fe7d82e6885e5887bf8f AnyEvent-7.01.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: Welcoming Mattia Meneguzzo
Thank you. I'm proud of being part of the Fedora Project community. I hope I'll do well with your precious help. Regards, *Mattia M.* 2012/5/4 Michel Alexandre Salim sali...@fedoraproject.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all, Please welcome Mattia Meneguzzo (FAS: odysseus) as our newest packager! He's introduced himself in the marketing list previously: http://www.linux-archive.org/fedora-marketing/11379-self-introduction-11.html and his first package, the Zukitwo theme for GTK2/GTK3/Gnome Shell/XFCE, just passed review: https://bugzilla.redhat.com/show_bug.cgi?id=752169 Mattia, I wish you a long, fruitful and pleasant stay, and feel free to ask me, us here, or the packaging if you have queries. Regards, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPo89xAAoJEEr1VKujapN6ZR4H/3TIn65KlFkyJFUyGGK5boKA Bf8hrpMi0BCKpyMT9m9VsVFsz9dKgRQt6xF0b1xjPsDNxRaLQqKGMQ3Yrq8aK3RC mFBJcTQTfQxTQRst1e14GTmhdklzZmlqA2tKzeaHcy/EX2UlM5IOLcNbD2OPkYSr +/eR+1ePL/zxB7wA1VQ29qEqrAtMINoaELbeuI7YOJbFcxJ+LQUEGJ1LoEZzYiUH ayJKc88KjLQ6BAAyqrAZnkktqmTVHGZYrjfnzJQvEV1g+acP5GXZzVmzhlyj/ve8 Bpfjf1sCNo5RiAJl9gGUtPvep5ciT/W8dhP2C2prF8Xh+QNig0xaTSSrQlRZwHI= =8MO1 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
CDDL+GPL still an issue?
Hello, I would like to know if there are still issues with CDDL packages in Fedora. It is not my intention to start a flame, I'm simply asking if that's still the case or if I can fill a Review Request for the infamous cdrtools in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=507108 http://fedoraproject.org/wiki/Licensing#Good_Licenses Regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide ext4/virtio FS performance hit (10x slower) ?
On 05/13/2012 12:00 AM, Reindl Harald wrote: how can someone find out if it is a debug-kernel? even the satble ones seems to have a ton of debug options enabled especially CONFIG_DEBUG_KERNEL=y See http://fedoraproject.org/wiki/KernelDebugStrategy to find what kernel config options to look for. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Size of official media handouts (was Re: Proposed F18 feature: MiniDebugInfo)
On 05/14/2012 01:40 AM, Alexander Larsson wrote: I understand that you want to ship isolated images for each of the desktops in this combination image, as that is what is tested, etc. However, there is gonna be a lot of duplicated bits in those images. Can't we use some form of image where the duplicated blocks can be shared. Seems like an obvious win to me. The format of an iso9660 directory makes it easy to share entire files: just set the first sector number of the contiguous extent. However the multi-session aspect of the all-in-one platter might put each session into its own container, which might interfere with sharing across sessions. Intentional un-checked wrap-around comes to mind. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CDDL+GPL still an issue?
On Mon, May 14, 2012 at 9:06 AM, Simone Caronni negativ...@gmail.com wrote: Hello, I would like to know if there are still issues with CDDL packages in Fedora. It is not my intention to start a flame, I'm simply asking if that's still the case or if I can fill a Review Request for the infamous cdrtools in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=507108 http://fedoraproject.org/wiki/Licensing#Good_Licenses http://fedoraproject.org/wiki/Licensing#SoftwareLicenses It's fine, so long as it's not mixed in the same software with GPL-compatible code, which is what, for example, keeps ZFS out of the kernel but lets us ship zfs-fuse. -J Regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CDDL+GPL still an issue?
On Mon, May 14, 2012 at 04:06:19PM +0200, Simone Caronni wrote: I would like to know if there are still issues with CDDL packages in Fedora. I'm not aware that there ever have been. It is not my intention to start a flame, I'm simply asking if that's still the case or if I can fill a Review Request for the infamous cdrtools in Fedora: cdrtools used to link GPLed code with CDDLed code. Such a binary is undistributable. If it still does that then there's no way for this code to be distributed by Fedora. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Guidelines - creating tarball from VCS with script
On Mon, May 14, 2012 at 03:02:23PM +0200, Tomas Radej wrote: Hi, I was wondering if Packaging Guidelines could be amended so that even when creating tarball from VCS, using a standalone shell script would be mandatory (see http://fedoraproject.org/wiki/Packaging:SourceURL#Using_Revision_Control ). I believe this could allow easier reviews and package updates as there would be no need to copypaste code from comments, and checking for package's checksum could be (at least partially) automated for the fedora-review tool. What do you think? Automating of the package's checksum won't work for many VCS's . git, for instance, does not preserve timestamps. So the tarball created from a git snapshot will have a different checksum for each checkout. I personally prefer to have the checkout instructions in comments. It makes it easier to review what the person did and interrupts my thoughts less when I can see what the person did to produce the tarball in the same window as I'm looking at the spec file. Having to open up a second file to see if the checkout commands are hitting the canonical source repository and that they contain enough information to checkout only a single version is a distraction. -Toshio pgpntlzY0cQvc.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CDDL+GPL still an issue?
On 05/14/2012 10:06 AM, Simone Caronni wrote: Hello, I would like to know if there are still issues with CDDL packages in Fedora. It is not my intention to start a flame, I'm simply asking if that's still the case or if I can fill a Review Request for the infamous cdrtools in Fedora: No. We're not including cdrtools in Fedora. Consider it pre-emptively legally blocked. The last time this topic was brought up, I took the time to identify all of the legal issues around it (and attempt to dispel some of Mr. Schilling's crazy): https://www.redhat.com/archives/fedora-legal-list/2009-July/msg0.html I've also added it to the Forbidden Items list: https://fedoraproject.org/wiki/Forbidden_items#cdrtools ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Guidelines - creating tarball from VCS with script
I agree with Toshio on this. Depending on how the VCS behaves with checkout/cloning, it will be difficult to get predictable results in a usable way through a script. Commenting in the spec file is the best way to go in my opinion. On May 14, 2012 9:22 AM, Toshio Kuratomi a.bad...@gmail.com wrote: On Mon, May 14, 2012 at 03:02:23PM +0200, Tomas Radej wrote: Hi, I was wondering if Packaging Guidelines could be amended so that even when creating tarball from VCS, using a standalone shell script would be mandatory (see http://fedoraproject.org/wiki/Packaging:SourceURL#Using_Revision_Control ). I believe this could allow easier reviews and package updates as there would be no need to copypaste code from comments, and checking for package's checksum could be (at least partially) automated for the fedora-review tool. What do you think? Automating of the package's checksum won't work for many VCS's . git, for instance, does not preserve timestamps. So the tarball created from a git snapshot will have a different checksum for each checkout. I personally prefer to have the checkout instructions in comments. It makes it easier to review what the person did and interrupts my thoughts less when I can see what the person did to produce the tarball in the same window as I'm looking at the spec file. Having to open up a second file to see if the checkout commands are hitting the canonical source repository and that they contain enough information to checkout only a single version is a distraction. -Toshio -- 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: Packaging Guidelines - creating tarball from VCS with script
Le 14/05/2012 16:22, Toshio Kuratomi a écrit : What do you think? I personally prefer to have the checkout instructions in comments. +1 Except for some very complex scripts for which it make sense to have a shell script. Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CDDL+GPL still an issue?
Thanks! To better understand; in similar cases, how do I know that I can't link with GPL? The fact that both GPLv3 Compat? and GPLv2 Compat? columns have their value to NO in the CDDL or BSD Protection line can be a clear indication of that? http://fedoraproject.org/wiki/Licensing#Good_Licenses Regards, --Simone On 14 May 2012 16:27, Tom Callaway tcall...@redhat.com wrote: On 05/14/2012 10:06 AM, Simone Caronni wrote: Hello, I would like to know if there are still issues with CDDL packages in Fedora. It is not my intention to start a flame, I'm simply asking if that's still the case or if I can fill a Review Request for the infamous cdrtools in Fedora: No. We're not including cdrtools in Fedora. Consider it pre-emptively legally blocked. The last time this topic was brought up, I took the time to identify all of the legal issues around it (and attempt to dispel some of Mr. Schilling's crazy): https://www.redhat.com/archives/fedora-legal-list/2009-July/msg0.html I've also added it to the Forbidden Items list: https://fedoraproject.org/wiki/Forbidden_items#cdrtools ~tom == Fedora Project -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CDDL+GPL still an issue?
On Mon, May 14, 2012 at 9:27 AM, Tom Callaway tcall...@redhat.com wrote: On 05/14/2012 10:06 AM, Simone Caronni wrote: Hello, I would like to know if there are still issues with CDDL packages in Fedora. It is not my intention to start a flame, I'm simply asking if that's still the case or if I can fill a Review Request for the infamous cdrtools in Fedora: No. We're not including cdrtools in Fedora. Consider it pre-emptively legally blocked. The last time this topic was brought up, I took the time to identify all of the legal issues around it (and attempt to dispel some of Mr. Schilling's crazy): https://www.redhat.com/archives/fedora-legal-list/2009-July/msg0.html I've also added it to the Forbidden Items list: https://fedoraproject.org/wiki/Forbidden_items#cdrtools Ah, the memories. -J ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Packaging issue: what to do about debuginfo after arch-noarch change?
I recently converted mysql-connector-java from arch to noarch (it used to use GCJ to build, now it doesn't). Martin Cermak pointed out to me that if you had the debuginfo subpackage installed, and you upgrade, the old debuginfo will still be there even though it's now irrelevant. Is this a bug, and if so what should I do about it? It seems to me that it's not a bug, because AFAICS there has never been any attempt to enforce that only relevant debuginfo packages are installed. For instance, there isn't any Requires: at all from a debuginfo package to its base package, let alone an exact-version-match Requires:. It was suggested that I could add an Obsoletes: line to the specfile to get rid of the old debuginfo package, but this seems a bit weird to me, and inconsistent with the fact that there aren't Requires: linkages. I don't see anything in the packaging guidelines that addresses the point. Given that we're converting most Java packages to noarch, perhaps the issue comes up often enough to justify having a policy? regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CDDL+GPL still an issue?
On Mon, May 14, 2012 at 9:32 AM, Jon Ciesla limburg...@gmail.com wrote: On Mon, May 14, 2012 at 9:27 AM, Tom Callaway tcall...@redhat.com wrote: On 05/14/2012 10:06 AM, Simone Caronni wrote: Hello, I would like to know if there are still issues with CDDL packages in Fedora. It is not my intention to start a flame, I'm simply asking if that's still the case or if I can fill a Review Request for the infamous cdrtools in Fedora: No. We're not including cdrtools in Fedora. Consider it pre-emptively legally blocked. The last time this topic was brought up, I took the time to identify all of the legal issues around it (and attempt to dispel some of Mr. Schilling's crazy): https://www.redhat.com/archives/fedora-legal-list/2009-July/msg0.html I've also added it to the Forbidden Items list: https://fedoraproject.org/wiki/Forbidden_items#cdrtools Ah, the memories. -J ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Mr Schilling is just a special kind of crazy. He seems to have a rather warped view of copyright law. And since when were forks illegal? Do we know exactly what parts of cdrtools cause the legal incompatibilities? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CDDL+GPL still an issue?
On 05/14/2012 10:32 AM, Simone Caronni wrote: Thanks! To better understand; in similar cases, how do I know that I can't link with GPL? The fact that both GPLv3 Compat? and GPLv2 Compat? columns have their value to NO in the CDDL or BSD Protection line can be a clear indication of that? Yes. CDDL is considered to be GPLv2 and GPLv3 incompatible, so cases of direct linking or code copying between GPLv2|GPLv3 and CDDL code result in a pile of incompatible licenses (and effectively undistributable) results, so they are not permitted in Fedora. cdrtools is a particularly egregious case, which is why I added it to the Forbidden Items list. (To be clear, CDDL-only works that do not depend upon or link to GPL code are okay for Fedora, even if I personally think the CDDL license is a terrible choice.) ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CDDL+GPL still an issue?
On 05/14/2012 10:40 AM, Conan Kudo (ニール・ゴンパ) wrote: Mr Schilling is just a special kind of crazy. He seems to have a rather warped view of copyright law. And since when were forks illegal? Do we know exactly what parts of cdrtools cause the legal incompatibilities? If you really want me to revisit the details of this... item... you will need to compensate me for it with high quality liquor in advance. I can provide a mailing address upon request. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging issue: what to do about debuginfo after arch-noarch change?
On 05/14/2012 10:34 AM, Tom Lane wrote: I recently converted mysql-connector-java from arch to noarch (it used to use GCJ to build, now it doesn't). Martin Cermak pointed out to me that if you had the debuginfo subpackage installed, and you upgrade, the old debuginfo will still be there even though it's now irrelevant. Is this a bug, and if so what should I do about it? It seems to me that it's not a bug, because AFAICS there has never been any attempt to enforce that only relevant debuginfo packages are installed. For instance, there isn't any Requires: at all from a debuginfo package to its base package, let alone an exact-version-match Requires:. It was suggested that I could add an Obsoletes: line to the specfile to get rid of the old debuginfo package, but this seems a bit weird to me, and inconsistent with the fact that there aren't Requires: linkages. I don't see anything in the packaging guidelines that addresses the point. Given that we're converting most Java packages to noarch, perhaps the issue comes up often enough to justify having a policy? Hmm. I'm inclined to say that we ought to resolve this either in anaconda or preupgrade by running some sort of cleanup script that looks for orphan debuginfo and flushes them down the drain, as opposed to carrying Obsoletes. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CDDL+GPL still an issue?
No thanks, no revisiting; searches in google pointing to flame wars are enough! :D --Simone On 14 May 2012 16:42, Tom Callaway tcall...@redhat.com wrote: On 05/14/2012 10:40 AM, Conan Kudo (ニール・ゴンパ) wrote: Mr Schilling is just a special kind of crazy. He seems to have a rather warped view of copyright law. And since when were forks illegal? Do we know exactly what parts of cdrtools cause the legal incompatibilities? If you really want me to revisit the details of this... item... you will need to compensate me for it with high quality liquor in advance. I can provide a mailing address upon request. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging issue: what to do about debuginfo after arch-noarch change?
Tom Callaway tcall...@redhat.com writes: On 05/14/2012 10:34 AM, Tom Lane wrote: I recently converted mysql-connector-java from arch to noarch (it used to use GCJ to build, now it doesn't). Martin Cermak pointed out to me that if you had the debuginfo subpackage installed, and you upgrade, the old debuginfo will still be there even though it's now irrelevant. Is this a bug, and if so what should I do about it? Hmm. I'm inclined to say that we ought to resolve this either in anaconda or preupgrade by running some sort of cleanup script that looks for orphan debuginfo and flushes them down the drain, as opposed to carrying Obsoletes. Note that the case Martin was concerned about was a plain old yum update of the package, not an OS-wide upgrade. I'm unsure to what extent yum knows about debuginfo, but that's where smarts would need to be added to address his concern. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
TC5 Live Desktop burned to actual media is not EFI bootable on MBP41. The only option for the media is Windows. I'm not sure if this regression occurred in TC4 or TC5. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging issue: what to do about debuginfo after arch-noarch change?
On 05/14/2012 11:02 AM, Tom Lane wrote: Tom Callaway tcall...@redhat.com writes: On 05/14/2012 10:34 AM, Tom Lane wrote: I recently converted mysql-connector-java from arch to noarch (it used to use GCJ to build, now it doesn't). Martin Cermak pointed out to me that if you had the debuginfo subpackage installed, and you upgrade, the old debuginfo will still be there even though it's now irrelevant. Is this a bug, and if so what should I do about it? Hmm. I'm inclined to say that we ought to resolve this either in anaconda or preupgrade by running some sort of cleanup script that looks for orphan debuginfo and flushes them down the drain, as opposed to carrying Obsoletes. Note that the case Martin was concerned about was a plain old yum update of the package, not an OS-wide upgrade. I'm unsure to what extent yum knows about debuginfo, but that's where smarts would need to be added to address his concern. I don't think yum cares, it just sees debuginfo packages as packages from the debuginfo repo. Debuginfo packages don't have Requires of the base package, so they should never be breaking deps in situations like the one above, and I'm not sure we want to be slowing down the yum transaction to do a reaper check on every transaction (hence, preupgrade or anaconda). ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-Net-OpenSSH
perl-Net-OpenSSH has broken dependencies in the rawhide tree:
On x86_64:
perl-Net-OpenSSH-0.57-2.fc18.noarch requires
openssh-clients(%{__isa_name}-%{__isa_bits})
On i386:
perl-Net-OpenSSH-0.57-2.fc18.noarch requires
openssh-clients(%{__isa_name}-%{__isa_bits})
Please resolve this as soon as possible.
--
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
Broken dependencies: perl-SQL-Translator
perl-SQL-Translator has broken dependencies in the rawhide tree: On x86_64: perl-SQL-Translator-0.11011-1.fc18.noarch requires perl(SQL::Translator::Schema::Graph::Port) perl-SQL-Translator-0.11011-1.fc18.noarch requires perl(SQL::Translator::Schema::Graph::Node) perl-SQL-Translator-0.11011-1.fc18.noarch requires perl(SQL::Translator::Schema::Graph::HyperEdge) perl-SQL-Translator-0.11011-1.fc18.noarch requires perl(SQL::Translator::Schema::Graph::Edge) perl-SQL-Translator-0.11011-1.fc18.noarch requires perl(SQL::Translator::Schema::Graph::CompoundEdge) On i386: perl-SQL-Translator-0.11011-1.fc18.noarch requires perl(SQL::Translator::Schema::Graph::Port) perl-SQL-Translator-0.11011-1.fc18.noarch requires perl(SQL::Translator::Schema::Graph::Node) perl-SQL-Translator-0.11011-1.fc18.noarch requires perl(SQL::Translator::Schema::Graph::HyperEdge) perl-SQL-Translator-0.11011-1.fc18.noarch requires perl(SQL::Translator::Schema::Graph::Edge) perl-SQL-Translator-0.11011-1.fc18.noarch requires perl(SQL::Translator::Schema::Graph::CompoundEdge) Please resolve this as soon as possible. -- 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: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On Sun, 2012-05-13 at 12:21 +0700, Michel Alexandre Salim wrote: Apart from the worrying test suite results on secondary archs, actually it's the libstdc++ issue that's causing the most headache. How much effort does it take to maintain a compatibility version of libstdc++? It'd make clang much more useful if we're not caught between upstream (that abandons released versions) and the Fedora GCC team's fast update cycles. Apologies, I'm not familiar with this part of the eternal waking nightmare called C++. Can you give more details? - 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
rawhide report: 20120514 changes
Compose started at Mon May 14 08:15:03 UTC 2012 Broken deps for x86_64 -- [389-admin] 389-admin-1.1.28-1.fc18.i686 requires libicuuc.so.48 389-admin-1.1.28-1.fc18.i686 requires libicui18n.so.48 389-admin-1.1.28-1.fc18.i686 requires libicudata.so.48 389-admin-1.1.28-1.fc18.x86_64 requires libicuuc.so.48()(64bit) 389-admin-1.1.28-1.fc18.x86_64 requires libicui18n.so.48()(64bit) 389-admin-1.1.28-1.fc18.x86_64 requires libicudata.so.48()(64bit) [389-adminutil] 389-adminutil-1.1.15-2.fc17.i686 requires libicuuc.so.48 389-adminutil-1.1.15-2.fc17.i686 requires libicui18n.so.48 389-adminutil-1.1.15-2.fc17.i686 requires libicudata.so.48 389-adminutil-1.1.15-2.fc17.x86_64 requires libicuuc.so.48()(64bit) 389-adminutil-1.1.15-2.fc17.x86_64 requires libicui18n.so.48()(64bit) 389-adminutil-1.1.15-2.fc17.x86_64 requires libicudata.so.48()(64bit) [389-dsgw] 389-dsgw-1.1.9-2.fc17.x86_64 requires libicuuc.so.48()(64bit) 389-dsgw-1.1.9-2.fc17.x86_64 requires libicui18n.so.48()(64bit) 389-dsgw-1.1.9-2.fc17.x86_64 requires libicudata.so.48()(64bit) [aeolus-all] aeolus-all-0.4.0-2.fc17.noarch requires aeolus-conductor-doc = 0:0.4.0-2.fc17 aeolus-all-0.4.0-2.fc17.noarch requires aeolus-conductor-daemons = 0:0.4.0-2.fc17 [aeolus-configserver] aeolus-configserver-0.4.5-1.fc18.noarch requires ruby-nokogiri [axis2c] axis2c-1.6.0-4.fc17.i686 requires httpd-mmn = 0:20051115-x86-32 axis2c-1.6.0-4.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64 [bibletime] bibletime-2.9.1-1.fc18.x86_64 requires libicuuc.so.48()(64bit) bibletime-2.9.1-1.fc18.x86_64 requires libicui18n.so.48()(64bit) [boost141] boost141-graph-1.41.0-2.fc17.i686 requires libicuuc.so.48 boost141-graph-1.41.0-2.fc17.i686 requires libicui18n.so.48 boost141-graph-1.41.0-2.fc17.x86_64 requires libicuuc.so.48()(64bit) boost141-graph-1.41.0-2.fc17.x86_64 requires libicui18n.so.48()(64bit) boost141-regex-1.41.0-2.fc17.i686 requires libicuuc.so.48 boost141-regex-1.41.0-2.fc17.i686 requires libicui18n.so.48 boost141-regex-1.41.0-2.fc17.x86_64 requires libicuuc.so.48()(64bit) boost141-regex-1.41.0-2.fc17.x86_64 requires libicui18n.so.48()(64bit) [couchdb] couchdb-1.1.1-1.fc18.x86_64 requires libicuuc.so.48()(64bit) couchdb-1.1.1-1.fc18.x86_64 requires libicui18n.so.48()(64bit) couchdb-1.1.1-1.fc18.x86_64 requires libicudata.so.48()(64bit) [dustmite] dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires libphobos2-ldc.so()(64bit) [evolution-couchdb] evolution-couchdb-0.5.91-10.fc18.x86_64 requires libedata-cal-1.2.so.15()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libedata-book-1.2.so.13()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libecal-1.2.so.11()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libcamel-1.2.so.33()(64bit) [evolution-rss] 1:evolution-rss-0.3.91-1.fc18.x86_64 requires libedataserverui-3.0.so.1()(64bit) 1:evolution-rss-0.3.91-1.fc18.x86_64 requires libcamel-1.2.so.33()(64bit) [fawkes] fawkes-plugin-xmlrpc-0.4.2-10.fc18.x86_64 requires libxmlrpc_server++.so.7()(64bit) fawkes-plugin-xmlrpc-0.4.2-10.fc18.x86_64 requires libxmlrpc++.so.7()(64bit) [fldigi] fldigi-3.21.37-2.fc18.x86_64 requires libxmlrpc_server_abyss++.so.7()(64bit) fldigi-3.21.37-2.fc18.x86_64 requires libxmlrpc_server++.so.7()(64bit) fldigi-3.21.37-2.fc18.x86_64 requires libxmlrpc++.so.7()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 gcc-python2-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 gcc-python3-debug-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 gcc-python3-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 [ghc-wai-extra] ghc-wai-extra-0.4.6-3.fc18.i686 requires libHSzlib-enum-0.2.1-ghc7.4.1.so ghc-wai-extra-0.4.6-3.fc18.i686 requires libHSzlib-bindings-0.0.3.2-ghc7.4.1.so ghc-wai-extra-0.4.6-3.fc18.i686 requires ghc(zlib-enum-0.2.1-55af94f47edaf6ddd74e441a7a34ef7e) ghc-wai-extra-0.4.6-3.fc18.i686 requires ghc(zlib-bindings-0.0.3.2-3d82a54b78146286e86c5a9fa9085ef2) ghc-wai-extra-0.4.6-3.fc18.x86_64 requires libHSzlib-enum-0.2.1-ghc7.4.1.so()(64bit) ghc-wai-extra-0.4.6-3.fc18.x86_64 requires libHSzlib-bindings-0.0.3.2-ghc7.4.1.so()(64bit) ghc-wai-extra-0.4.6-3.fc18.x86_64 requires ghc(zlib-enum-0.2.1-6264df6f05d62c31c73f13219fe69f53) ghc-wai-extra-0.4.6-3.fc18.x86_64 requires ghc(zlib-bindings-0.0.3.2-d83646b762e4c3d5f1dcf4b8665bb1c5) ghc-wai-extra-devel-0.4.6-3.fc18.i686 requires ghc-devel(zlib-enum-0.2.1-55af94f47edaf6ddd74e441a7a34ef7e)
Re: Another heads up for F17 upgrades from F16 (via yum)
Hi Adam, TC4 won't install, and because of this, thinking that it was not supposed to install, I was wondering what one was supposed to do with it. I realise that my thought-process may have been wrong and it should have been installable, but I thought I would come from that what happened was that which was supposed to take place. hope this helps, Richard On May 13, 2012 10:36 PM, Adam Williamson awill...@redhat.com wrote: On Sun, 2012-05-13 at 21:01 -0700, Richard Vickery wrote: thanks, On Sun, May 13, 2012 at 9:01 PM, Richard Vickery richard.vicker...@gmail.com wrote: How exactly is the Fedora-17-TC4-i386-DVD.iso file supposed to work? Could you clarify your question and its relationship to this thread? Are you having some specific problem with TC4, or are you asking for general information as to how to use either ISO files in general or Fedora installer images in particular? Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Size of official media handouts (was Re: Proposed F18 feature: MiniDebugInfo)
Jaroslav Reznik (jrez...@redhat.com) said: - Original Message - This being said I am +1 for 1 GB, but please note that I only speak Another thing - we realized that targeting 1 GB is non sense when we have 700 MB, so we moved to 1.5 GB. There was a little difference and no way to put everything on it. With 1 GB target and no 700 MB it makes sense again (and to have the bigger one unlimited). How so? 700MB cutoff is for CDs. A 1GB cutoff is for USB sticks. I'm still a bit baffled that a 3.5 MB increase on a 700MB live image is considered a complete showstopper. That's one git package, for example; I would hope that creative dependency trimming can find that space. (Or reorganization of boot images, for example.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
Some feedback from a succefull installation of F17 TC4 on a Macbook Air 13 (Model number A1369). Unfortunately the TC5 didn't boot. For TC4 we had to change label grub option to LIVE in order to boot. Is this a typo? Anaconda worked just fine and installation was completed succefully. Only thing didn't work as expected is that grub overwrited OsX bootloader but didn't create an OsX menu entry. We manually had to add a chainloader menu entry for /usr/share/standalone/i386/boot.efi Other than that everything seems to work great. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes from today's FESCo Meeting (2012-05-14)
=== #fedora-meeting: FESCO (2012-05-14) === Meeting started by sgallagh at 17:00:13 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-05-14/fesco.2012-05-14-17.00.log.html . Meeting summary --- * init process (sgallagh, 17:00:13) * limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m all present (sgallagh, 17:03:25) * #847 Request to have guidance on growing use of LLVM (sgallagh, 17:04:03) * AGREED: Packages may only build with an alternative compiler to gcc if upstream does not support gcc (6 +1) (sgallagh, 17:50:30) * #849 Build and host request for French live ISOs (sgallagh, 17:50:37) * AGREED: Send this to the Fedora Advisory Board (9 +1) (sgallagh, 17:58:23) * #850 Unmounting USB devices is unsafe in Fedora 17 (sgallagh, 17:58:36) * AGREED: USB unmounting issue is a blocker, needs immediate attention (9 +1) (sgallagh, 18:11:26) * #851 F18 Feature: procps-ng (next generation procps tools) - https://fedoraproject.org/wiki/Features/procps-ng (sgallagh, 18:11:34) * AGREED: Feature procps-ng is accepted (9 +1) (sgallagh, 18:14:47) * #852 F18 Feature: OpenShift Origin - https://fedoraproject.org/wiki/Features/OpenShift_Origin (sgallagh, 18:14:52) * AGREED: Feature: OpenShift Origin is accepted (9 +1) (sgallagh, 18:16:02) * #853 F18 Feature: New Installer UI - https://fedoraproject.org/wiki/Features/NewInstallerUI (sgallagh, 18:16:06) * AGREED: Feature: New Installer UI is accepted (9 +1) (sgallagh, 18:19:51) * Next week's chair (sgallagh, 18:20:11) * AGREED: t8m will chair the 2012-05-21 meeting (sgallagh, 18:20:47) * Open Floor (sgallagh, 18:20:53) * ACTION: sgallagh to file FPC ticket for new compiler policy (sgallagh, 18:23:33) * ACTION: sgallagh to file an Advisory Board ticket for the localized compose (sgallagh, 18:24:35) Meeting ended at 18:35:13 UTC. Action Items * sgallagh to file FPC ticket for new compiler policy * sgallagh to file an Advisory Board ticket for the localized compose Action Items, by person --- * sgallagh * sgallagh to file FPC ticket for new compiler policy * sgallagh to file an Advisory Board ticket for the localized compose * **UNASSIGNED** * (none) People Present (lines said) --- * sgallagh (103) * pjones (76) * notting (63) * mitr (60) * t8m (55) * mjg59 (50) * nirik (49) * limburgher (30) * mmaslano (15) * zodbot (11) * nb (9) * mclasen (6) * drago01 (5) * kparal (1) * tibbs|w (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot 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: default media size [Was: Proposed F18 feature: MiniDebugInfo]
On 05/12/2012 09:51 PM, Matthew Garrett wrote: On Thu, May 10, 2012 at 11:00:48AM -0400, Adam Jackson wrote: So the set of people we'd be inconveniencing is exactly the set of people with no bandwidth and the inability to boot from anything larger than a CD. Not only that - the people who have no bandwidth, the inability to boot from anything larger than a CD and no USB ports that can be bootstrapped from a bootloader sitting on a CD or floppy. USB has been required by Microsoft's logo program since 1999 and was effectively ubiquitous on Pentium 2 before that, so the set of hardware we're ruling out is at least 13 years old and more realistically probably 15. We've already dropped support for x86 hardware that was in production more recently than that. Reality can differ from the press releases. I have two running machines that contradict the conclusions above. Instead of 13 or 15 years, such an effective cutoff would be closer to about 8 years. I consider that to be uncomfortably young to be declared obsolete, especially when the declaration is issued at the end of a release cycle instead of at the beginning. The most important issue in this thread is ability to boot from USB2.0. Although the Microsoft logo endorsement may have required USB since 1999, USB1.1 (12Mbit/s) was sufficient in the early years, and the ability to boot from USB also was not required at first. In my experience, the ability to boot from USB2.0 was not common in consumer hardware until around 2005 [see USB mass storage in http://en.wikipedia.org/wiki/USB2.0#USB_2.0 ] which is only 7 years ago. Below are the details on my counterexamples. Exactly eleven years ago in May 2001 I purchased new from Dell an Inspiron 4000 laptop: 700MHz/550MHz Pentium III (Coppermine: sse but no sse2), 16KB L1, 256KB L2, 64MB RAM, ATI Rage128 graphics, 10GB harddrive, CD drive, outboard floppy, 10/100 ethernet, 33.6Kb winmodem, VGA out, projector out, serial, parallel, dock, audio in/out, IrDA, dual PCMCIA slots, 1 PS/2, and 1 USB *1.1* port (12Mbit/s); WindowsME [logo] installed. The laptop was positioned towards the high end of the SOHO (Small Office / Home Office) market. Its outstanding feature is a 1024x768 display panel; at the time many others were 800x600. Over the years the machine has been upgraded to 384MB RAM, 40GB harddrive, and USB2.0 via PCMCIA card. With a new battery and charger it still provides hours of use per charge. The laptop cannot boot from USB, and the BIOS also has the 1023-cylinder limit for booting. None of the Fedora install .iso contain a CD-to-USB trampoline for booting. Thus I copy the kernel and initrd onto a small partition that resides below cylinder 1024, and boot them specifying root=live:CDLABEL=label. Yesterday I used this technique successfully to install default Graphical Desktop of Fedora 17 TC5 from 4GB USB2.0 flash media. Install took 80 minutes (versus 17 minutes on a 3GHz Core-i5), and the LED for harddrive activity indicated page thrashing during only a few packages. Using DVD it may have taken about 3 hours or more because of time for seeks and for spin up/down on longer packages. Gnome3 runs acceptably in fallback mode; XFCE runs well. LibreOffice Writer does not lag. So a CD-to-USB trampoline with good Usability for booting the installer might remove the obsolete tag on this laptop. After the laptop, about one year later in 2002 I built a desktop using ASUS P4B266 board: 1.6 GHz Pentium4 (Northwood: NetBurst with sse2), 2x256MB DDR (DDR1; now 2x512MB), PATA harddrives [upgraded twice], CD drive [upgraded to DVD], 2x USB1.1, 4x USB2.0, AGP+PCI slots, etc. Except for being self-built, the box qualified for WindowsME logo. Although the hardware was still not old in 2003/2004, the BIOS cannot boot from USB. Only two weeks ago, both Fry's and Newegg [leading parts sellers in USA] had a sale on 1GB DDR1 DIMM ($42.) This machine runs Windows XP, Fedora Core 4 (with Win4Lin), and Fedora 17. Its only detrimental factors are its louder fans (2nd generation, along with power supply), and the current ATI Radeon 9250 graphics card [RV280; new in 2006] which Gnome3 does not support except in fallback mode. XFCE runs well. Not being able to boot from USB2.0 casts a shadow on this box that is otherwise as good as new in 2003/2004, or even more recently than that in some ways. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Size of official media handouts (was Re: Proposed F18 feature: MiniDebugInfo)
On Mon, 2012-05-14 at 13:48 -0400, Bill Nottingham wrote: I'm still a bit baffled that a 3.5 MB increase on a 700MB live image is considered a complete showstopper. That's one git package, for example; I would hope that creative dependency trimming can find that space. (Or reorganization of boot images, for example.) There's a modest amount of low-hanging fruit if people really cared about image size. For example, here's a way to shrink the (uncompressed) live filesystem by 30M: https://bugzilla.redhat.com/show_bug.cgi?id=812975#c4 I do find the concern for difficult install scenarios to be noble, but I would tend to class that as a different problem from producing a useful live image that also happens to be installable. But clearly the objection here is about doing more work more than changing the image size. - 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
Question regarding version + svn revision on packaging
One of the packages I'm submitting for Unknown Horizons support (python-enet or pyenet) has no real version and it's just svn revision 24 (python bindings for ENet); What would be the best way to express this in the spec file? ex: Version: 0.0.0+svn24 Or any other? Opinions most welcome. -- Nelson Marques // I've stopped trying to understand sandwiches with a third piece of bread in the middle... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding version + svn revision on packaging
On Mon, May 14, 2012 at 1:51 PM, Nelson Marques nmo.marq...@gmail.com wrote:
One of the packages I'm submitting for Unknown Horizons support
(python-enet or pyenet) has no real version and it's just svn revision
24 (python bindings for ENet);
What would be the best way to express this in the spec file?
ex: Version: 0.0.0+svn24
Or any other? Opinions most welcome.
One 0 is enough, no need to assume minor and patch versions. Also, I
think + is a Debian thing, for Fedora it would just be part of the
release. For a pre-release package.:
Version: 0
Release: 0.1.svn24%{?dist}
or something like that, would give:
package name-0-0.1.svn24.dist
see:
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding version + svn revision on packaging
Thanks, looks cool to me, I'll use that if there are no objections :)
2012/5/14 Richard Shaw hobbes1...@gmail.com:
On Mon, May 14, 2012 at 1:51 PM, Nelson Marques nmo.marq...@gmail.com wrote:
One of the packages I'm submitting for Unknown Horizons support
(python-enet or pyenet) has no real version and it's just svn revision
24 (python bindings for ENet);
What would be the best way to express this in the spec file?
ex: Version: 0.0.0+svn24
Or any other? Opinions most welcome.
One 0 is enough, no need to assume minor and patch versions. Also, I
think + is a Debian thing, for Fedora it would just be part of the
release. For a pre-release package.:
Version: 0
Release: 0.1.svn24%{?dist}
or something like that, would give:
package name-0-0.1.svn24.dist
see:
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Nelson Marques
// I've stopped trying to understand sandwiches with a third piece of
bread in the middle...
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]
That doesn't seem to contradict me? If we went with this approach then we'd obviously want to include a CD-USB bootloader, but otherwise it sounds like there'd be no problem doing a USB install on that hardware. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding version + svn revision on packaging
On Mon, May 14, 2012 at 08:00:22PM +0100, Nelson Marques wrote:
Thanks, looks cool to me, I'll use that if there are no objections :)
2012/5/14 Richard Shaw hobbes1...@gmail.com:
On Mon, May 14, 2012 at 1:51 PM, Nelson Marques nmo.marq...@gmail.com
wrote:
One of the packages I'm submitting for Unknown Horizons support
(python-enet or pyenet) has no real version and it's just svn revision
24 (python bindings for ENet);
What would be the best way to express this in the spec file?
ex: Version: 0.0.0+svn24
Or any other? Opinions most welcome.
One 0 is enough, no need to assume minor and patch versions. Also, I
think + is a Debian thing, for Fedora it would just be part of the
release. For a pre-release package.:
Version: 0
Release: 0.1.svn24%{?dist}
or something like that, would give:
package name-0-0.1.svn24.dist
see:
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages
Yep -- we'd want the date in there too like this:
Version: 0
Release: 0.1.20120412svn24%{?dist}
-Toshio
pgpMlmb21yTyk.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))
On Mon, 14.05.12 14:45, Stephen Gallagher (sgall...@redhat.com) wrote: * #851 F18 Feature: procps-ng (next generation procps tools) - https://fedoraproject.org/wiki/Features/procps-ng (sgallagh, 18:11:34) * AGREED: Feature procps-ng is accepted (9 +1) (sgallagh, 18:14:47) Ahem. I think is is a really bad idea. -ng packages point to a huge failure in the handling of the packages in question, and should not be deemed a feature for Linux but a failure of Linux Karel Zak has made clear that he is happy to merge procps into util-linux (Karel is both upstream and downstream for u-l), and has offered to do the work. util-linux is the much better place for these utilities, so that common code, the development infrastructure, the build system, the documentation scheme, the release cycle and the maintainership can be shared. There's really no point in all the bureaucracy for such a transition if it just replaces one bad situation with another bad situation. If you do a transition then do it right and merge procps into util-linux. We really don't need two packages with such overlapping functionality. Both of them had long phases in their history where they were slowly rotting along. The best way to fight that is having a single package from it so that this easier kept an eye on. They do very similar stuff, they need the same expertise from the hackers and maintainers and they should justbe one. Really, nobody needs transitions, renames and multiple independent repos for stuff that is very very similar in purpose and behaviour. I'd really like to see FESCO strongly ask the people behind procps-ng to help working in the integration of its tools into util-linux, to make the basic set of tools more nicely integrated rather than continue to grow apart! There's really no point in just rubberstamping everything people suggest. FESCO should push people in the right direction, and push them towards collaboration. FESCO, please steer fedora (and Linux) in the right direction here, that's your job! Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Size of official media handouts (was Re: Proposed F18 feature: MiniDebugInfo)
I'm still a bit baffled that a 3.5 MB increase on a 700MB live image is considered a complete showstopper. ... Another place to check is the raw filesystem size before adding payload and before compressing. The unused space squashes nicely because it was created as zero on purpose, but still can occupy a significant fraction of a megabyte because each 128KB block is squashed separately. Start with a filesystem that is closer to the size of the total payload. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))
Lennart Poettering (mzerq...@0pointer.de) said: * #851 F18 Feature: procps-ng (next generation procps tools) - https://fedoraproject.org/wiki/Features/procps-ng (sgallagh, 18:11:34) * AGREED: Feature procps-ng is accepted (9 +1) (sgallagh, 18:14:47) Ahem. I think is is a really bad idea. -ng packages point to a huge failure in the handling of the packages in question, and should not be deemed a feature for Linux but a failure of Linux putting FESCo hat on I read this as simply a feature saying we're switching from procps upstream X to procps upstream Y. To be honest, I'm not sure it's even worthy of a Feature. The -ng naming is unfortunate, but so are many other things. In fact, we're shipping a version from this upstream already, just not the new all-distro-patches-merged version. So, it's essentially a no-op. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Guidelines - creating tarball from VCS with script
On 2012-05-14 17:22, Toshio Kuratomi wrote: I personally prefer to have the checkout instructions in comments. The big drawback of that is that if they're just in comments, they're not a prerequisite for creating the shipped tarball, and they will bitrot sooner or later. Using macros in them is one way to avoid some cases of bitrot, but it's plain annoying because they need to be expanded by hand before copy-pasting the commands. Always creating and using an external script to create the tarball doesn't suffer from this problem. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))
On Mon, May 14, 2012 at 10:10 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 14.05.12 14:45, Stephen Gallagher (sgall...@redhat.com) wrote: * #851 F18 Feature: procps-ng (next generation procps tools) - https://fedoraproject.org/wiki/Features/procps-ng (sgallagh, 18:11:34) * AGREED: Feature procps-ng is accepted (9 +1) (sgallagh, 18:14:47) Karel Zak has made clear that he is happy to merge procps into util-linux (Karel is both upstream and downstream for u-l), and has offered to do the work. Yet he told me that he is happy with procps-ng, and the revival was very much needed. Karel? util-linux is the much better place for these utilities, so that common code, the development infrastructure, the build system, the documentation scheme, the release cycle and the maintainership can be shared. Why is the pairing of procps and util-linux any more special than pairing, say, coreutils and bzip2? Common code, development infrastructure, documentation scheme, release cycle and maintainership can always be shared. IMHO common code belongs in a generally useful library for the platform (e.g. glibc, glib2), not in some package-private git repository in each project, where the code slowly rots. And if /proc accesses are that generally useful to be put into a library, that library surely should have a stable API, belong in the procps project, and be used by other projects (including util-linux-ng) as necessary. There's really no point in all the bureaucracy for such a transition if it just replaces one bad situation with another bad situation. If you do a transition then do it right and merge procps into util-linux. What bureaucracy? And if you look closely enough, the transition _has already happened_, there is an actively maintained cross-distribution shared git repo. The old and new situations are not at all same. I'd really like to see FESCO strongly ask the people behind procps-ng to help working in the integration of its tools into util-linux, to make the basic set of tools more nicely integrated rather than continue to grow apart! What does nicely integrated mean, really? The tools have their documented behaviors. Putting them into one git repo won't make them magically more integrated - and it won't even make them magically more maintaned; actually, two separate projects means more proud maintainers, so it is pretty likely to mean more manpower overall. There's really no point in just rubberstamping everything people suggest. FESCO should push people in the right direction, and push them towards collaboration. FESCO, please steer fedora (and Linux) in the right direction here, that's your job! Ignoring the obvious difficulties[1], how can FESCo push upstreams to start or not to start work on a particular project, and how can it do so before the project is done enough to be proposed for integration? We had an unmaintained procps upstream and 50 Fedora-specific patches. Now we have a distribution-common upstream with active development. Seems pretty close to the right direction to me.[2] Mirek [1] Opinions differ on the Right Direction. I wonder how pushing systemd to be less nicely integrated would be received, for example :) Or the eternal non-technical user simplicity vs. syadmin flexibility debate. [2] Even introducing some F17-F18 incompatibilities to be the same across distributions. Great, right? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Guidelines - creating tarball from VCS with script
2012/5/14 Toshio Kuratomi a.bad...@gmail.com: Automating of the package's checksum won't work for many VCS's . git, for instance, does not preserve timestamps. So the tarball created from a git snapshot will have a different checksum for each checkout. While files' modification times in a checkout may be different, archives created with 'git archive' are stable, because git uses the datetime of the commit for each file in the archive. So instead of cloning the repository and creating the archive locally, the preferred method would imho be to use a download link (if present) of the used git hosting service for directly preparing an archive, and to file bugs for the respective hosting service if they do not properly use this git functionality. - Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNS 3 http://www.gns3.net
Other RPM's/spec's are out there for different RPM based distros, of varying quality, most not quite Fedora compatible, These are what I've fiddled with/created and am currently using for FC16/x86_64, http://www.routedlogic.net/files/gns3.spec http://www.routedlogic.net/files/gns3-0.8.2-1.1.src.rpm http://www.routedlogic.net/files/dynamips.spec http://www.routedlogic.net/files/dynamips-0.2.8.RC3-1.fc16.src.rpm -Colin On 14 May 2012 06:34, Ralf Ertzinger fed...@camperquake.de wrote: Hi. On Sun, 13 May 2012 17:08:09 -0300, Adrian Alves wrote Anybody is working on GNS 3 http://www.gns3.net because if not i like to start working on it to build the rpm for it. I think that might run afoul of https://fedoraproject.org/wiki/Packaging:Guidelines#Packages_which_are_not_useful_without_external_bits While GSN3 itself does not require said bits, it's basically just a frontend for programs that do. -- Down that path lies madness. On the other hand, the road to hell is paved with melting snowballs. -- Larry Wall (PERL god) -- 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: Installer unable to detect Geforce GTX 460 v2
Unfortunately, your suggestion is no use because the screen will stay totally black after initialization of the installer. =( On Mon 14 May 2012 04:31:49 AM PDT, Vratislav Podzimek wrote: I believe it should be possible to swith to tty2 (with Ctrl+Alt+F2) and use scp or some other tool to retrieve logs. -- Luya Tshimbalanga Graphic Web Designer E: l...@fedoraproject.org W: http://www.thefinalzone.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installer unable to detect Geforce GTX 460 v2
On Mon, 14 May 2012 14:56:00 -0700 Luya Tshimbalanga l...@fedoraproject.org wrote: Unfortunately, your suggestion is no use because the screen will stay totally black after initialization of the installer. =( If you start the install with sshd as a boot parameter, you'll be able to ssh in to the installation environment and retrieve the logs. Tim signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNS 3 http://www.gns3.net
On 15/05/12 07:21, Colin Stubbs wrote: These are what I've fiddled with/created and am currently using for FC16/x86_64, ... http://www.routedlogic.net/files/dynamips.spec You might want to add the patch for multiple idlepc values. This makes a big difference in practice. As far as Fedora's policy Packages which are not useful without external bits note that there are repositories such as rpmfusion with less strict inclusion criteria. Perhaps your package would be happier there, whilst still making it easy for Fedora users to install GNS3. Note that Cisco is not the world's only networking vendor and some other vendors make their software available as a VM image for evaluation and learning. You might add the ready availability of learning platforms to the Request for Tender the next time you make a major networking purchase. -- Glen Turner www.gdt.id.au/~gdt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNS 3 http://www.gns3.net
On Tue, 15 May 2012 08:25:48 +0930 Glen Turner g...@gdt.id.au wrote: On 15/05/12 07:21, Colin Stubbs wrote: These are what I've fiddled with/created and am currently using for FC16/x86_64, ... http://www.routedlogic.net/files/dynamips.spec You might want to add the patch for multiple idlepc values. This makes a big difference in practice. As far as Fedora's policy Packages which are not useful without external bits note that there are repositories such as rpmfusion with less strict inclusion criteria. Perhaps your package would be happier there, whilst still making it easy for Fedora users to install GNS3. ...snip... Some might say this has already happened: https://bugzilla.redhat.com/show_bug.cgi?id=510464 https://bugzilla.rpmfusion.org/show_bug.cgi?id=718 kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
On Mon, 2012-05-14 at 09:07 -0600, Chris Murphy wrote: TC5 Live Desktop burned to actual media is not EFI bootable on MBP41. The only option for the media is Windows. I'm not sure if this regression occurred in TC4 or TC5. As noted in https://bugzilla.redhat.com/show_bug.cgi?id=810104 , this turns out to be because a stale livecd-tools build was in the 'bleed' repo used for sideloading builds into TC/RC composes, so we built TC4 and TC5 with that old livecd-tools instead of the newest one. This should be resolved for TC6/RC1. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another heads up for F17 upgrades from F16 (via yum)
On Mon, 2012-05-14 at 09:47 -0700, Richard Vickery wrote: Hi Adam, TC4 won't install, and because of this, thinking that it was not supposed to install, I was wondering what one was supposed to do with it. I realise that my thought-process may have been wrong and it should have been installable, Er. Not only 'should have been installable', but in most tests, it is. If you have a problem installing it, please file a bug report with appropriate details. Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]
On Mon, 2012-05-14 at 11:49 -0700, John Reiser wrote: On 05/12/2012 09:51 PM, Matthew Garrett wrote: On Thu, May 10, 2012 at 11:00:48AM -0400, Adam Jackson wrote: So the set of people we'd be inconveniencing is exactly the set of people with no bandwidth and the inability to boot from anything larger than a CD. Not only that - the people who have no bandwidth, the inability to boot from anything larger than a CD and no USB ports that can be bootstrapped from a bootloader sitting on a CD or floppy. USB has been required by Microsoft's logo program since 1999 and was effectively ubiquitous on Pentium 2 before that, so the set of hardware we're ruling out is at least 13 years old and more realistically probably 15. We've already dropped support for x86 hardware that was in production more recently than that. Reality can differ from the press releases. I have two running machines that contradict the conclusions above. Instead of 13 or 15 years, such an effective cutoff would be closer to about 8 years. I consider that to be uncomfortably young to be declared obsolete, especially when the declaration is issued at the end of a release cycle instead of at the beginning. The most important issue in this thread is ability to boot from USB2.0. No, it isn't. mjg59 wrote: the inability to boot from anything larger than a CD and no USB ports that can be bootstrapped from a bootloader sitting on a CD or floppy. So you're talking past each other. You are assuming that direct boot from USB is the minimum. Matthew reckons bootstrapping from a CD or floppy is fine. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Size of official media handouts (was Re: Proposed F18 feature: MiniDebugInfo)
On Mon, 2012-05-14 at 14:50 -0400, Adam Jackson wrote: On Mon, 2012-05-14 at 13:48 -0400, Bill Nottingham wrote: I'm still a bit baffled that a 3.5 MB increase on a 700MB live image is considered a complete showstopper. That's one git package, for example; I would hope that creative dependency trimming can find that space. (Or reorganization of boot images, for example.) There's a modest amount of low-hanging fruit if people really cared about image size. For example, here's a way to shrink the (uncompressed) live filesystem by 30M: https://bugzilla.redhat.com/show_bug.cgi?id=812975#c4 I do find the concern for difficult install scenarios to be noble, but I would tend to class that as a different problem from producing a useful live image that also happens to be installable. But clearly the objection here is about doing more work more than changing the image size. Well, the desktop team has said for a while that the thing they'd really want to add to the desktop image if they had more room is LibreOffice, but that requires substantially more than a few dozen MB. Basically, they consider saving a small amount of room to be more trouble than it's worth in most cases, but saving or creating a large amount of room to be very valuable, as it would allow the re-introduction of an office suite. AIUI, anyway. As it stands, the desktop image is actually usually several MB under 700, but not enough to put LO back in. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installer unable to detect Geforce GTX 460 v2
I added sshd as a boot parameter after highlighting Install/Upgrade Fedora from F17 DVD. There are still a black screen after initialization. I attempt to get ssh information using my laptop and received a denied connection. Did I miss something? On Mon 14 May 2012 03:33:53 PM PDT, Tim Flink wrote: On Mon, 14 May 2012 14:56:00 -0700 Luya Tshimbalangal...@fedoraproject.org wrote: Unfortunately, your suggestion is no use because the screen will stay totally black after initialization of the installer. =( If you start the install with sshd as a boot parameter, you'll be able to ssh in to the installation environment and retrieve the logs. Tim -- Luya Tshimbalanga Graphic Web Designer E: l...@fedoraproject.org W: http://www.thefinalzone.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another heads up for F17 upgrades from F16 (via yum)
Thanks Adam, The *iso may not have burned properly, now that I think of it with the info you have supplied here. I shall attempt it again within the next 24 hours - hopefully. I will let you know. Richard On Mon, May 14, 2012 at 5:14 PM, Adam Williamson awill...@redhat.comwrote: On Mon, 2012-05-14 at 09:47 -0700, Richard Vickery wrote: Hi Adam, TC4 won't install, and because of this, thinking that it was not supposed to install, I was wondering what one was supposed to do with it. I realise that my thought-process may have been wrong and it should have been installable, Er. Not only 'should have been installable', but in most tests, it is. If you have a problem installing it, please file a bug report with appropriate details. Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Component question
I filed a bug recently against remmina (https://bugzilla.redhat.com/show_bug.cgi?id=820815) which on second look would seem to be unrelated to remmina itself, but is rather a more generic issue affecting Gnome. Essentially, some applications that used to start their windows with the appropriate size in F-16 (even proprietary ones like ICAClient), now in F-17 appear to be disregarding the size of the window and opening in almost full screen mode (the window takes the whole workspace, but is not actually maximised). Does anyone know which component is normally responsible for this? The window manager? Some library? TIA, -- Bojan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Guidelines - creating tarball from VCS with script
On 05/14/2012 10:46 PM, Thomas Moschny wrote: 2012/5/14 Toshio Kuratomia.bad...@gmail.com: Automating of the package's checksum won't work for many VCS's . git, for instance, does not preserve timestamps. So the tarball created from a git snapshot will have a different checksum for each checkout. While files' modification times in a checkout may be different, archives created with 'git archive' are stable, because git uses the datetime of the commit for each file in the archive. So instead of cloning the repository and creating the archive locally, the preferred method would imho be to use a download link (if present) of the used git hosting service for directly preparing an archive, and to file bugs for the respective hosting service if they do not properly use this git functionality. - Thomas I don't find the reference right here, but of the top of my head git changes modification times when checking out a branch, but keeps it when checking out a commit. But the real problem is the hosting services, and while we certainly can file bugs on github or gitorious, we also have to live with them. We just had a thread on the github tarballs with the unreasonable names like 1234fcd; no extension... modification time is not the only problem -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Component question
On Tue, 2012-05-15 at 11:15 +1000, Bojan Smojver wrote: I filed a bug recently against remmina (https://bugzilla.redhat.com/show_bug.cgi?id=820815) which on second look would seem to be unrelated to remmina itself, but is rather a more generic issue affecting Gnome. Essentially, some applications that used to start their windows with the appropriate size in F-16 (even proprietary ones like ICAClient), now in F-17 appear to be disregarding the size of the window and opening in almost full screen mode (the window takes the whole workspace, but is not actually maximised). Does anyone know which component is normally responsible for this? The window manager? Some library? Two different problems here. The ICAClient window (although explicitly set by user) is being resized only in mutter, caused by this silly commit: http://git.gnome.org/browse/mutter/commit/?id=f2f500836ef217bfbd7bbf5ad54c9248cbdb7925 Metacity does the right thing and obeys the window size, as set by the application explicitly. -- Bojan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-IO-Socket-SSL] Update to 1.74
commit 600d46f55fc5358e99298491d61284d6b524d4f6
Author: Paul Howarth p...@city-fan.org
Date: Mon May 14 14:10:36 2012 +0100
Update to 1.74
- New upstream release 1.74
- Accept a version of SSLv2/3 as SSLv23, because older documentation could
be interpreted like this
perl-IO-Socket-SSL.spec |7 ++-
sources |2 +-
2 files changed, 7 insertions(+), 2 deletions(-)
---
diff --git a/perl-IO-Socket-SSL.spec b/perl-IO-Socket-SSL.spec
index 696b9ea..944fcee 100644
--- a/perl-IO-Socket-SSL.spec
+++ b/perl-IO-Socket-SSL.spec
@@ -1,5 +1,5 @@
Name: perl-IO-Socket-SSL
-Version: 1.73
+Version: 1.74
Release: 1%{?dist}
Summary: Perl library for transparent SSL
Group: Development/Libraries
@@ -54,6 +54,11 @@ rm -rf %{buildroot}
%{_mandir}/man3/IO::Socket::SSL.3pm*
%changelog
+* Mon May 14 2012 Paul Howarth p...@city-fan.org - 1.74-1
+- Update to 1.74
+ - accept a version of SSLv2/3 as SSLv23, because older documentation could
+be interpreted like this
+
* Fri May 11 2012 Paul Howarth p...@city-fan.org - 1.73-1
- Update to 1.73
- set DEFAULT_CIPHER_LIST to ALL:!LOW instead of HIGH:!LOW
diff --git a/sources b/sources
index 477a06d..4717cd7 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-94d0e640abf765f3268aab34eae79f6a IO-Socket-SSL-1.73.tar.gz
+6a9bc800d136af7709b2fb8dd2e4e8a5 IO-Socket-SSL-1.74.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-IO-Socket-SSL] Created tag perl-IO-Socket-SSL-1.74-1.fc18
The lightweight tag 'perl-IO-Socket-SSL-1.74-1.fc18' was created pointing to: 600d46f... Update to 1.74 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-AnyEvent] Created tag perl-AnyEvent-7.01-1.fc18
The lightweight tag 'perl-AnyEvent-7.01-1.fc18' was created pointing to: c27a78c... Update to 7.01 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
