Re: Self Introduction
Hi, On 04/26/2011 11:47 AM, Martin Cermak wrote: Hi all, I'm a RH QA engineer located in Brno. Nice to meet you. I'm a long time Fedora contributor, and since 2.5 years a software engineer for RH :) I searched the web for some nice command line calendar which could track events and I found pal [1]. It is practical and I'm using it. It is a simple piece of code, included in Debian, but not yet in Fedora. So for me this looks not only like a useful piece of code, but also as a piece of code suitable for my educational purposes ;) I pinged the upstream (Scott Kuhl, Martijn van Oosterhout) and they are both fine with adding pal to Fedora under my maintenance. So I created a review request [2] and now I'm looking for a sponsor. I'm a sponsor and I would be happy to sponsor you. But first I would like to see slightly more of your packaging skills / understanding of the Fedora packaging guidelines (I already took a quick look at your pal package). There are 2 ways to show your package ninja skills, you can create 1 or 2 more packages (which I will then review together with pal), see here for a list of potential candidates: http://fedoraproject.org/wiki/PackageMaintainers/WishList If you would be interested in packaging up a game or 2 let me know and I'll update the Games SIG wishlist page, as I think that needs some love :) Also we can always use some more nice fonts in Fedora, see the fonts wishlist, and also: http://mairin.wordpress.com/category/unpackaged-font-of-the-week/ Or instead of doing some more packages, you could do some unofficial reviews, also described here: http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Suggests/Recommends proposal [Was: Re: PackageKit in Fedora 15 (beta)]
On Tue, Apr 26, 2011 at 8:55 PM, Matej Cepl mc...@redhat.com wrote: Dne 26.4.2011 18:23, Florian Festi napsal(a): I think if anybody can come up with a exact description how they should look like and how they should work and can create some evidence that this is want we need and want implementing them is not the problem[*]. Until now no one has come up with a proposal and enough confidence. Well, I would for starters just take http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps as a basis for the further refinement. == Recommends == This declares a strong, but not absolute, dependency. The Recommends field should list packages that would be found together with this one in all but unusual installations. == Suggests == This is used to declare that one package may be more useful with one or more others. Using this field tells the packaging system and the user that the listed packages are related to this one and can perhaps enhance its usefulness, but that installing this one without them is perfectly reasonable. - As an examples of Recommends I heard crond (or procmail) and /usr/sbin/sendmail ... strictly speaking crond (and procmail) work without sendmail, but almost never seen the former without the latter, and usually if you want that it is some very special case, where administrator knows what he is doing. On the other hand the case in the hand ... gnome-settings-daemon and packagekit (or phonon-gstreamer-backend and its packagekit plugin) would be Suggests — there are many real world scenarios where one could live without PackageKit, but there is no discussion that PK plugin (when it works, that is) could be very useful addition for totem or phonon. As soon as one looks at the details it becomes less obvious what we really want. Even whether the Suggests/Recommends should live in the packages or in comps or else where or both or both or in all three is still under debate. IMHO, Suggests/Recommends should live in the spec file and be maintained by the package maintainers. Do we need reverse relations? Do we really want to have exactly two levels of strength? Do we need conditionals (install an package only if two or more other packages are installed) as we had (have) in comps? Or should be trash the whole concept of comps and comps groups and start all over? When and how should they be evaluated? Do we need to save the users decision not to want the suggested package? What happens if the Suggests changes during an update? We can work on these more elaborate ideas later, but I think that the plain introduction of the Suggests/Recommends as outlined above (roughly, I guess there would be a lot of discussion about that even) would be nice starter for F16 (with a lot of bugs to discuss what level of dependency is required for each particular case). We can deal with the esoteric cases you suggest later. And specifically about comps ... no, I would leave them in cases where they are useful (i.e., roughly anywhere they don't do work of S/R dependencies). They are useful for suggesting grouping of packages and organization of installation models (i.e., definition of what's Desktop, what's KDE, etc.). And even then I don't think there is a need for any rush to replace comps any time soon ... the biggest value of Suggests/Recommends IMHO is the possibility to break unnecessary Requires which make these nonsensical situations (i.e., you need PackageKit in order to have gdm). So I am not too optimistic that we'll have Suggests or Recommends any time soon. As I said above I have been saying this for almost five years already. It took Cato the Elder fifty years, so I think I have still some way to go :) [*] Depending on the exact features implementing still can be tricky and require a lot of work. I doubt that it will be even remotely close to half an hour but nothing that cannot be handled. Of course, I expect that it was half an hour used in a Pickwickian manner. Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel The hard part is to define what the package tools should do in the different cases A depsolver need to work with real requirements, so it need to be defined in what cases that a soft requirement will become a real requirements to do the right thing And 2 kind of soft deps don't make it more simple. There is lot of actions you can do in a yum transaction : install,update,remove,downgrade,obsolete,reinstall and you can mix them in a single transaction so it gets very complex. Another issue is that Suggests/Recommends is a parent - child relations When having a package there supports some kind of plugin infrastructure, you have to add recommends for all plugin packages, so each time a new plugin package is added you have to change and rebuild the main
Self Introduction
Greetings all! My name is Nicholas van Oudtshoorn - long time Fedora user, first time (hopefully!) contributor. One of my jobs (apart from being a church pastor) involves taking care of the IT systems for a local seminary here in Perth, Western Australia. We've been running Fedora on our servers for several years now - basically because it's the distro I find the most intuitive! As part of my duties, I manage the seminary's library software - Koha. Although this runs fine under Fedora, quite a few of it's dependencies are not available in the Fedora repositories. Given the number of libraries using koha (big and small - check out http://wiki.koha-community.org/wiki/Koha_Users_Worldwide ), I suspect that rectifying this could be of some use! To this end, I've started packaging up build requirements. The first package I've made (boy - it's more complex than it seems at first :-) ) is for the Zebra database engine. After that, I'd like to work on the perl packages that are missing. (CPAN is useful - but yum is *so* much easier!) I'd also like to see about updating the yaz package. (yaz is currently available in Fedora - but is quite a few versions behind the upstream) Anywho - just thought I'd introduce myself. I've loved using Fedora over the last years - and am excited about the possibility of giving something back. Nicholas van Oudtshoorn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: AutoQA upgrade path failure makes no sense to me
Here is the update: https://admin.fedoraproject.org/updates/libguestfs-1.6.2-1.fc13.7 Here's the failed test result: http://autoqa.fedoraproject.org/results/87921-autotest/qa03.c.fedoraproject.org/upgradepath/results/output.log This is pretty confusing. Why does it mention other packages != libguestfs? We currently test all pending packages at once. We're working on better presentation of the results. Of course only libguestfs results are relevant to you. It seems to be saying after much head-scratching and decoding that an update to dist-f14 (ie. the original ancient released version without updates) would fail, but how could anyone do that? I'm sorry, this is a bug in AutoQA (depcheck test): https://fedorahosted.org/autoqa/ticket/309 It will be solved in AutoQA 0.4.7, which will be deployed any day now. Thanks, Kamil PS: If you write directly to autoqa-devel list [1] next time, you'll get faster response. [1] https://fedorahosted.org/mailman/listinfo/autoqa-devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F14, can't logout from X environment - Bug 665540
I see something similar on my work machine with ATI (unsure of the actual card specs). I've worked around this by switching to the TTY which I did startx from and sending it a ^C. This has worked for me flawlessly so far. Hi, thank you for your suggestion but in my case, when the problem occours, keyboard and mouse are unresponsive Right. Same here. I should have mentioned that the ^C sent to startx is the logout action here :) . Sorry Ben, now it's clear, thank you :-) and I will do some tests and I'll let you know the result. However i think that by this way you have never correctly closed X environment. Do you suffer any collateral effects ? Marco -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GNOME 3 Fallback Mode
I'm trying to run F15 beta LiveCD in a virtual machine, but I get a complaint that GNOME 3 failed to load and is running in fallback mode. Is there any way to make it work properly when virtualized? Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 Fallback Mode
On Wed, Apr 27, 2011 at 12:31 PM, Andrew Haley a...@redhat.com wrote: I'm trying to run F15 beta LiveCD in a virtual machine, but I get a complaint that GNOME 3 failed to load and is running in fallback mode. Is there any way to make it work properly when virtualized? Not yet ... the VM has to provide proper 3D acceleration for it to work. Ajax has been working on making it run on software rendering, once his work is finished it should be able to run in VMs. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 Fallback Mode
On 04/27/2011 11:35 AM, drago01 wrote: On Wed, Apr 27, 2011 at 12:31 PM, Andrew Haley a...@redhat.com wrote: I'm trying to run F15 beta LiveCD in a virtual machine, but I get a complaint that GNOME 3 failed to load and is running in fallback mode. Is there any way to make it work properly when virtualized? Not yet ... the VM has to provide proper 3D acceleration for it to work. Ajax has been working on making it run on software rendering, once his work is finished it should be able to run in VMs. I see. This is a bit unfortunate from a beta testing point of view: I can't be the only one who tests preview releases in a VM. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 Fallback Mode
On the other hand it will be awesome when it's finished and possibly will remove the need for fallback mode altogether. -Cam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: AutoQA upgrade path failure makes no sense to me
On Wed, Apr 27, 2011 at 04:37:50AM -0400, Kamil Paral wrote: Here is the update: https://admin.fedoraproject.org/updates/libguestfs-1.6.2-1.fc13.7 Here's the failed test result: http://autoqa.fedoraproject.org/results/87921-autotest/qa03.c.fedoraproject.org/upgradepath/results/output.log This is pretty confusing. Why does it mention other packages != libguestfs? We currently test all pending packages at once. We're working on better presentation of the results. Of course only libguestfs results are relevant to you. It seems to be saying after much head-scratching and decoding that an update to dist-f14 (ie. the original ancient released version without updates) would fail, but how could anyone do that? I'm sorry, this is a bug in AutoQA (depcheck test): https://fedorahosted.org/autoqa/ticket/309 It will be solved in AutoQA 0.4.7, which will be deployed any day now. Thanks, Kamil PS: If you write directly to autoqa-devel list [1] next time, you'll get faster response. [1] https://fedorahosted.org/mailman/listinfo/autoqa-devel Thanks for all the answers. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Padre] padre.desktop upload with changes into git instead of sources.
commit 3ea36c7cca089478d7c03535a653f956f94271db Author: Marcela Mašláňová mmasl...@redhat.com Date: Wed Apr 27 13:29:38 2011 +0200 padre.desktop upload with changes into git instead of sources. .gitignore|1 - padre.desktop | 10 ++ sources |1 - 3 files changed, 10 insertions(+), 2 deletions(-) --- diff --git a/.gitignore b/.gitignore index fa89b54..79b5bf3 100644 --- a/.gitignore +++ b/.gitignore @@ -6,4 +6,3 @@ Padre-0.64.tar.gz /Padre-0.80.tar.gz /Padre-0.82.tar.gz /Padre-0.84.tar.gz -/padre.desktop diff --git a/padre.desktop b/padre.desktop new file mode 100644 index 000..8c6e9bb --- /dev/null +++ b/padre.desktop @@ -0,0 +1,10 @@ +[Desktop Entry] +Name=Padre +Comment=Perl Application Development and Refactoring Environment +Comment[cs]=Prostředí pro vývoj a přepis perlových aplikací +GenericName=Perl IDE +Exec=padre +Icon=padre +Terminal=false +Type=Application +Categories=Development;IDE; diff --git a/sources b/sources index 72fc75f..1d8b733 100644 --- a/sources +++ b/sources @@ -1,2 +1 @@ 29c21759803089fa6a9b981ae35ba512 Padre-0.84.tar.gz -60785f75d6c4b556c1293a51d80c465e padre.desktop -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Padre] padre.desktop as file instead of source
commit 206207d3f755951bcac8ae1185038a82ba9f5daa
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Wed Apr 27 14:05:41 2011 +0200
padre.desktop as file instead of source
perl-Padre.spec | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
---
diff --git a/perl-Padre.spec b/perl-Padre.spec
index a51450f..ff54d2c 100644
--- a/perl-Padre.spec
+++ b/perl-Padre.spec
@@ -3,7 +3,7 @@
Name: perl-Padre
Version:0.84
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Perl Application Development and Refactoring Environment
License:GPL+ or Artistic
Group: Development/Libraries
@@ -330,6 +330,12 @@ find
${RPM_BUILD_ROOT}%{perl_vendorlib}/auto/share/dist/Padre/locale/ \
sed 's|^'$RPM_BUILD_ROOT'||
s|\(.*/\)\([^.]*\)\(\.mo\)$|%lang(\2) \1\2\3|' %{name}.lang
+# install logo of Padre into correct paths
+mkdir -p $RPM_BUILD_ROOT/%{_datadir}/icons/hicolor/{64x64,16x16}/apps/
+install -m644 ./share/icons/padre/64x64/logo.png \
+$RPM_BUILD_ROOT/%{_datadir}/icons/hicolor/64x64/apps/padre.png
+install -m644 ./share/icons/padre/16x16/logo.png \
+$RPM_BUILD_ROOT/%{_datadir}/icons/hicolor/16x16/apps/padre.png
# install icon
desktop-file-install --vendor=fedora \
--dir=$RPM_BUILD_ROOT/%{_datadir}/applications %{SOURCE1}
@@ -366,12 +372,17 @@ desktop-file-install --vendor=fedora \
%{perl_vendorlib}/auto/share/dist/Padre/templates
%{perl_vendorlib}/auto/share/dist/Padre/timeline
%{perl_vendorlib}/Padre*
+%{_datadir}/icons/hicolor/64x64/apps/padre.png
+%{_datadir}/icons/hicolor/16x16/apps/padre.png
%{_datadir}/applications/fedora-padre.desktop
%{_mandir}/man3/*
%{_bindir}/padre
%changelog
+* Tue Mar 15 2011 Marcela Mašláňová mmasl...@redhat.com - 0.84-3
+- padre.desktop as file instead of source
+
* Tue Mar 15 2011 Marcela Mašláňová mmasl...@redhat.com - 0.84-2
- 699569 add missing .desktop file
--
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
Avoiding conditioning ignorance towards AutoQA
Hi fellow Fedorans. Recently, AutoQA has been introduced to catch typical problems early in the update process. In general, I appreciate that effort, but currently I find myself in a phase of conditioning ignorance towards AutoQA, essentially because it is drowning me in irrelevant information. The current case why I'm writing is https://admin.fedoraproject.org/updates/lua-wsapi-1.3.4-4.fc15. Here are two ideas to make AutoQA relevant, less time-consuming, and more helpful. In short: good QA is always quiet, only if there is a problem it communicates. - Post only errors It is common, for example, in automated build or continuous integration systems to send out emails only on errors. Similar goes for Unix tools, which tend to be quiet if everything is ok, and only bother you with output if something is not. Therefore, I propose to have AutoQA messages posted only in case that there has been an error. - Accumulate error messages An email is sent for every single comment to Bodhi. In the case of AutoQA, it causes one email per platform. It increases the load of email tremendously to deal with, which in turn makes me ignore it. Therefore, I propose to accumulate messages for all platforms. Combined with the earlier proposal, the states for all platforms should be collected by an intermediate node, and if and only if a test failed on any of the platforms, one message with all status messages is posted to the update. On a related note: it'd be much appreciated if Bodhi would provide an option to get a daily digest with all comments of all the packages I'm involved with. I hope the fine folks of the AutoQA effort take these proposals into account when proceeding in the development of the system and help me to stop ignorance from taking over. Regards, Tim -- Tim Niemueller t...@niemueller.de www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 Fallback Mode
On Wed, Apr 27, 2011 at 12:48 PM, Camilo Mesias cam...@mesias.co.uk wrote: On the other hand it will be awesome when it's finished and possibly will remove the need for fallback mode altogether. Yeah, that and the fix for Intel 945 video used in a lot of netbooks :-) It works great with just the built in screen, but as soon as you attach an external display that has a horizontal resolution 1024 it breaks, so I need fallback right now. It is related to 2048x2048 buffer limits in the hardware for 3D. Quote (http://www.thinkwiki.org/wiki/Xorg_RandR_1.2): Note that the maximum supported size of the virtual desktop for the Intel 945GM series of chipset with 3D acceleration enabled, is 2048x2048. The virtual screen can be larger but DRI will be disabled. (In Fedora 14 this was not so much a problem for use with my external 19 screen as I would just disable the netbook's screen in gnome-display-properties whenever the external screen attaches. That way I was able to enable Compiz as long as both screens were not active at the same time. This does not seem to work in gnome-shell any more unfortunately.) François -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 Fallback Mode
On 4/27/11 6:40 AM, Andrew Haley wrote: On 04/27/2011 11:35 AM, drago01 wrote: On Wed, Apr 27, 2011 at 12:31 PM, Andrew Haleya...@redhat.com wrote: I'm trying to run F15 beta LiveCD in a virtual machine, but I get a complaint that GNOME 3 failed to load and is running in fallback mode. Is there any way to make it work properly when virtualized? Not yet ... the VM has to provide proper 3D acceleration for it to work. Ajax has been working on making it run on software rendering, once his work is finished it should be able to run in VMs. I see. This is a bit unfortunate from a beta testing point of view: I can't be the only one who tests preview releases in a VM. Lots of things are unfortunate. This is software, after all. I regret not working on this earlier, since it would probably have saved the effort invested in fallback mode entirely. But it's a bit late to mope about it. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Avoiding conditioning ignorance towards AutoQA
Hi fellow Fedorans. Recently, AutoQA has been introduced to catch typical problems early in the update process. In general, I appreciate that effort, but currently I find myself in a phase of conditioning ignorance towards AutoQA, essentially because it is drowning me in irrelevant information. The current case why I'm writing is https://admin.fedoraproject.org/updates/lua-wsapi-1.3.4-4.fc15. Here are two ideas to make AutoQA relevant, less time-consuming, and more helpful. In short: good QA is always quiet, only if there is a problem it communicates. - Post only errors It is common, for example, in automated build or continuous integration systems to send out emails only on errors. Similar goes for Unix tools, which tend to be quiet if everything is ok, and only bother you with output if something is not. Therefore, I propose to have AutoQA messages posted only in case that there has been an error. How can you then distinguish an update for which the tests have passed from an update for which the tests haven't yet been executed? Moreover, currently not all updates are tested. Sometimes our tests simply don't work properly. Not just the updates are being tested, the whole AutoQA is being tested (and developed) in this whole effort. - Accumulate error messages An email is sent for every single comment to Bodhi. In the case of AutoQA, it causes one email per platform. It increases the load of email tremendously to deal with, which in turn makes me ignore it. Therefore, I propose to accumulate messages for all platforms. We have that in plan, believe me. Combined with the earlier proposal, the states for all platforms should be collected by an intermediate node, and if and only if a test failed on any of the platforms, one message with all status messages is posted to the update. Sending Bodhi comments is just a quick way how to inform the maintainers. We are working on a results database with API that other Fedora services (Koji, Bodhi) could query and use the results as they seem fit. For most tests I expect it will be similar to what you describe. But that's future. Until that's implemented we can only either send comments to Bodhi or send no comments at all. On a related note: it'd be much appreciated if Bodhi would provide an option to get a daily digest with all comments of all the packages I'm involved with. Great idea, you can ask lmacken about that (or create ticket in its Trac). Or, you can filter your emails and check the relevant folder once a day :) I hope the fine folks of the AutoQA effort take these proposals into account when proceeding in the development of the system and help me to stop ignorance from taking over. It will take some time, but we see the deficiencies, same as you do. We try to improve as fast as possible. Regards, Tim Thanks, Kamil PS: We have a special mailing list for AutoQA: https://fedorahosted.org/mailman/listinfo/autoqa-devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GNOME 3 Fallback Mode
drago01 drago01 at gmail.com writes: On Wed, Apr 27, 2011 at 12:31 PM, Andrew Haley aph at redhat.com wrote: I'm trying to run F15 beta LiveCD in a virtual machine, but I get a complaint that GNOME 3 failed to load and is running in fallback mode. Is there any way to make it work properly when virtualized? Not yet ... the VM has to provide proper 3D acceleration for it to work. Ajax has been working on making it run on software rendering, once his work is finished it should be able to run in VMs. I was under the impression that recent VirtualBox releases do provide the required 3D acceleration pass-through support, but that something on the Fedora side necessary to use it is missing. Is this correct, and how efficient would software rendering be, compared to that? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F15 and Broadcom BCM4313
Hi, I'm testing a netbook using the F15 Beta Live image. That netbook has a Broadcom BCM4313 wifi chipset, of which I can find several problem reports and the same number of answers, with or without success reports. The lspci -v output (I've zeroed the S/N in the output): 02:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g LP-PHY (rev 01) Subsystem: Device 1a3b:2047 Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at fbffc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [58] Vendor Specific Information: Len=78 ? Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [d0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [13c] Virtual Channel Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00 Capabilities: [16c] Power Budgeting ? Two questions: - Can I get this chip working (as a test) using the Live USB-stick, so that I can verify the correct working without actually installing Fedora on the disk? (Wired Ethernet is working to retrieve external stuff when needed.) - Is this chipset expected to start working without any additional tweaks during the F15 life cycle? Thx, -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 and Broadcom BCM4313
On Wed, Apr 27, 2011 at 04:03:16PM +0200, Jos Vos wrote: - Can I get this chip working (as a test) using the Live USB-stick, so that I can verify the correct working without actually installing Fedora on the disk? (Wired Ethernet is working to retrieve external stuff when needed.) No. - Is this chipset expected to start working without any additional tweaks during the F15 life cycle? If support for it appears outside the staging tree. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 Fallback Mode
On 04/27/2011 03:10 PM, Adam Jackson wrote: Lots of things are unfortunate. This is software, after all. I regret not working on this earlier, since it would probably have saved the effort invested in fallback mode entirely. I think the fallback mode is a great idea, not everyone is excited by gnome shell and those people are looking at Xfce. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 and Broadcom BCM4313
On 04/27/2011 02:21 PM, Matthew Garrett wrote: On Wed, Apr 27, 2011 at 04:03:16PM +0200, Jos Vos wrote: - Can I get this chip working (as a test) using the Live USB-stick, so that I can verify the correct working without actually installing Fedora on the disk? (Wired Ethernet is working to retrieve external stuff when needed.) No. I would think you could by creating the live usb with persistant storage and Install the kernel-devel package and akmods-wl from rpmfusion. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 Fallback Mode
On 4/27/11 10:01 AM, Andre Robatino wrote: I was under the impression that recent VirtualBox releases do provide the required 3D acceleration pass-through support, They do, or at east they claim to. but that something on the Fedora side necessary to use it is missing. The virtualbox guest additions are not really packageable, last I checked, because virtualbox upstream doesn't attempt to allow slip between guest additions and hypervisor: if we were to package them, they'd only work with a particular vbox hypervisor version, so installing F15 in a newer-than-F15-contemporary vbox (or F14 in an F15-contemporary vbox, etc) would have broken video drivers. I would love to be wrong about this. how efficient would software rendering be, compared to that? Probably less. Depends entirely on what your host drivers implement, and how well, and on what the guest drivers demand, and how well they're implemented, and so forth. But assuming all is right with the world, host-accelerated 3D would almost assuredly be faster than software guest 3D. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 Fallback Mode
On 04/27/2011 02:10 PM, Adam Jackson wrote: On 4/27/11 6:40 AM, Andrew Haley wrote: On 04/27/2011 11:35 AM, drago01 wrote: On Wed, Apr 27, 2011 at 12:31 PM, Andrew Haleya...@redhat.com wrote: I'm trying to run F15 beta LiveCD in a virtual machine, but I get a complaint that GNOME 3 failed to load and is running in fallback mode. Is there any way to make it work properly when virtualized? Not yet ... the VM has to provide proper 3D acceleration for it to work. Ajax has been working on making it run on software rendering, once his work is finished it should be able to run in VMs. I see. This is a bit unfortunate from a beta testing point of view: I can't be the only one who tests preview releases in a VM. Lots of things are unfortunate. This is software, after all. I regret not working on this earlier, since it would probably have saved the effort invested in fallback mode entirely. I guess so. I had no idea that the Alpha I was testing was not really the GNOME 3 shell, although I had received the warning about fallback mode. So I had no idea what people were complaining about... Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 Fallback Mode
On 04/27/2011 07:34 AM, Adam Jackson wrote: But assuming all is right with the world, host-accelerated 3D would almost assuredly be faster than software guest 3D. Does that include host software 3D with a guest that talks hardware 3D? -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 Fallback Mode
On 4/27/11 10:53 AM, John Reiser wrote: On 04/27/2011 07:34 AM, Adam Jackson wrote: But assuming all is right with the world, host-accelerated 3D would almost assuredly be faster than software guest 3D. Does that include host software 3D with a guest that talks hardware 3D? I have trouble deciphering what you could mean by that. If you mean guest passes through to host, host happens to be running software 3D, that would probably be slower than guest runs software 3D directly. It'd be a tradeoff between which side has a more efficient software implementation, how many CPUs you allocate to the guest, how expensive your hypercalls are, etc. And it's certainly not a scenario I was considering in the scope of all is right with the world. If you mean host sets up device passthrough for a guest, but runs software 3D for itself, that's a thing you could do I guess, but it's not clear why you'd want to, or what you'd be comparing against to determine relative speed. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 and Broadcom BCM4313
On Wed, 2011-04-27 at 15:21 +0100, Matthew Garrett wrote: On Wed, Apr 27, 2011 at 04:03:16PM +0200, Jos Vos wrote: - Can I get this chip working (as a test) using the Live USB-stick, so that I can verify the correct working without actually installing Fedora on the disk? (Wired Ethernet is working to retrieve external stuff when needed.) No. - Is this chipset expected to start working without any additional tweaks during the F15 life cycle? If support for it appears outside the staging tree. In addition to what Matt says, probably the best way to get it working in F15 for now (pragmatically speaking) is to install the proprietary 'wl' driver from a third party repository (the standard one has it packaged as kmod-wl / akmod-wl). That driver supports the chip in question and works, per multiple reports. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Retiring perl-Text-Aspell
I would like to invoke the EOL process for perl-Text-Aspell in Rawhide. I will continue to maintain it in Fedora through the F-15 lifecycle, and in EPEL through the EPEL 6 lifecycle. The package is already semi-crippled in EPEL 6, since only the aspell-en and aspell-sk dictionaries are available in RHEL 6. The packages that depend on perl-Text-Aspell in Rawhide are: acheck moodle xinha The packages that depend on perl-Text-Aspell in EPEL 6 are: moodle These packages should be migrated to perl-Text-Hunspell. I will wait 1 week before retiring perl-Text-Aspell in Rawhide to give the maintainers of these packages a chance to decide what to do. If one of you would like to take over maintenance, I will orphan the package instead of retiring it. Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
tomboy orphaned
Hey guys, A long, long time ago (before the extras/core merge in fact i think) i was given tomboy to help spread the influx of mono packages across desktop team. IIt's a neat program, but I don't really use it. I'm more of a send-myself-email/scribble-on-whiteboard kind of guy. I'm also not very good about maintaining it. I've orphaned it now. If anyone is interested in it, feel free to take it. --Ray -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 Fallback Mode
On Wed, Apr 27, 2011 at 16:27:13 +0200, Martin Stransky stran...@redhat.com wrote: On 04/27/2011 03:10 PM, Adam Jackson wrote: Lots of things are unfortunate. This is software, after all. I regret not working on this earlier, since it would probably have saved the effort invested in fallback mode entirely. I think the fallback mode is a great idea, not everyone is excited by gnome shell and those people are looking at Xfce. I also am using fallback mode in order to keep using work spaces in the manner in which I am used to. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] The Cloud Test Day is Tomorrow
The Cloud SIG test day for Fedora 15 is will be this Thursday [1]. The focus will be on using BoxGrinder [2] and Amazon Elastic Compute Cloud (EC2) [3] with Fedora 15. BoxGrinder is a set of projects that help you grind out appliances for multiple virtualization and Cloud providers. Another way to put it is that BoxGrinder makes it easy to create and deploy custom installations of Fedora, Red Hat Enterprise Linux or CentOS to your favorite KVM, Xen or VMWare based clouds. This includes private clouds and EC2. Live images, prebuilt EC2 amis and meta-appliances [4] will be available on the test day if you don't already have Fedora 15 installed. Detailed instructions for how to test are available on the wiki [1]. There are test cases for BoxGrinder that can be run without an AWS account for EC2 but testing on Amazon's infrastructure and other cloud providers (BoxGrinder also supports ElaticHosts, SKALI Cloud, Open Hosting and Serverlove) would be very much appreciated. Get ready for some cloudy good-ness and please help test if you have the time! Tim [1] http://fedoraproject.org/wiki/Test_Day:2011-04-28_Cloud_SIG [2] http://boxgrinder.org/ [3] http://aws.amazon.com/ec2/ [4] http://boxgrinder.org/tutorials/boxgrinder-build-meta-appliance/ signature.asc Description: OpenPGP digital signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retiring perl-Text-Aspell
Jerry James wrote: I would like to invoke the EOL process for perl-Text-Aspell in Rawhide. I will continue to maintain it in Fedora through the F-15 lifecycle, and in EPEL through the EPEL 6 lifecycle. The package is already semi-crippled in EPEL 6, since only the aspell-en and aspell-sk dictionaries are available in RHEL 6. The packages that depend on perl-Text-Aspell in Rawhide are: acheck moodle xinha The packages that depend on perl-Text-Aspell in EPEL 6 are: moodle These packages should be migrated to perl-Text-Hunspell. I will wait 1 week before retiring perl-Text-Aspell in Rawhide to give the maintainers of these packages a chance to decide what to do. If one of you would like to take over maintenance, I will orphan the package instead of retiring it. Regards, Hi, moodle maintainer. I just took a quick look through 2.0.2, and I don't see where the limited Perl present uses perl-text-aspell, so it may just be a hard-coded Requires that I can drop. Can someone with stronger Perl-Fu take a gander and confirm this for me, please? -J -- 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: Retiring perl-Text-Aspell
On Wed, Apr 27, 2011 at 10:00 AM, Jon Ciesla l...@jcomserv.net wrote: Hi, moodle maintainer. I just took a quick look through 2.0.2, and I don't see where the limited Perl present uses perl-text-aspell, so it may just be a hard-coded Requires that I can drop. Can someone with stronger Perl-Fu take a gander and confirm this for me, please? -J -- in your fear, seek only peace in your fear, seek only love -d. bowie Agreed. It looks like moodle is invoking aspell directly, rather than via perl-Text-Aspell. Somewhat ironically, I created the perl-Text-Aspell package in the first place because it was embedded in the moodle sources, and I was the moodle maintainer at the time (some 4 years ago). You may want to look at changing moodle to use hunspell anyway, due to the limited number of aspell dictionaries available in RHEL 6. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 and Broadcom BCM4313
On Wed, Apr 27, 2011 at 10:16 AM, Adam Williamson awill...@redhat.com wrote: In addition to what Matt says, probably the best way to get it working in F15 for now (pragmatically speaking) is to install the proprietary 'wl' driver from a third party repository (the standard one has it packaged as kmod-wl / akmod-wl). That driver supports the chip in question and works, per multiple reports. Yep, I have a HP Mini 5103 with the BCM 4313 chipset and wireless works just fine once I installed akmod-wl from rpmfusion. -- Jeff Ollie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2011-04-27)
=== #fedora-meeting: FESCO (2011-04-27) === Meeting started by nirik at 17:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-04-27/fesco.2011-04-27-17.30.log.html Meeting summary --- * init process (nirik, 17:30:01) * #585 Plan date for dist-git branch renames (nirik, 17:33:15) * ACTION: 2011-05-10 scheduled for the change. (nirik, 17:42:03) * #515 Investigate a features repo for stable releases (nirik, 17:44:43) * #563 suggested policy: all daemons must set RELRO and PIE flags (nirik, 17:48:25) * Open Floor (nirik, 17:49:48) Meeting ended at 18:26:42 UTC. Action Items * 2011-05-10 scheduled for the change. Action Items, by person --- * **UNASSIGNED** * 2011-05-10 scheduled for the change. People Present (lines said) --- * cwickert (71) * nirik (65) * mjg59 (49) * gholms (22) * Oxf13 (19) * mclasen (18) * notting (16) * ajax (8) * zodbot (7) * mmaslano (2) * rsc (2) * rwmjones (1) * SMParrish (0) * kylem (0) -- 17:30:01 nirik #startmeeting FESCO (2011-04-27) 17:30:01 zodbot Meeting started Wed Apr 27 17:30:01 2011 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:30:01 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:30:01 nirik #meetingname fesco 17:30:01 zodbot The meeting name has been set to 'fesco' 17:30:01 nirik #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano 17:30:01 nirik #topic init process 17:30:01 zodbot Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting 17:30:39 mjg59 Afternoon 17:30:48 * notting is here 17:31:34 * mmaslano here 17:31:38 ajax come on party people, throw your hands in the air 17:31:54 gholms Going to go for the third 20m meeting in a row? 17:32:01 ajax yesplz 17:32:06 nirik I think they are nice, yes. ;) 17:32:13 mjg59 As long as nobody brings up systemd 17:32:13 * mclasen is here 17:32:21 gholms mjg59: Shh! :P 17:32:21 mjg59 (Oh no!) 17:32:47 nirik cwickert said he would be a bit late... 17:33:11 nirik lets start with an easy one: 17:33:15 nirik #topic #585 Plan date for dist-git branch renames 17:33:15 nirik .fesco 585 17:33:17 zodbot nirik: #585 (Plan date for dist-git branch renames) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/585 17:33:59 mjg59 Oxf13: You around? 17:34:03 nirik this looks like a short outage. I'm happy to have it done whenever. 17:34:08 nirik sooner better than later I guess. 17:34:17 Oxf13 that I am 17:34:40 Oxf13 the outage is short, what I'm looking for is guidance and thought on how long we should wait for the proper fedpkg packages to soak in stable 17:34:48 Oxf13 for a reasonable amount of people to have them installed 17:34:57 mjg59 Oxf13: Are they in every relevant release now? 17:35:05 ajax f15 final change deadline is May 9 17:35:11 Oxf13 I do also need to create or have help creating a wiki landing page that we can direct people to to help them through the transition. 17:35:24 Oxf13 mjg59: I believe they're still in testing for el5/6 17:35:32 ajax so, presumably, that would be a point after which nobody needs to use git to fix things for f15 17:35:36 Oxf13 but went stable elsewhere lastweek/this week 17:35:55 mjg59 Oxf13: tbh, I don't think there's any real soak test required if the code is already available to people 17:36:03 mjg59 They're not going to be pushing to git unless they have network access... 17:36:06 Oxf13 unfortunately I'm buried this week trying to finish a presentation for a conference. 17:36:17 Oxf13 mjg59: that is true. 17:36:27 mjg59 So I'm happy with it once they're stable everywhere 17:36:33 Oxf13 and push attempts to the old path will be stopped by the ACL system, pointing them to a wiki page 17:36:35 * notting would prefer after f15 is frozen 17:36:40 Oxf13 said wiki page would say Download the update, run the fixbranches 17:36:55 mjg59 If there's any other infrastructure outages in the near future then doing it alongside one of them would be nice 17:36:55 mclasen we just want to avoid changing branch names before the fixed fedpkg is available via yum update on all releases, I guess 17:37:28 nirik well, I am hoping to have an outage next week on db01 to upgrade/move to new hardware. 17:37:50 ajax notting: may 10 then? 17:38:00 nirik that would affect wiki/smolt/wordpress/zarafa... so not really related to this. ;) 17:38:29 Oxf13 heh 17:38:29 notting ajax: something like that, yes. 17:38:39 Oxf13 the mid-may timeline is fine by me. 17:38:56 Oxf13 gives me time to create/polish the wiki page and the patch to the ACL system. 17:39:17 nirik note that that is in infrastructures change freeze, but we can get an exception for it. ;) 17:39:27 Oxf13 nod 17:39:34 * cwickert is here 17:39:53 nirik so, shall we tenatively say 10th? or thats summit, and go later in that
Re: wireless-tools/net-tools are DEPRECATED
On Tue, 2011-04-26 at 09:46 -0700, Adam Williamson wrote: On Sun, 2011-04-24 at 16:35 +, Ben Boeckel wrote: deal with in these cases) than some packets were lost. An option to persist connections despite something probably not actually existing would be nice for situations like this. Or, more simply, just a short time-out on cable disconnect (say 10 seconds) before treating the connection as down? NM has had one for a while: 4 seconds. THe problem with longer is that then any time you do disconnect the cable or undock your laptop, NM would think that you were still connected for 10 seconds (or more) until if flipped over to wifi. So there's a conflict here between people that occasionally pull out the network cable to do stuff, and between people that dock/undock and move from wired to wifi. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Suggests/Recommends proposal [Was: Re: PackageKit in Fedora 15 (beta)]
tim.laurid...@gmail.com wrote: The hard part is to define what the package tools should do in the different cases A depsolver need to work with real requirements, so it need to be defined in what cases that a soft requirement will become a real requirements to do the right thing See my proposal. And 2 kind of soft deps don't make it more simple. See my reply to James Antill for why 2. Another issue is that Suggests/Recommends is a parent - child relations When having a package there supports some kind of plugin infrastructure, you have to add recommends for all plugin packages, so each time a new plugin package is added you have to change and rebuild the main package to have a relationship, In that case it would be smarter to have a child - parent relationship, That can be discussed as a separate proposal later. Having reverse dependencies is not a requirement for having regular soft dependencies. but that would be very hard to work with if stored in the child spec only, you need some kind of central metadata to handle that. We already have such metadata: the repodata! Createrepo can extract that information from the child RPM and index it by the parent RPM name. But again, we should get forward soft dependencies working first before we even start discussing reverse ones. It is obvious that the reverse case is more complicated, and there is no practical need for blocking the forward case on it. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
FC 14 yum update problems
All, Not sure if this is the correct list to bring this up but here goes. This morning after booting my system I completed a yum update. After the update I was not able to use vlc or okular. I also was receiving an error when using konqueror. I have included the error for konqueror, and clip of /var/log/messages file plus the tail end of dmesg for information about vlc error. All working until this mornings update. The konqueror error was: There was an error loading the module KHTML. The diagnostics is: The plugin 'libkhtmlpart' uses an incompatible KDE library (4.6.2 (4.6.2)). The vlc error: [plynn55@plynn55 ~]$ sudo tail -f /var/log/messages Apr 27 10:42:19 plynn55 abrtd: Package 'vlc-core' isn't signed with proper key Apr 27 10:42:19 plynn55 abrtd: Corrupted or bad crash /var/spool/abrt/ccpp-1303915339-3383 (res:5), deleting Apr 27 10:52:19 plynn55 gnome-keyring-daemon[2527]: couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files Apr 27 12:56:24 plynn55 yum[6007]: Installed: adobe-release-1.0-0.noarch Apr 27 13:36:48 plynn55 kernel: [12251.314336] CE: hpet increased min_delta_ns to 16875 nsec Apr 27 14:26:19 plynn55 kernel: [15221.802290] vlc[7707]: segfault at 0 ip 7f7e115106d3 sp 7f7e14fb7bc0 error 4 in libkio.so.5.6.0[7f7e11338000+296000] Apr 27 14:26:19 plynn55 abrt[7708]: saved core dump of pid 7701 (/usr/bin/vlc) to /var/spool/abrt/ccpp-1303928779-7701.new/coredump (11309056 bytes) Apr 27 14:26:19 plynn55 abrtd: Directory 'ccpp-1303928779-7701' creation detected Apr 27 14:26:19 plynn55 abrtd: Package 'vlc-core' isn't signed with proper key Apr 27 14:26:19 plynn55 abrtd: Corrupted or bad crash /var/spool/abrt/ccpp-1303928779-7701 (res:5), deleting The Okular error: Pop up screen... Unable to find the Okular component. KDE crash handler: When the crash handler pops up it is requesting to install the debug symbols which will take up 3.1 GB. My laptop has available 6GB. This to me is a very large amount of hard drive space. Install 42 Package(s) Total download size: 628 M Installed size: 3.1 G Backtrace for okular Application: Okular (okular), signal: Segmentation fault [KCrash Handler] #6 0x7f10c5b506eb in QAction::setChecked(bool) () from /usr/lib64/libQtGui.so.4 #7 0x00408b13 in _start () Below is the end of dmesg, you will see a couple of vlc errors: [ 22.750573] alloc kstat_irqs on node -1 [ 22.750611] atl1c :07:00.0: irq 49 for MSI/MSI-X [ 22.750806] atl1c :07:00.0: atl1c: eth0 NIC Link is Up100 Mbps Full Duplex [ 24.256506] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 30.329911] RPC: Registered udp transport module. [ 30.330312] RPC: Registered tcp transport module. [ 30.330692] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 31.955401] vboxdrv: Found 2 processor cores. [ 31.955484] VBoxDrv: dbg - g_abExecMemory=a0db1240 [ 31.955504] vboxdrv: fAsync=0 offMin=0x201 offMax=0xee2 [ 31.956340] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'. [ 31.957022] vboxdrv: Successfully loaded version 4.0.2 (interface 0x0016). [ 33.602156] eth0: no IPv6 routers present [ 76.893701] hda-intel: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj. [ 92.237971] fuse init (API version 7.14) [ 1310.849180] CE: hpet increased min_delta_ns to 7500 nsec [ 1310.849297] CE: hpet increased min_delta_ns to 11250 nsec [ 1781.637160] vlc[3389]: segfault at 0 ip 7f840368f6d3 sp 7f840b330bc0 error 4 in libkio.so.5.6.0[7f84034b7000+296000] [12251.314336] CE: hpet increased min_delta_ns to 16875 nsec [15221.802290] vlc[7707]: segfault at 0 ip 7f7e115106d3 sp 7f7e14fb7bc0 error 4 in libkio.so.5.6.0[7f7e11338000+296000] I am currently wondering what other issues I am going to run into. If this is not the correct list to bring up these issues please let me know. Thank You Phillip Lynn plyn...@verizon.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wireless-tools/net-tools are DEPRECATED
On Sun, 2011-04-24 at 23:06 +0200, Tomasz Torcz wrote: On Sun, Apr 24, 2011 at 07:10:48PM +0200, Kevin Kofler wrote: Ben Boeckel wrote: One thing I liked a lot with my ifconfig scripts/wpa_supplicant pairing is that when wireless is spotty, the network doesn't keep going up and down. Instead, applications see lots of dropped packets. When reauthentication can take 5 to 10s (or more), assuming that the connection is steady when its just spotty can result in better behavior. Also nice when quickly swapping ethernet cables. A network is gone event gets different reactions from applications (particularly those that are NM-aware which makes those applications MUCH more annoying to deal with in these cases) than some packets were lost. An option to persist connections despite something probably not actually existing would be nice for situations like this. I've found NM to actually be quite tolerant of spotty wireless connections. In fact, usually, it's me who triggers a reconnect (or if possible, a connect to a different access point, e.g. when I'm at the university in a shared building with the business university (WU), I try switching from eduroam to eduroam-wu when reception of my university's eduroam is poor), NM just happily stays connected even with 100% packet loss. Well, I have opposite experience with my wired connection. It takes only about 5 flip-flop (carrier on/carrier off) in 10 seconds for NM to consider connection down. When carrier state changes happen, NM sets the carrier state internally, but won't do anything about it for 4 seconds. If you get another carrier change within that 4 seconds, NM pushes the action off for another 4 seconds. If you get another, then it pushes it off for another 4 seconds. So basically, whenever the device settles down and stops spamming carrier changes, NM won't do anything for 4 seconds. The next question, what's causing your carrier to flip-flop int he first place? Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wireless-tools/net-tools are DEPRECATED
On Sun, 2011-04-24 at 19:10 +0200, Kevin Kofler wrote: Ben Boeckel wrote: One thing I liked a lot with my ifconfig scripts/wpa_supplicant pairing is that when wireless is spotty, the network doesn't keep going up and down. Instead, applications see lots of dropped packets. When reauthentication can take 5 to 10s (or more), assuming that the connection is steady when its just spotty can result in better behavior. Also nice when quickly swapping ethernet cables. A network is gone event gets different reactions from applications (particularly those that are NM-aware which makes those applications MUCH more annoying to deal with in these cases) than some packets were lost. An option to persist connections despite something probably not actually existing would be nice for situations like this. I've found NM to actually be quite tolerant of spotty wireless connections. In fact, usually, it's me who triggers a reconnect (or if possible, a connect to a different access point, e.g. when I'm at the university in a shared building with the business university (WU), I try switching from eduroam to eduroam-wu when reception of my university's eduroam is poor), NM just happily stays connected even with 100% packet loss. If the driver/supplicant report that they are still connected, then NM says you're still connected; we'd need wpa_supplicant debug logs to figure out what's going on here. When this happens, if you do 'iwconfig wlan0' does it show a valid BSSID? If so, then the driver has a problem because it says it's still connected, but cannot pass traffic to/from the AP. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Avoiding conditioning ignorance towards AutoQA
On 27.04.2011 15:38, Kamil Paral wrote: - Post only errors It is common, for example, in automated build or continuous integration systems to send out emails only on errors. Similar goes for Unix tools, which tend to be quiet if everything is ok, and only bother you with output if something is not. Therefore, I propose to have AutoQA messages posted only in case that there has been an error. How can you then distinguish an update for which the tests have passed from an update for which the tests haven't yet been executed? Moreover, currently not all updates are tested. Sometimes our tests simply don't work properly. Not just the updates are being tested, the whole AutoQA is being tested (and developed) in this whole effort. Please don't force testing, fixing, and maintaining AutoQA on the rest of us. Integrate it such that stuff is pushed to testing only after AutoQA has been run, or have a flag display tests ran. Or post the PASSED messages, but make Bodhi not sent messages in the case the tests passed. Keeping the current way will just make me (and possibly others) add filters to throw away messages from AutoQA. Please be aware of how much contributor time you waste by making them hope through useless (because the tests have passed and no information is gained) mails. I realize you want to improve things, but at the current stage its consuming the most valuable resource we have, packager/developer time. - Accumulate error messages An email is sent for every single We have that in plan, believe me. Combined with the earlier proposal, the states for all platforms should be collected by an intermediate node, and if and only if a test failed on any of the platforms, one message with all status messages is posted to the update. Sending Bodhi comments is just a quick way how to inform the maintainers. We are working on a results database with API that other Fedora services (Koji, Bodhi) could query and use the results as they seem fit. For most tests I expect it will be similar to what you describe. But that's future. Until that's implemented we can only either send comments to Bodhi or send no comments at all. I understand you like to have a quick and working solution for now, and that great stuff is coming. But you cost a lot of time right now. Please reconsider to make your development and testing time less intrusive for others. On a related note: it'd be much appreciated if Bodhi would provide an option to get a daily digest with all comments of all the packages I'm involved with. Great idea, you can ask lmacken about that (or create ticket in its Trac). Or, you can filter your emails and check the relevant folder once a day :) That still means striving through many messages with lots of non-info text. One concise email would make things much better. I hope the fine folks of the AutoQA effort take these proposals into account when proceeding in the development of the system and help me to stop ignorance from taking over. It will take some time, but we see the deficiencies, same as you do. We try to improve as fast as possible. Please try to find a way to do this without costing as much time as atm. There must be ways, for example have a list of packages to use it for that packagers can opt-in and make AutoQA developers the first to use it. PS: We have a special mailing list for AutoQA: https://fedorahosted.org/mailman/listinfo/autoqa-devel Sorry, to keep me involved in Fedora I have to make it a reasonable effort, joining yet another project is out of my possibilities atm. Tim -- Tim Niemueller t...@niemueller.de www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 and Broadcom BCM4313
Adam Williamson wrote: In addition to what Matt says, probably the best way to get it working in F15 for now (pragmatically speaking) is to install the proprietary 'wl' driver from a third party repository (the standard one has it packaged as kmod-wl / akmod-wl). That driver supports the chip in question and works, per multiple reports. RPM Fusion should really be updating its kmod-staging. The package in RPM Fusion for F15 is ancient and won't even install. A current kmod-staging would bring Free support for this chipset instead of the proprietary one. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retiring perl-Text-Aspell
Jerry James wrote: You may want to look at changing moodle to use hunspell anyway, due to the limited number of aspell dictionaries available in RHEL 6. Yeah, aspell needs to die, everything in Fedora has been supposed to use Hunspell since Fedora 9: https://fedoraproject.org/wiki/Releases/FeatureDictionary Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC 14 yum update problems
Phillip Lynn wrote: This morning after booting my system I completed a yum update. After the update I was not able to use vlc or okular. I also was receiving an error when using konqueror. I have included the error for konqueror, and clip of /var/log/messages file plus the tail end of dmesg for information about vlc error. All working until this mornings update. The konqueror error was: There was an error loading the module KHTML. The diagnostics is: The plugin 'libkhtmlpart' uses an incompatible KDE library (4.6.2 (4.6.2)). You need to restart your session after upgrading KDE. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC 14 yum update problems
Sorry, I forgot to say that was after the yum update and a reboot. Thanks, Phillip Lynn On Wed, 2011-04-27 at 21:38 +0200, Kevin Kofler wrote: Phillip Lynn wrote: This morning after booting my system I completed a yum update. After the update I was not able to use vlc or okular. I also was receiving an error when using konqueror. I have included the error for konqueror, and clip of /var/log/messages file plus the tail end of dmesg for information about vlc error. All working until this mornings update. The konqueror error was: There was an error loading the module KHTML. The diagnostics is: The plugin 'libkhtmlpart' uses an incompatible KDE library (4.6.2 (4.6.2)). You need to restart your session after upgrading KDE. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Suggests/Recommends proposal [Was: Re: PackageKit in Fedora 15 (beta)]
On Wed, Apr 27, 2011 at 12:47, Kevin Kofler kevin.kof...@chello.at wrote: tim.laurid...@gmail.com wrote: The hard part is to define what the package tools should do in the different cases A depsolver need to work with real requirements, so it need to be defined in what cases that a soft requirement will become a real requirements to do the right thing See my proposal. My problem with your proposal is that it is not crazy enough. It is a lot of work for marginal gain and doesn't really bet the farm enough. I would prefer a proposal that Fedora 17 will be based off of Conary or .debs as it is crazy enough to work. -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Let us be kind, one to another, for most of us are fighting a hard battle. -- Ian MacLaren -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Avoiding conditioning ignorance towards AutoQA
On Wed, 2011-04-27 at 21:03 +0200, Tim Niemueller wrote: On 27.04.2011 15:38, Kamil Paral wrote: - Post only errors It is common, for example, in automated build or continuous integration systems to send out emails only on errors. Similar goes for Unix tools, which tend to be quiet if everything is ok, and only bother you with output if something is not. Therefore, I propose to have AutoQA messages posted only in case that there has been an error. How can you then distinguish an update for which the tests have passed from an update for which the tests haven't yet been executed? Moreover, currently not all updates are tested. Sometimes our tests simply don't work properly. Not just the updates are being tested, the whole AutoQA is being tested (and developed) in this whole effort. Please don't force testing, fixing, and maintaining AutoQA on the rest of us. Well, we don't force it, but like bodhi, koji and most other key infrastructure tools, it is software ... and software unfortunately has bugs. We do our best to minimize those bugs, but we've found it very difficult to emulate a real-world bodhi+koji setup (with interesting data) in our test instance. Integrate it such that stuff is pushed to testing only after AutoQA has been run, or have a flag display tests ran. Or post the PASSED messages, but make Bodhi not sent messages in the case the tests passed. Re: integration and only allowing updates to proceed to 'updates-testing' ... that's the goal. Unfortunately, as with many things, arriving at a destination involves a journey. We can't simply turn this feature on until we have confidence that the tests are correctly enforcing the package update policy [1]. Therefore, we are operating in a permissive mode at this time. With regards to having a flag or having bodhi not send messages in certain scenarios. Those are definitely options. We'll need to raise those ideas the bodhi folks [2] for review, since AutoQA and bodhi are separate projects. But your concerns are definitely worth following up on. [1] https://fedoraproject.org/wiki/Updates_Policy [2] https://fedorahosted.org/mailman/listinfo/bodhi Keeping the current way will just make me (and possibly others) add filters to throw away messages from AutoQA. Please be aware of how much contributor time you waste by making them hope through useless (because the tests have passed and no information is gained) mails. I realize you want to improve things, but at the current stage its consuming the most valuable resource we have, packager/developer time. - Accumulate error messages An email is sent for every single We have that in plan, believe me. Combined with the earlier proposal, the states for all platforms should be collected by an intermediate node, and if and only if a test failed on any of the platforms, one message with all status messages is posted to the update. Sending Bodhi comments is just a quick way how to inform the maintainers. We are working on a results database with API that other Fedora services (Koji, Bodhi) could query and use the results as they seem fit. For most tests I expect it will be similar to what you describe. But that's future. Until that's implemented we can only either send comments to Bodhi or send no comments at all. I understand you like to have a quick and working solution for now, and that great stuff is coming. But you cost a lot of time right now. Please reconsider to make your development and testing time less intrusive for others. Thanks for your feedback. We're actively working on ways to reduce the unnecessary emails generated by bodhi when posting feedback. Obviously, the goal is to work *for* maintainers, not against them. On a related note: it'd be much appreciated if Bodhi would provide an option to get a daily digest with all comments of all the packages I'm involved with. Great idea, you can ask lmacken about that (or create ticket in its Trac). Or, you can filter your emails and check the relevant folder once a day :) That still means striving through many messages with lots of non-info text. One concise email would make things much better. The point Kamil was making is that bodhi and AutoQA are different tools. If you have a good idea for bodhi, please raise that on https://fedorahosted.org/mailman/listinfo/bodhi. I hope the fine folks of the AutoQA effort take these proposals into account when proceeding in the development of the system and help me to stop ignorance from taking over. It will take some time, but we see the deficiencies, same as you do. We try to improve as fast as possible. Please try to find a way to do this without costing as much time as atm. There must be ways, for example have a list of packages to use it for that packagers can opt-in and make AutoQA developers the first to use it. Opt-in support has been available for some time now.
Re: wireless-tools/net-tools are DEPRECATED
On Wed, Apr 27, 2011 at 01:58:57PM -0500, Dan Williams wrote: On Sun, 2011-04-24 at 23:06 +0200, Tomasz Torcz wrote: On Sun, Apr 24, 2011 at 07:10:48PM +0200, Kevin Kofler wrote: Ben Boeckel wrote: One thing I liked a lot with my ifconfig scripts/wpa_supplicant pairing is that when wireless is spotty, the network doesn't keep going up and down. Instead, applications see lots of dropped packets. When reauthentication can take 5 to 10s (or more), assuming that the connection is steady when its just spotty can result in better behavior. Also nice when quickly swapping ethernet cables. A network is gone event gets different reactions from applications (particularly those that are NM-aware which makes those applications MUCH more annoying to deal with in these cases) than some packets were lost. An option to persist connections despite something probably not actually existing would be nice for situations like this. I've found NM to actually be quite tolerant of spotty wireless connections. In fact, usually, it's me who triggers a reconnect (or if possible, a connect to a different access point, e.g. when I'm at the university in a shared building with the business university (WU), I try switching from eduroam to eduroam-wu when reception of my university's eduroam is poor), NM just happily stays connected even with 100% packet loss. Well, I have opposite experience with my wired connection. It takes only about 5 flip-flop (carrier on/carrier off) in 10 seconds for NM to consider connection down. When carrier state changes happen, NM sets the carrier state internally, but won't do anything about it for 4 seconds. If you get another carrier change within that 4 seconds, NM pushes the action off for another 4 seconds. If you get another, then it pushes it off for another 4 seconds. So basically, whenever the device settles down and stops spamming carrier changes, NM won't do anything for 4 seconds. That's not what I'm seeing: messages-20110403:Mar 29 13:08:11 mother NetworkManager[1285]: info (nf): carrier now OFF (device state 3) messages-20110403:Mar 29 13:08:11 mother NetworkManager[1285]: info (nf): device state change: 3 - 2 (reason 40) messages-20110403:Mar 29 13:08:11 mother NetworkManager[1285]: info (nf): deactivating device (reason: 40). messages-20110403:Mar 29 13:08:21 mother NetworkManager[1285]: info (nf): carrier now ON (device state 2) messages-20110403:Mar 29 13:08:21 mother NetworkManager[1285]: info (nf): device state change: 2 - 3 (reason 40) messages-20110403:Mar 29 13:09:06 mother NetworkManager[1285]: info (nf): carrier now OFF (device state 3) messages-20110403:Mar 29 13:09:06 mother NetworkManager[1285]: info (nf): device state change: 3 - 2 (reason 40) messages-20110403:Mar 29 13:09:06 mother NetworkManager[1285]: info (nf): deactivating device (reason: 40). messages-20110403:Mar 29 13:09:07 mother NetworkManager[1285]: info (nf): carrier now ON (device state 2) messages-20110403:Mar 29 13:09:07 mother NetworkManager[1285]: info (nf): device state change: 2 - 3 (reason 40) messages-20110403:Mar 29 13:09:09 mother NetworkManager[1285]: info (nf): carrier now OFF (device state 3) messages-20110403:Mar 29 13:09:09 mother NetworkManager[1285]: info (nf): device state change: 3 - 2 (reason 40) messages-20110403:Mar 29 13:09:09 mother NetworkManager[1285]: info (nf): deactivating device (reason: 40). messages-20110403:Mar 29 13:09:11 mother NetworkManager[1285]: info (nf): carrier now ON (device state 2) messages-20110403:Mar 29 13:09:11 mother NetworkManager[1285]: info (nf): device state change: 2 - 3 (reason 40) messages-20110403:Mar 29 13:09:17 mother NetworkManager[1285]: info (nf): carrier now OFF (device state 3) messages-20110403:Mar 29 13:09:17 mother NetworkManager[1285]: info (nf): device state change: 3 - 2 (reason 40) messages-20110403:Mar 29 13:09:17 mother NetworkManager[1285]: info (nf): deactivating device (reason: 40). messages-20110403:Mar 29 13:09:17 mother NetworkManager[1285]: info (nf): canceled DHCP transaction, DHCP client pid 7250 At this point I need to manually do nmcli con up uuid xxx to have connection working again. The next question, what's causing your carrier to flip-flop int he first place? Power problems at the other end of ehternet cable. Beyond my control. -- Tomasz TorczTo co nierealne -- tutaj jest normalne. xmpp: zdzich...@chrome.pl Ziomale na życie mają tu patenty specjalne. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Updates make DVD upgrade insecure. (was: AutoQA upgrade path failure makes no sense to me)
Kevin Kofler wrote: I've been saying all the time that the DVD must get fixed to support enabling the updates repository also for upgrades, not just for new installs. In fact, I'd even go as far as saying it should REQUIRE it, not just support it. That would make bug 998 even more urgent than it already is – especially if the updates repository were required, as that would change the upgrade from secure to insecure. Currently it is possible to upgrade by DVD in a secure way. It requires some manual checking but it can be done if you have the knowledge. If packages are downloaded during the upgrade, then the upgrade is insecure unless Anaconda learns to verify the signatures on the packages it downloads. Björn Persson 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: wireless-tools/net-tools are DEPRECATED
On 04/27/2011 08:48 PM, Dan Williams wrote: NM has had one for a while: 4 seconds. THe problem with longer is that then any time you do disconnect the cable or undock your laptop, NM would think that you were still connected for 10 seconds (or more) until if flipped over to wifi. So there's a conflict here between people that occasionally pull out the network cable to do stuff, and between people that dock/undock and move from wired to wifi. But when you switch from wired to wifi you get a new IP so all your connections are lost. Having to wait a few seconds more will not add too much annoyance to the process. On the other end, if someone steps on my cable, I think it is unreasonable that I only have 4 seconds to fix it before losing my connections. I think 4 seconds is too low. And 10 seconds too, I'd say. Why not configurable? Or, why not to ask the user? (wired carrier lost for xx seconds, switching to wifi in xx seconds: buttonswitch now, buttonadd another minute) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wireless-tools/net-tools are DEPRECATED
Roberto Ragusa m...@robertoragusa.it wrote: Why not configurable? Or, why not to ask the user? (wired carrier lost for xx seconds, switching to wifi in xx seconds: buttonswitch now, buttonadd another minute) Personally, I've seen that it's usually I want to be on this network until I disconnect. My example was the wireless in my dorm room. Going from my room to a friend's, there was a region of no connection (brick walls, distance, what have you) whereas my destination had good reception via either the windows or the fact that it was just 10 feet away, vertically. NM would drop my wireless and connect to the campus wireless as a fallback. This drops me out of my network and I had to manually fix the problem. Similar problems where the authenticated network was spotty but the non-authenticated network was fine. --Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F14, can't logout from X environment - Bug 665540
Marco jjletho67-aro...@yahoo.it wrote: I see something similar on my work machine with ATI (unsure of the actual card specs). I've worked around this by switching to the TTY which I did startx from and sending it a ^C. This has worked for me flawlessly so far. Hi, thank you for your suggestion but in my case, when the problem occours, keyboard and mouse are unresponsive Right. Same here. I should have mentioned that the ^C sent to startx is the logout action here :) . Sorry Ben, now it's clear, thank you :-) and I will do some tests and I'll let you know the result. However i think that by this way you have never correctly closed X environment. Do you suffer any collateral effects ? The only things running that care about X when I do this are: - urxvt256cd - xmobar - xmonad None of them hold important files open (at least for writing), so it's cleaner than a reboot would be in this case. The serverauth is left laying around, but reusing that is hitting the PID jackpot AFAIK. --Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ipv6 tools + ipv4 tools fusion.
why ipv6 and ipv4 have different name for the tools ? for example ping6 and ping I think it's possible writing a wrapper to detect if a ip is v4 or v6 and execute the correct cmd, what fedora guys think about this ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ipv6 tools + ipv4 tools fusion.
On Mi, 2011-04-27 at 20:17 -0300, Itamar Reis Peixoto wrote:
why ipv6 and ipv4 have different name for the tools ?
for example
ping6 and ping
I think it's possible writing a wrapper to detect if a ip is v4 or v6
and execute the correct cmd,
$ ping{6} www.kame.net
If you are using a DNS name it gets ambiguous what to use in the end, IP
v4 or v6.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ipv6 tools + ipv4 tools fusion.
Am 28.04.2011 01:17, schrieb Itamar Reis Peixoto: why ipv6 and ipv4 have different name for the tools ? for example ping6 and ping I think it's possible writing a wrapper to detect if a ip is v4 or v6 and execute the correct cmd, what fedora guys think about this ? because the same hostname can have A and AAA records and the people commonly use ping (sysadmins) must be able to decide what they will test? most times you ping a hostname and with the same command you would have to use an extra parameter, not easier/clearer signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
On Wed, 27 Apr 2011 16:20:24 +0800 Nicholas van Rheede van Oudtshoorn vano...@gmail.com wrote: Greetings all! welcome! My name is Nicholas van Oudtshoorn - long time Fedora user, first time (hopefully!) contributor. One of my jobs (apart from being a church pastor) involves taking care of the IT systems for a local seminary here in Perth, Western Australia. We've been running Fedora on our servers for several years now - basically because it's the distro I find the most intuitive! As part of my duties, I manage the seminary's library software - Koha. Although this runs fine under Fedora, quite a few of it's dependencies are not available in the Fedora repositories. Given the number of libraries using koha (big and small - check out http://wiki.koha-community.org/wiki/Koha_Users_Worldwide ), I suspect that rectifying this could be of some use! To this end, I've started packaging up build requirements. The first package I've made (boy - it's more complex than it seems at first :-) ) is for the Zebra database engine. After that, I'd like to work on the perl packages that are missing. (CPAN is useful - but yum is *so* much easier!) I'd also like to see about updating the yaz package. (yaz is currently available in Fedora - but is quite a few versions behind the upstream) Anywho - just thought I'd introduce myself. I've loved using Fedora over the last years - and am excited about the possibility of giving something back. Excellent. Welcome to the fun! kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ipv6 tools + ipv4 tools fusion.
On Thu, Apr 28, 2011 at 02:59:09AM +0200, Reindl Harald wrote: because the same hostname can have A and AAA records and the people commonly use ping (sysadmins) must be able to decide what they will test? Use -4 -or -6 parameters if you care to force one vs. the other. most times you ping a hostname and with the same command you would have to use an extra parameter, not easier/clearer I disagree. In some cases you might only care that either/or IPv4/IPv6 works to reach a hostname. Right now, you would need to run both commands and wrap logic around that in order to script a test for connectivity. Also, there is precedent to using -4 and -6 for this purpose. Do you propose we add telnet6, ftp6, ssh6, etc commands? I think not, but if you did care to have a special IPv6 version of a command that had a -6 option, you could always wrap command -6 in a script called command6. Finally, at some point people will care more about IPv6 and less about IPv4, and then the command6 versions will just be extra typing for no good reason. I do miss -4 and -6 options for the telnet and ftp commands though. That would be nice to have. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: wireless-tools/net-tools are DEPRECATED
On Wed, 2011-04-27 at 13:48 -0500, Dan Williams wrote: On Tue, 2011-04-26 at 09:46 -0700, Adam Williamson wrote: On Sun, 2011-04-24 at 16:35 +, Ben Boeckel wrote: deal with in these cases) than some packets were lost. An option to persist connections despite something probably not actually existing would be nice for situations like this. Or, more simply, just a short time-out on cable disconnect (say 10 seconds) before treating the connection as down? NM has had one for a while: 4 seconds. THe problem with longer is that then any time you do disconnect the cable or undock your laptop, NM would think that you were still connected for 10 seconds (or more) until if flipped over to wifi. So there's a conflict here between people that occasionally pull out the network cable to do stuff, and between people that dock/undock and move from wired to wifi. That's a point. How about no timeout when there's an alternative connection available, timeout when there isn't? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 and Broadcom BCM4313
On Wed, 2011-04-27 at 21:15 +0200, Kevin Kofler wrote: Adam Williamson wrote: In addition to what Matt says, probably the best way to get it working in F15 for now (pragmatically speaking) is to install the proprietary 'wl' driver from a third party repository (the standard one has it packaged as kmod-wl / akmod-wl). That driver supports the chip in question and works, per multiple reports. RPM Fusion should really be updating its kmod-staging. The package in RPM Fusion for F15 is ancient and won't even install. A current kmod-staging would bring Free support for this chipset instead of the proprietary one. RPM Fusion is people ;) it needs someone to do it, I guess. I don't know if there's an active maintainer for that package. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ipv6 tools + ipv4 tools fusion.
On Wed, 27 Apr 2011, Chuck Anderson wrote: On Thu, Apr 28, 2011 at 02:59:09AM +0200, Reindl Harald wrote: because the same hostname can have A and AAA records and the people commonly use ping (sysadmins) must be able to decide what they will test? Use -4 -or -6 parameters if you care to force one vs. the other. +1 It's really annoying, because ping takes a long time to fail when you try it on an name. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RE: GNOME 3 Fallback Mode
Regarding whether G3 should even have a fallback mode; of course it should. At least until it becomes stable. That's a no-brainer. Regards -- PHOTO RESOLUTIONS - Photo - Graphic - Web C and L Jones - Proprietors ABN: 98 317 740 240 WWW: http://photoresolutions.freehostia.com @: chrisjo...@comcen.com.au or photoresoluti...@comcen.com.au Command lines and Linux terminals are my comfort zone! OS: openSUSE 11.4 System: Linux 2.6.37.1-1.2 x86_64 Desktop: KDE 4.6.0 OS: Windows XP System: x86 Desktop: Professional SP3 OS: FreeBSD 7.3 System: i386 Server: Headless-WebUI+putty -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: About placement of dual-life modules
On Tue, Apr 26, 2011 at 5:51 PM, Petr Pisar ppi...@redhat.com wrote: On Fri, Apr 22, 2011 at 11:00:46PM +0800, Robin Lee wrote: Some dual-life modules, like PathTools and CGI, are placed within vendor path in Fedora 15. This situation is not expected by some applications, for example, cpanm -L command will definitely fail if an installing package needs such dual-life modules. This is problem of that applications. They should not expect exact location. Formally, some packagers wanted to install all Fedora modules into core. But there are some RPM-related problems (files in debuginfo subpackages would conflict because debug data are delivered by one subpackage for all subpackages together) and some packagers were against it. I agree that this is the true obstacle. So, why not just exclude such modules in perl.spec, Because the meaning of dual-lived packages is to live together (in Fedora repository, not in system). The idea is users are not disturbed by updating all perl core subpackages just for sake of upgrading a core module. and place the updated dual-life modules to site paths? Site? Site is for third-party modules. If Fedora installed packages into site, where would user install their software? Oh, sorry... s/site/vendor/ . I think cpan* should be (pre)configured to install into site instead of vendor. -- Petr -- 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 -- 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-Padre/f15/master] Add padre.desktop
commit 32ce1124d1fb5dd26ee0e676ffe9cb02a45c13c6
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Wed Apr 27 10:08:57 2011 +0200
Add padre.desktop
.gitignore |1 +
perl-Padre.spec | 12 +++-
sources |1 +
3 files changed, 13 insertions(+), 1 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 79b5bf3..fa89b54 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,4 @@ Padre-0.64.tar.gz
/Padre-0.80.tar.gz
/Padre-0.82.tar.gz
/Padre-0.84.tar.gz
+/padre.desktop
diff --git a/perl-Padre.spec b/perl-Padre.spec
index 27a753b..a51450f 100644
--- a/perl-Padre.spec
+++ b/perl-Padre.spec
@@ -3,14 +3,16 @@
Name: perl-Padre
Version:0.84
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Perl Application Development and Refactoring Environment
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Padre/
Source0:
http://search.cpan.org/CPAN/authors/id/P/PL/PLAVEN/Padre-%{version}.tar.gz
+Source1:padre.desktop
BuildArch: noarch
BuildRequires: gettext
+BuildRequires: desktop-file-utils
BuildRequires: perl(Alien::wxWidgets) = 0.46
BuildRequires: perl(Capture::Tiny) = 0.06
BuildRequires: perl(Class::Adapter) = 1.05
@@ -328,6 +330,10 @@ find
${RPM_BUILD_ROOT}%{perl_vendorlib}/auto/share/dist/Padre/locale/ \
sed 's|^'$RPM_BUILD_ROOT'||
s|\(.*/\)\([^.]*\)\(\.mo\)$|%lang(\2) \1\2\3|' %{name}.lang
+# install icon
+desktop-file-install --vendor=fedora \
+--dir=$RPM_BUILD_ROOT/%{_datadir}/applications %{SOURCE1}
+
%{_fixperms} $RPM_BUILD_ROOT/*
@@ -360,11 +366,15 @@ find
${RPM_BUILD_ROOT}%{perl_vendorlib}/auto/share/dist/Padre/locale/ \
%{perl_vendorlib}/auto/share/dist/Padre/templates
%{perl_vendorlib}/auto/share/dist/Padre/timeline
%{perl_vendorlib}/Padre*
+%{_datadir}/applications/fedora-padre.desktop
%{_mandir}/man3/*
%{_bindir}/padre
%changelog
+* Tue Mar 15 2011 Marcela Mašláňová mmasl...@redhat.com - 0.84-2
+- 699569 add missing .desktop file
+
* Tue Mar 15 2011 Marcela Mašláňová mmasl...@redhat.com - 0.84-1
- update to 0.84
- remove clear section
diff --git a/sources b/sources
index 1d8b733..72fc75f 100644
--- a/sources
+++ b/sources
@@ -1 +1,2 @@
29c21759803089fa6a9b981ae35ba512 Padre-0.84.tar.gz
+60785f75d6c4b556c1293a51d80c465e padre.desktop
--
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
[Bug 699569] There is no Application icon in Gnome3's Activities/Applications
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=699569 --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2011-04-27 04:50:50 EDT --- perl-Padre-0.84-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/perl-Padre-0.84-2.fc15 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 699569] There is no Application icon in Gnome3's Activities/Applications
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=699569 Marcela Mašláňová mmasl...@redhat.com changed: What|Removed |Added Status|MODIFIED|ASSIGNED --- Comment #5 from Marcela Mašláňová mmasl...@redhat.com 2011-04-27 04:53:44 EDT --- (In reply to comment #1) Gnome3 apparently still uses the same directory and there isn't a perl-Padre.desktop file in there so I guess that there just isn't one. I thought that there was one, but maybe I was wrong. If anybody can remember there not being a .desktop file for perl-Padre then please close this bug, but I thought that there was one. Could you test it in Gnome? This update does work for me in KDE. Please add karma in bodhi. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Padre/f15/master] Install icons into correct paths.
commit 605ab522d5daeccc9ecfeb83c9d2ea61f82da2b2
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Wed Apr 27 12:50:39 2011 +0200
Install icons into correct paths.
Icon wasn't visible in krunner and Activites.
perl-Padre.spec | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
---
diff --git a/perl-Padre.spec b/perl-Padre.spec
index a51450f..bf18a90 100644
--- a/perl-Padre.spec
+++ b/perl-Padre.spec
@@ -3,7 +3,7 @@
Name: perl-Padre
Version:0.84
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Perl Application Development and Refactoring Environment
License:GPL+ or Artistic
Group: Development/Libraries
@@ -330,6 +330,12 @@ find
${RPM_BUILD_ROOT}%{perl_vendorlib}/auto/share/dist/Padre/locale/ \
sed 's|^'$RPM_BUILD_ROOT'||
s|\(.*/\)\([^.]*\)\(\.mo\)$|%lang(\2) \1\2\3|' %{name}.lang
+# install logo of Padre into correct paths
+mkdir -p $RPM_BUILD_ROOT/%{_datadir}/icons/hicolor/{64x64,16x16}/apps/
+install -m644 ./share/icons/padre/64x64/logo.png \
+$RPM_BUILD_ROOT/%{_datadir}/icons/hicolor/64x64/apps/padre.png
+install -m644 ./share/icons/padre/16x16/logo.png \
+$RPM_BUILD_ROOT/%{_datadir}/icons/hicolor/16x16/apps/padre.png
# install icon
desktop-file-install --vendor=fedora \
--dir=$RPM_BUILD_ROOT/%{_datadir}/applications %{SOURCE1}
@@ -367,11 +373,16 @@ desktop-file-install --vendor=fedora \
%{perl_vendorlib}/auto/share/dist/Padre/timeline
%{perl_vendorlib}/Padre*
%{_datadir}/applications/fedora-padre.desktop
+%{_datadir}/icons/hicolor/16x16/apps/padre.png
+%{_datadir}/icons/hicolor/64x64/apps/padre.png
%{_mandir}/man3/*
%{_bindir}/padre
%changelog
+* Wed Apr 27 2011 Marcela Mašláňová mmasl...@redhat.com - 0.84-3
+- install icons into correct path, should add icon into Activity for Gnome3
+
* Tue Mar 15 2011 Marcela Mašláňová mmasl...@redhat.com - 0.84-2
- 699569 add missing .desktop file
--
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
[Bug 700043] New: perl-Devel-CheckOS-1.64 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Devel-CheckOS-1.64 is available https://bugzilla.redhat.com/show_bug.cgi?id=700043 Summary: perl-Devel-CheckOS-1.64 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Devel-CheckOS AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora Story Points: --- Latest upstream release: 1.64 Current version in Fedora Rawhide: 1.63 URL: http://search.cpan.org/dist/Devel-CheckOS/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Fatal/el6/master] (3 commits) ...Update to 0.005
Summary of changes: 39dbda4... - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass (*) ec3c903... Update to 0.004 (*) 3001da8... Update to 0.005 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 700045] New: perl-Mojolicious-1.21 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Mojolicious-1.21 is available https://bugzilla.redhat.com/show_bug.cgi?id=700045 Summary: perl-Mojolicious-1.21 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Mojolicious AssignedTo: yan...@declera.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: yan...@declera.com, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Latest upstream release: 1.21 Current version in Fedora Rawhide: 1.16 URL: http://search.cpan.org/dist/Mojolicious/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 700046] New: perl-Test-DistManifest-1.011 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Test-DistManifest-1.011 is available https://bugzilla.redhat.com/show_bug.cgi?id=700046 Summary: perl-Test-DistManifest-1.011 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Test-DistManifest AssignedTo: ppi...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, ppi...@redhat.com, psab...@redhat.com Classification: Fedora Story Points: --- Latest upstream release: 1.011 Current version in Fedora Rawhide: 1.009 URL: http://search.cpan.org/dist/Test-DistManifest/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Fatal] Created tag perl-Test-Fatal-0.005-1.el6
The lightweight tag 'perl-Test-Fatal-0.005-1.el6' was created pointing to: 3001da8... Update to 0.005 -- 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
[Bug 700047] New: perlbrew-0.19 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perlbrew-0.19 is available https://bugzilla.redhat.com/show_bug.cgi?id=700047 Summary: perlbrew-0.19 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perlbrew AssignedTo: iarn...@gmail.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: iarn...@gmail.com, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Latest upstream release: 0.19 Current version in Fedora Rawhide: 0.18 URL: http://search.cpan.org/dist/App-perlbrew/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Devel-CheckOS-1.64.tar.gz uploaded to lookaside cache by mmaslano
A file has been added to the lookaside cache for perl-Devel-CheckOS: 458d93207c4feaf2fbdcb14962be82e4 Devel-CheckOS-1.64.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-Devel-CheckOS] Upload to 1.64
commit ed2f90e9ba4afcd721aaa68b5e6355c400343aa7
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Wed Apr 27 13:09:34 2011 +0200
Upload to 1.64
.gitignore |1 +
perl-Devel-CheckOS.spec | 12 +---
sources |2 +-
3 files changed, 7 insertions(+), 8 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 5b2f2c2..479e644 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
Devel-CheckOS-1.50.tar.gz
/Devel-CheckOS-1.63.tar.gz
+/Devel-CheckOS-1.64.tar.gz
diff --git a/perl-Devel-CheckOS.spec b/perl-Devel-CheckOS.spec
index cf2e85c..8228091 100644
--- a/perl-Devel-CheckOS.spec
+++ b/perl-Devel-CheckOS.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-CheckOS
-Version:1.63
-Release:3%{?dist}
+Version:1.64
+Release:1%{?dist}
Summary:Check what OS we're running on
License:GPLv2 or Artistic
Group: Development/Libraries
@@ -37,8 +37,6 @@ Linux, Solaris, AIX etc.
make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
-
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
@@ -55,9 +53,6 @@ rm -rf t/XX-autodetected-linux-as-Y.t
%check
make test
-%clean
-rm -rf $RPM_BUILD_ROOT
-
%files
%defattr(-,root,root,-)
%doc ARTISTIC.txt CHANGES GPL2.txt README TODO
@@ -67,6 +62,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Wed Apr 27 2011 Marcela Mašláňová mmasl...@redhat.com 1.64-1
+- update to 1.64
+
* Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.63-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
diff --git a/sources b/sources
index d537825..19803e9 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c6a555cb7c289b70642e7b573d9acdee Devel-CheckOS-1.63.tar.gz
+458d93207c4feaf2fbdcb14962be82e4 Devel-CheckOS-1.64.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-Padre/f15/master] padre.desktop upload with changes into git instead of sources.
commit 3468f242ba3cd7552f58854c54919f3a0169a382 Author: Marcela Mašláňová mmasl...@redhat.com Date: Wed Apr 27 13:29:38 2011 +0200 padre.desktop upload with changes into git instead of sources. .gitignore|1 - padre.desktop | 10 ++ sources |1 - 3 files changed, 10 insertions(+), 2 deletions(-) --- diff --git a/.gitignore b/.gitignore index fa89b54..79b5bf3 100644 --- a/.gitignore +++ b/.gitignore @@ -6,4 +6,3 @@ Padre-0.64.tar.gz /Padre-0.80.tar.gz /Padre-0.82.tar.gz /Padre-0.84.tar.gz -/padre.desktop diff --git a/padre.desktop b/padre.desktop new file mode 100644 index 000..8c6e9bb --- /dev/null +++ b/padre.desktop @@ -0,0 +1,10 @@ +[Desktop Entry] +Name=Padre +Comment=Perl Application Development and Refactoring Environment +Comment[cs]=Prostředí pro vývoj a přepis perlových aplikací +GenericName=Perl IDE +Exec=padre +Icon=padre +Terminal=false +Type=Application +Categories=Development;IDE; diff --git a/sources b/sources index 72fc75f..1d8b733 100644 --- a/sources +++ b/sources @@ -1,2 +1 @@ 29c21759803089fa6a9b981ae35ba512 Padre-0.84.tar.gz -60785f75d6c4b556c1293a51d80c465e padre.desktop -- 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
[Bug 700043] perl-Devel-CheckOS-1.64 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=700043 Marcela Mašláňová mmasl...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution||RAWHIDE Last Closed||2011-04-27 07:12:32 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Test-DistManifest-1.011.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Test-DistManifest: 669c4f3e99dd60f1a7a198b3b2e61026 Test-DistManifest-1.011.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-Test-DistManifest] 1.011 bump
commit 73d4f18c1316337fa1fc74f94a9e8926f4b25e41
Author: Petr Písař ppi...@redhat.com
Date: Wed Apr 27 18:13:37 2011 +0200
1.011 bump
.gitignore |1 +
perl-Test-DistManifest.spec | 23 +++
sources |2 +-
3 files changed, 17 insertions(+), 9 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 1f40bb0..2b10cde 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/Test-DistManifest-1.009.tar.gz
+/Test-DistManifest-1.011.tar.gz
diff --git a/perl-Test-DistManifest.spec b/perl-Test-DistManifest.spec
index 9533fe4..93a09e8 100644
--- a/perl-Test-DistManifest.spec
+++ b/perl-Test-DistManifest.spec
@@ -1,5 +1,5 @@
Name: perl-Test-DistManifest
-Version:1.009
+Version:1.011
Release:1%{?dist}
Summary:Author test that validates a package MANIFEST
License:GPL+ or Artistic
@@ -7,24 +7,25 @@ Group: Development/Libraries
URL:http://search.cpan.org/dist/Test-DistManifest/
Source0:
http://www.cpan.org/authors/id/J/JA/JAWNSY/Test-DistManifest-%{version}.tar.gz
BuildArch: noarch
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.31
BuildRequires: perl(File::Spec)
BuildRequires: perl(File::Spec::Unix)
-BuildRequires: perl(Module::Build)
BuildRequires: perl(Module::Manifest) = 0.07
-BuildRequires: perl(Test::Builder) = 0.72
+BuildRequires: perl(Test::Builder)
BuildRequires: perl(Test::More) = 0.62
# Tests only:
BuildRequires: perl(Test::Builder::Tester)
BuildRequires: perl(Test::NoWarnings) = 0.084
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
Requires: perl(Module::Manifest) = 0.07
-Requires: perl(Test::Builder) = 0.72
+Requires: perl(Test::Builder)
# This is a plug-in into Test::More. Depend on it even if not mentioned in the
# code
Requires: perl(Test::More) = 0.62
# Filter underspecifed dependencies
%filter_from_requires /^perl(Module::Manifest)$/d
+# Filter multiple dependencies
%filter_from_requires /^perl(Test::Builder)$/d
%filter_setup
@@ -36,18 +37,20 @@ distribution.
%setup -q -n Test-DistManifest-%{version}
%build
-%{__perl} Build.PL installdirs=core
-./Build
+%{__perl} Makefile.PL INSTALLDIRS=perl OPTIMIZE=$RPM_OPT_FLAGS
+make %{?_smp_mflags}
%install
-./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
# post-install rpmbuild scripts contaminates RPM_BUILD_ROOT (bug #672538).
rm debug*.list
-./Build test
+make test
%files
%defattr(-,root,root,-)
@@ -56,6 +59,10 @@ rm debug*.list
%{_mandir}/man3/*
%changelog
+* Wed Apr 27 2011 Petr Pisar ppi...@redhat.com - 1.011-1
+- 1.011 bump
+- Move to ExtUtils::MakeMaker
+
* Tue Jan 25 2011 Petr Pisar ppi...@redhat.com 1.009-1
- Specfile autogenerated by cpanspec 1.78.
- Remove BuildRoot stuff
diff --git a/sources b/sources
index 1b706ad..622df2c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-014331ccac1b3efe49f0a55fc59e552d Test-DistManifest-1.009.tar.gz
+669c4f3e99dd60f1a7a198b3b2e61026 Test-DistManifest-1.011.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
[Bug 700046] perl-Test-DistManifest-1.011 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=700046 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Test-DistManifest-1.01 ||1-1.fc16 Resolution||RAWHIDE Last Closed||2011-04-27 12:20:04 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 700047] perlbrew-0.19 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=700047 Iain Arnell iarn...@gmail.com changed: What|Removed |Added Status|NEW |ASSIGNED Depends on||700141(perl-Devel-PatchPerl ||) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 699569] There is no Application icon in Gnome3's Activities/Applications
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=699569 --- Comment #8 from gat gatlinsulli...@yahoo.com 2011-04-27 16:17:46 EDT --- I tested this in fall-back mode. It is in programming, but there is no icon. There is still no icon when the icon is dragged to the toolbar. How can I remove the application launcher from the toolbar? Right-click sucks in fall-back mode too. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
