Re: Fedora ARM and SecureBoot
On Thu, Jun 07, 2012 at 07:41:32PM -0400, Sam Varshavchik wrote: > Przemek Klosowski writes: > > >What is Fedora ARM planning to do about the upcoming Microsoft > >hardware certification spec requiring Secure Boot? > > Why, all they have to do is simply pay another $99. Problem solved. We wouldn't even have to do that. But, as I said, I'm not in favour of doing something that results in a platform where the user is unable to run the software they choose. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Laptop screen stuck on very low brightness
Corey Richardson wrote: > How are you trying to modify the brightness? Holding down Fn and pressing the up and down keys is supposed to adjust the brightness. A little box is shown in the middle of the screen with a horizontal bar that indicates the brightness. That part still works. The bar grows and shrinks, but the brightness is not affected. > Does `xbacklight` work? All xbacklight commands I try (except for "xbacklight -help") cause the screen to flash once and return zero. Even "xbacklight -get" causes a flash, prints nothing, and returns zero. 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: Fedora ARM and SecureBoot
Przemek Klosowski writes: What is Fedora ARM planning to do about the upcoming Microsoft hardware certification spec requiring Secure Boot? Why, all they have to do is simply pay another $99. Problem solved. So, what is the current thinking? The current consensus seems to be that something or someone, somewhere around here, has jumped the shark. Not completely clear what, or who, that something is; where exactly the jump over the shark happened; and how high over the shark the jump was; but it definitely happened and the best investigative minds are on the case, searching and gathering the details. I realize that not everyone in the audience may be familiar with this idiom, so here it is: http://en.wikipedia.org/wiki/Jumping_the_shark pgp6yGFqm1CEC.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Airtime am about to build it
Hello guys anybody working on it if not am about to build it http://www.sourcefabric.org/en/airtime/download/ Regards, Adrian.- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Wed, 2012-06-06 at 07:53 -0400, Josh Boyer wrote: > On Wed, Jun 6, 2012 at 6:15 AM, Benny Amorsen wrote: > > Adam Williamson writes: > > > >> 3. yum *if you follow the instructions carefully* > > > > Those instructions include dracut doing unspecified magic. For other > > The magic was quite specified. You rebuild the initramfs with the > convertfs module included, and pass the approriate arguments on boot. > There's a wiki page covering exactly that. Note that the exact same magic is done for you automatically during an anaconda/preupgrade-based upgrade; the same dracut invocation is performed, it's just that you don't do it manually. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Wed, 2012-06-06 at 12:15 +0200, Benny Amorsen wrote: > Adam Williamson writes: > > > 3. yum *if you follow the instructions carefully* > > Those instructions include dracut doing unspecified magic. For other > releases I'd agree with you and do a yum upgrade, but I must admit I > don't dare try this time. It's not really unspecified; it's doing the /usr move. I've followed the 16->17 yum upgrade instructions on five systems with complete success. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Deleting a package from f18/rawhide builds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 07 Jun 2012 17:37:25 -0400 (EDT) Kaleb Keithley wrote: > How do I do this? (The package is hekafs.) > > I have retired the package in f18. > > I have removed the f18 tag from all the fc18 builds. > > Bit the rawhide build is still pulling the fc17 version of the > package. > > There are no dependencies on it. > > I have googled for it, but my google fu is not good with this one. > > Clearly I have missed something, but what? > > Thanks, > http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life you file a ticket to have it blocked by release engineering Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk/RI1oACgkQkSxm47BaWfc+CgCgoUB4KI75/YwldaF6yH2wRxD9 z1wAnjS+r7VcaoRXF/85aiuoxj93ZWL3 =FYxz -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Deleting a package from f18/rawhide builds?
> > How do I do this? (The package is hekafs.) > > I have retired the package in f18. > > I have removed the f18 tag from all the fc18 builds. > > But the rawhide build is still pulling the fc17 version of the package. > > There are no dependencies on it. And FWIW, the latest glusterfs rpm Obsoletes hekafs. -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Deleting a package from f18/rawhide builds?
On Thu, 07 Jun 2012 17:37:25 -0400 (EDT) Kaleb Keithley wrote: > How do I do this? (The package is hekafs.) > > I have retired the package in f18. > > I have removed the f18 tag from all the fc18 builds. > > Bit the rawhide build is still pulling the fc17 version of the > package. > > There are no dependencies on it. > > I have googled for it, but my google fu is not good with this one. > > Clearly I have missed something, but what? http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life You're missing step 7 at least. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Deleting a package from f18/rawhide builds?
On Thu, Jun 7, 2012 at 10:37 PM, Kaleb Keithley wrote: > How do I do this? (The package is hekafs.) > > I have retired the package in f18. > > I have removed the f18 tag from all the fc18 builds. > > Bit the rawhide build is still pulling the fc17 version of the package. > > There are no dependencies on it. > > I have googled for it, but my google fu is not good with this one. > > Clearly I have missed something, but what? You file a rel-eng ticket requesting to get it blocked https://fedorahosted.org/rel-eng/newticket -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Laptop screen stuck on very low brightness
On Thu, 7 Jun 2012 19:20:21 +0200 Björn Persson wrote: > After I upgraded to Fedora 17 my laptop screen is stuck on a very low > brightness setting, which makes it very hard to read. It's OK during > POST, Grub and early Linux initialization, but goes dim before I'm > prompted for the disk encryption passphrase. After that I can't turn > the brightness back up. > How are you trying to modify the brightness? Does `xbacklight` work? > Which package should I report this against? Linux? X? Plymouth? Or > something else? > I believe that would be a kernel issue, depending on where the problem actually lies. > Björn Persson -- Corey Richardson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Deleting a package from f18/rawhide builds?
How do I do this? (The package is hekafs.) I have retired the package in f18. I have removed the f18 tag from all the fc18 builds. Bit the rawhide build is still pulling the fc17 version of the package. There are no dependencies on it. I have googled for it, but my google fu is not good with this one. Clearly I have missed something, but what? Thanks, -- Kaleb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Net-OpenSSH] Perl 5.16 rebuild
commit 8e61a2aa5e6232bede07462e1159d9a1c8a2d0eb
Author: Petr Písař
Date: Thu Jun 7 23:30:04 2012 +0200
Perl 5.16 rebuild
perl-Net-OpenSSH.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Net-OpenSSH.spec b/perl-Net-OpenSSH.spec
index 5d015dc..a85e7e0 100644
--- a/perl-Net-OpenSSH.spec
+++ b/perl-Net-OpenSSH.spec
@@ -1,6 +1,6 @@
Name: perl-Net-OpenSSH
Version:0.57
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Perl SSH client package implemented on top of OpenSSH
License:GPL+ or Artistic
Group: Development/Libraries
@@ -50,6 +50,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Jun 07 2012 Petr Pisar - 0.57-5
+- Perl 5.16 rebuild
+
* Mon Jun 04 2012 Petr Pisar - 0.57-4
- Do not require specific architecture of openssh-clients
--
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-CSS-Minifier] Perl 5.16 rebuild
commit 6bc72240fd0cb2f8e9b0b6462c30152b9f85a9ba
Author: Petr Písař
Date: Thu Jun 7 23:29:34 2012 +0200
Perl 5.16 rebuild
perl-CSS-Minifier.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-CSS-Minifier.spec b/perl-CSS-Minifier.spec
index 4db7c13..11f192a 100644
--- a/perl-CSS-Minifier.spec
+++ b/perl-CSS-Minifier.spec
@@ -1,6 +1,6 @@
Name: perl-CSS-Minifier
Version:0.01
-Release:10%{?dist}
+Release:11%{?dist}
# lib/CSS/Minifier.pm -> GPL+ or Artistic
License:GPL+ or Artistic
Group: Development/Libraries
@@ -53,6 +53,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Thu Jun 07 2012 Petr Pisar - 0.01-11
+- Perl 5.16 rebuild
+
* Wed May 30 2012 Emmanuel Seyman - 0.01-10
- Clean up spec file
- Add perl default filter
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-SSH2] Perl 5.16 rebuild
commit 7fb78d62876cf4938f4ca21cb1349ff41f0cac75
Author: Petr Písař
Date: Thu Jun 7 23:29:26 2012 +0200
Perl 5.16 rebuild
perl-Net-SSH2.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Net-SSH2.spec b/perl-Net-SSH2.spec
index 911f170..08d3a1d 100644
--- a/perl-Net-SSH2.spec
+++ b/perl-Net-SSH2.spec
@@ -1,6 +1,6 @@
Name: perl-Net-SSH2
Version:0.44
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Support for the SSH 2 protocol via libSSH2
License:GPL+ or Artistic
Group: Development/Libraries
@@ -54,6 +54,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Jun 07 2012 Petr Pisar - 0.44-2
+- Perl 5.16 rebuild
+
* Fri Apr 27 2012 Petr Šabata - 0.44-1
- 0.44 bump
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fedora ARM and SecureBoot
On Thu, Jun 7, 2012 at 9:30 PM, drago01 wrote: > On Thu, Jun 7, 2012 at 10:02 PM, Adam Jackson wrote: >> On Thu, 2012-06-07 at 21:12 +0200, drago01 wrote: >>> On Thu, Jun 7, 2012 at 7:14 PM, Przemek Klosowski >>> wrote: >>> > What is Fedora ARM planning to do about the upcoming Microsoft hardware >>> > certification spec requiring Secure Boot? By the spec, there must be a way >>> > to disable it on x86, but on ARM they expressly prohibit turning it off. I >>> > guess the current Fedora/RedHat stance, as explained by Matthew Garrett, >>> > is >>> > to obtain a MS certificate covering x86 and presumably ARM kernels from >>> >>> That's incorrect. The plan is to support secure boot only on x86. >> >> What gives you that impression? > > Matthew's blog. > >> Why would we _not_ support secure boot >> on arm? > > I think we should do that. (support in on ARM as well). Well at the moment there's no even support for uEFI on ARM linux so at the moment it's putting the cart before the horse. It is being worked upon and it's certainly in the pipeline but at the moment it's not there so it's a mute point really, in the future it's possible it will be supportable but it's a long way out which ever way you look at it. Let's get decent Fedora support for the rest of the currently readily available devices and the 100s more that will come out between now and when uEFI on ARM becomes a reality. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Intent to retire: nss_ldap
Hi, I would like to retire PADL's nss_ldap and pam_ldap from current Rawhide. SSSD has been the default in Fedora for quite a few releases with nss-pam-ldapd as another option for deployments that, for some reason, do not want to migrate to the SSSD. nss_ldap also seems to be abandoned upstream. Are there still any users of nss_ldap? If so, what are the reasons keeping you from using either nss-pam-ldapd or the SSSD? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM and SecureBoot
On Thu, Jun 7, 2012 at 10:02 PM, Adam Jackson wrote: > On Thu, 2012-06-07 at 21:12 +0200, drago01 wrote: >> On Thu, Jun 7, 2012 at 7:14 PM, Przemek Klosowski >> wrote: >> > What is Fedora ARM planning to do about the upcoming Microsoft hardware >> > certification spec requiring Secure Boot? By the spec, there must be a way >> > to disable it on x86, but on ARM they expressly prohibit turning it off. I >> > guess the current Fedora/RedHat stance, as explained by Matthew Garrett, is >> > to obtain a MS certificate covering x86 and presumably ARM kernels from >> >> That's incorrect. The plan is to support secure boot only on x86. > > What gives you that impression? Matthew's blog. > Why would we _not_ support secure boot > on arm? I think we should do that. (support in on ARM as well). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM and SecureBoot
Once upon a time, Adam Jackson said: > If there are ARM machines where UEFI and Secure Boot are available, > we're going to have tools to do your own trust database management > anyway, so why would supporting them be any different from doing the > same on x86? For Windows 8 certification on ARM, Microsoft is going to require UEFI with Secure Boot enabled _and_ no method for users to disable Secure Boot or enroll their own keys (the opposite of x86 where they require a disable method and custom key enrollment support). Right now, Win8/ARM is a market of zero, but there will be hardware coming. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM and SecureBoot
On Thu, 2012-06-07 at 21:12 +0200, drago01 wrote: > On Thu, Jun 7, 2012 at 7:14 PM, Przemek Klosowski > wrote: > > What is Fedora ARM planning to do about the upcoming Microsoft hardware > > certification spec requiring Secure Boot? By the spec, there must be a way > > to disable it on x86, but on ARM they expressly prohibit turning it off. I > > guess the current Fedora/RedHat stance, as explained by Matthew Garrett, is > > to obtain a MS certificate covering x86 and presumably ARM kernels from > > That's incorrect. The plan is to support secure boot only on x86. What gives you that impression? Why would we _not_ support secure boot on arm? - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM and SecureBoot
On Thu, 2012-06-07 at 13:14 -0400, Przemek Klosowski wrote: > What is Fedora ARM planning to do about the upcoming Microsoft hardware > certification spec requiring Secure Boot? By the spec, there must be a > way to disable it on x86, but on ARM they expressly prohibit turning it > off. I guess the current Fedora/RedHat stance, as explained by Matthew > Garrett, is to obtain a MS certificate covering x86 and presumably ARM > kernels from Fedora, but this doesn't help respins and mods and even > custom kernels---more likely on ARM because of the its relative newness > and faster pace of development. > > People pointed out that MS hardware requirements for ARM don't have > anwhere near the market coverage/importance as in the x86 sector, so > they argue that it's OK to ignore the issue. Indeed, currently majority > of ARM hardware just doesn't care about MS, but Secure Boot is a > reflection of the industry trend seeking more security (*) so it's > conceivable that more digital signing is in ARM's future, too. > > So, what is the current thinking? What's to decide? There are no ARM machines where getting Fedora signed by someone else would improve our ability to boot, so why would we bother getting someone else to sign Fedora on ARM? If there are ARM machines where UEFI and Secure Boot are available, we're going to have tools to do your own trust database management anyway, so why would supporting them be any different from doing the same on x86? - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM and SecureBoot
On Thu, Jun 7, 2012 at 6:14 PM, Przemek Klosowski wrote: > What is Fedora ARM planning to do about the upcoming Microsoft hardware > certification spec requiring Secure Boot? By the spec, there must be a way > to disable it on x86, but on ARM they expressly prohibit turning it off. I > guess the current Fedora/RedHat stance, as explained by Matthew Garrett, is > to obtain a MS certificate covering x86 and presumably ARM kernels from > Fedora, but this doesn't help respins and mods and even custom > kernels---more likely on ARM because of the its relative newness and faster > pace of development. > > People pointed out that MS hardware requirements for ARM don't have anwhere > near the market coverage/importance as in the x86 sector, so they argue that > it's OK to ignore the issue. Indeed, currently majority of ARM hardware just > doesn't care about MS, but Secure Boot is a reflection of the industry trend > seeking more security (*) so it's conceivable that more digital signing is > in ARM's future, too. > > So, what is the current thinking? The current thinking is wait and see. MS is not a leader in the market and the route that most vendors are going in the non MS ARM market is to allow users to disable the security. From the phone perspective where it might be a carrier requirement it's not a market we're even looking at and it's very hard to tell because it's very early in the MS section of the game anyway. Also at the moment there's lots of very usable HW which isn't a problem. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM and SecureBoot
Once upon a time, Przemek Klosowski said: > What is Fedora ARM planning to do about the upcoming Microsoft hardware > certification spec requiring Secure Boot? By the spec, there must be a > way to disable it on x86, but on ARM they expressly prohibit turning it > off. I guess the current Fedora/RedHat stance, as explained by Matthew > Garrett, is to obtain a MS certificate covering x86 and presumably ARM > kernels from Fedora No, if you read what was said, they are specifically _not_ going to cover ARM, because that would be attempting to put Fedora on a platform that would not allow custom kernel and such. Don't support the locked down platform; the answer to "Fedora on ARM" is "don't buy a Win8 ARM system and expect to run Fedora". -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM and SecureBoot
On Thu, Jun 07, 2012 at 01:14:57PM -0400, Przemek Klosowski wrote: > What is Fedora ARM planning to do about the upcoming Microsoft > hardware certification spec requiring Secure Boot? By the spec, > there must be a way to disable it on x86, but on ARM they expressly > prohibit turning it off. I guess the current Fedora/RedHat stance, > as explained by Matthew Garrett, is to obtain a MS certificate > covering x86 and presumably ARM kernels from Fedora, but this > doesn't help respins and mods and even custom kernels---more likely > on ARM because of the its relative newness and faster pace of > development. I (personally) have no desire to support scenarios where it's impossible for the user to install their own keys, so I have no intention of working on this. It's technically possible, but I think it's incompatible with Fedora's goals. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: System problems
On 06/07/2012 01:25 PM, Richard Vickery wrote: > since the upgrade to 17, I've been experiencing system freezes on frequent > occasions when getting up from the > computer. The term "frequent" used in this context has a different meaning > from "constantly"; there are many moments > when I can get up to accomplish other tasks, and come back to a usable > computer without rebooting, but there seem to > be as many times when coming back to a system that is using all the resources > to complete some task and not giving me > access for at least 5 minutes. Most of the time I end up rebooting after > waiting for 5 minutes. This is a much > different experience from the experience up to F16. I may be operating under > the influences left by the kernel panics > during the testing phase. > > Might try testing the Live CD to see if it happens there as well. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM and SecureBoot
On Thu, Jun 7, 2012 at 7:14 PM, Przemek Klosowski wrote: > What is Fedora ARM planning to do about the upcoming Microsoft hardware > certification spec requiring Secure Boot? By the spec, there must be a way > to disable it on x86, but on ARM they expressly prohibit turning it off. I > guess the current Fedora/RedHat stance, as explained by Matthew Garrett, is > to obtain a MS certificate covering x86 and presumably ARM kernels from That's incorrect. The plan is to support secure boot only on x86. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Error-0.17018.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Error: 1137a7bbb94c9508a2268c467583207f Error-0.17018.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: *countable infinities only
Le Ven 1 juin 2012 18:38, Gerry Reno a écrit : > How are you going to dual-boot: > Windows-8 and Windows-7 > Windows-8 and Windows-XP > Windows-8 and Windows 2008 Server > > Windows-8 and Fedora 16 > Windows-8 and Fedora 17 > Windows-8 and Fedora 18 vmware is going to make a killing selling a 'firmware' hypervisor that lets its customers run whatever they want without bios restrictions (and if you think MS can afford not to boot on vmware, you've not seen the inroads vmware made in the past years with MS customers) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Le Sam 2 juin 2012 14:10, Richard W.M. Jones a écrit : > On Fri, Jun 01, 2012 at 12:48:55PM -0400, Gerry Reno wrote: >> We are all, Microsoft included, headed for signature-HELL. >> >> This is going to gum up the entire x86 hardware ecosystem to such a >> point and Microsoft will rue the day they ever dreamt up this >> nonsense. > > This. > > Microsoft also forgets its own recent history. Blindly trusting > signed ActiveX controls, instead of confining web content. Actually, it forgets flame was signed with its own certificates Guess what will happen the day one of the MS key leaks and they will have to choose between applying their own mechanism and not breaking all their customers with legitimate deployments signed with the compromised key ? PCs and servers (esp business side) are not game consoles with limited shelf life with owners that blindly apply the latest firmware on release date -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MALLOC_PERTURB_: everyone should set this envvar
Jim Meyering (j...@meyering.net) said: > I posted about MALLOC_PERTURB_ about a year ago, > > http://thread.gmane.org/gmane.linux.redhat.fedora.devel/132690 > > but it is clear that not everyone is setting the variable, so for those > who didn't take the time last year, or who are new to the subject, > do yourself a favor and set MALLOC_PERTURB_ to a value in 1..255 > everywhere. See the 'debugmode' package. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora kernel IRC meeting 6-8-2012 canceled
We're canceling tomorrow's IRC meeting. There will be a couple of people that will be unable to attend and there aren't a lot of items to discuss. As always, if you have questions please feel free to email the kernel list and we'll reply as soon as we can. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
System problems
since the upgrade to 17, I've been experiencing system freezes on frequent occasions when getting up from the computer. The term "frequent" used in this context has a different meaning from "constantly"; there are many moments when I can get up to accomplish other tasks, and come back to a usable computer without rebooting, but there seem to be as many times when coming back to a system that is using all the resources to complete some task and not giving me access for at least 5 minutes. Most of the time I end up rebooting after waiting for 5 minutes. This is a much different experience from the experience up to F16. I may be operating under the influences left by the kernel panics during the testing phase. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Laptop screen stuck on very low brightness
After I upgraded to Fedora 17 my laptop screen is stuck on a very low brightness setting, which makes it very hard to read. It's OK during POST, Grub and early Linux initialization, but goes dim before I'm prompted for the disk encryption passphrase. After that I can't turn the brightness back up. Which package should I report this against? Linux? X? Plymouth? Or something else? 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: Fedora ARM and SecureBoot
What is Fedora ARM planning to do about the upcoming Microsoft hardware certification spec requiring Secure Boot? By the spec, there must be a way to disable it on x86, but on ARM they expressly prohibit turning it off. I guess the current Fedora/RedHat stance, as explained by Matthew Garrett, is to obtain a MS certificate covering x86 and presumably ARM kernels from Fedora, but this doesn't help respins and mods and even custom kernels---more likely on ARM because of the its relative newness and faster pace of development. People pointed out that MS hardware requirements for ARM don't have anwhere near the market coverage/importance as in the x86 sector, so they argue that it's OK to ignore the issue. Indeed, currently majority of ARM hardware just doesn't care about MS, but Secure Boot is a reflection of the industry trend seeking more security (*) so it's conceivable that more digital signing is in ARM's future, too. So, what is the current thinking? (*) this is true whether one agrees with it or not, and whatever one thinks about SecureBoot technical merit. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap request for libpfm
On Thu, Jun 7, 2012 at 10:44 AM, William Cohen wrote: > Hi All, > > I am trying to clean up the papi package. The papi package currently bundles > the libpfm sources with in it. I would like to split libpfm out into a > separate package to follow the Fedora packaging guidelines. There have been > some comments on package in the bz, but need to get the libpfm package > officially reviewed: > > https://bugzilla.redhat.com/show_bug.cgi?id=804666 I'll take this if you can do python-svg: https://bugzilla.redhat.com/show_bug.cgi?id=829809 -J > I can review someone else's package for this one. > > -Will > > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swap request for libpfm
Hi All, I am trying to clean up the papi package. The papi package currently bundles the libpfm sources with in it. I would like to split libpfm out into a separate package to follow the Fedora packaging guidelines. There have been some comments on package in the bz, but need to get the libpfm package officially reviewed: https://bugzilla.redhat.com/show_bug.cgi?id=804666 I can review someone else's package for this one. -Will -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Perl-Critic] conditionalize aspell
commit 4f6102cf164f062b33efdbf8f753b42f96875a6a
Author: Marcela Mašláňová
Date: Thu Jun 7 17:32:26 2012 +0200
conditionalize aspell
perl-Perl-Critic.spec |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
---
diff --git a/perl-Perl-Critic.spec b/perl-Perl-Critic.spec
index 23fdec1..e536ba7 100644
--- a/perl-Perl-Critic.spec
+++ b/perl-Perl-Critic.spec
@@ -1,6 +1,6 @@
Name: perl-Perl-Critic
Version: 1.117
-Release: 4%{?dist}
+Release: 5%{?dist}
Summary: Critique Perl source code for best-practices
Group: Development/Libraries
License: GPL+ or Artistic
@@ -13,7 +13,9 @@ BuildRequires:perl(Module::Build)
BuildRequires: perl(Task::Weaken)
# Module requirements
+%if ! (0%{?rhel} >= 7)
BuildRequires: aspell-en
+%endif
BuildRequires: perl(B::Keywords) >= 1.05
BuildRequires: perl(Carp)
BuildRequires: perl(charnames)
@@ -79,7 +81,9 @@ BuildRequires:perl(Test::Without::Module)
# Optional/not automatically detected runtime dependencies
Requires: perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+%if ! (0%{?rhel} >= 7)
Requires: aspell
+%endif
Requires: perl(File::HomeDir)
Requires: perl(File::Which)
Requires: perl(Module::Pluggable) >= 3.1
@@ -144,6 +148,9 @@ LC_ALL=en_US ./Build %{!?perl_bootstrap:author}test
%{_mandir}/man3/Test::Perl::Critic::Policy.3pm*
%changelog
+* Thu Jun 7 2012 Marcela Mašláňová - 1.117-5
+- conditionalize aspell
+
* Tue Apr 24 2012 Petr Pisar - 1.117-4
- Do not use Test::Kwalitee on RHEL >= 7
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 828213] perl-Alien-SDL-1.434 is available
https://bugzilla.redhat.com/show_bug.cgi?id=828213 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Alien-SDL-1.434-1.fc18 Resolution|--- |RAWHIDE Last Closed||2012-06-07 11:31:25 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rawhide report: 20120607 changes
Compose started at Thu Jun 7 08:15:04 UTC 2012 Broken deps for x86_64 -- [389-admin] 389-admin-1.1.28-1.fc18.i686 requires libicuuc.so.48 389-admin-1.1.28-1.fc18.i686 requires libicui18n.so.48 389-admin-1.1.28-1.fc18.i686 requires libicudata.so.48 389-admin-1.1.28-1.fc18.x86_64 requires libicuuc.so.48()(64bit) 389-admin-1.1.28-1.fc18.x86_64 requires libicui18n.so.48()(64bit) 389-admin-1.1.28-1.fc18.x86_64 requires libicudata.so.48()(64bit) [PackageKit] PackageKit-zif-0.7.4-6.fc18.x86_64 requires libzif.so.3()(64bit) [aeolus-all] aeolus-all-0.4.0-2.fc17.noarch requires aeolus-conductor-doc = 0:0.4.0-2.fc17 aeolus-all-0.4.0-2.fc17.noarch requires aeolus-conductor-daemons = 0:0.4.0-2.fc17 [aeolus-configserver] aeolus-configserver-0.4.5-1.fc18.noarch requires ruby-nokogiri [askbot] askbot-0.7.39-1.fc17.noarch requires django-authenticator = 0:0.1.4 [axis2c] axis2c-1.6.0-4.fc17.i686 requires httpd-mmn = 0:20051115-x86-32 axis2c-1.6.0-4.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64 [boost141] boost141-graph-1.41.0-2.fc17.i686 requires libicuuc.so.48 boost141-graph-1.41.0-2.fc17.i686 requires libicui18n.so.48 boost141-graph-1.41.0-2.fc17.x86_64 requires libicuuc.so.48()(64bit) boost141-graph-1.41.0-2.fc17.x86_64 requires libicui18n.so.48()(64bit) boost141-regex-1.41.0-2.fc17.i686 requires libicuuc.so.48 boost141-regex-1.41.0-2.fc17.i686 requires libicui18n.so.48 boost141-regex-1.41.0-2.fc17.x86_64 requires libicuuc.so.48()(64bit) boost141-regex-1.41.0-2.fc17.x86_64 requires libicui18n.so.48()(64bit) [dustmite] dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires libphobos2-ldc.so()(64bit) [evolution-couchdb] evolution-couchdb-0.5.91-10.fc18.x86_64 requires libedata-cal-1.2.so.15()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libedata-book-1.2.so.13()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libecal-1.2.so.11()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libcamel-1.2.so.33()(64bit) [evolution-rss] 1:evolution-rss-0.3.91-1.fc18.x86_64 requires libedataserverui-3.0.so.1()(64bit) 1:evolution-rss-0.3.91-1.fc18.x86_64 requires libcamel-1.2.so.33()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 gcc-python2-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 gcc-python3-debug-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 gcc-python3-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 [gdb-heap] gdb-heap-0.5-8.fc17.x86_64 requires glibc(x86-64) = 0:2.15 [gnome-pilot] gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserverui-3.0.so.1()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libecal-1.2.so.11()(64bit) [gnome-python2-desktop] gnome-python2-evolution-2.32.0-9.fc17.x86_64 requires libecal-1.2.so.11()(64bit) [hekafs] hekafs-0.7-30.fc17.x86_64 requires glusterfs = 0:3.2.6 [inkscape] inkscape-0.48.2-5.fc17.x86_64 requires libpoppler.so.19()(64bit) inkscape-view-0.48.2-5.fc17.x86_64 requires libpoppler.so.19()(64bit) [mail-notification] mail-notification-evolution-plugin-5.4-56.fc18.x86_64 requires libcamel-1.2.so.34()(64bit) [matreshka] matreshka-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnarl-4.6.so matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnarl-4.6.so()(64bit) matreshka-sql-core-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-core-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-sql-postgresql-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-postgresql-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-sql-sqlite-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-sqlite-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) [mod_auth_pam] mod_auth_pam-1.1.1-11.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64 [mod_nss] mod_nss-1.0.8-16.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64 [mod_pubcookie] mod_pubcookie-3.3.4a-7.fc18.x86_64 requires httpd-mmn = 0:20051115-x86-64 [mod_scgi] mod_scgi-1.13-5.fc15.x86_64 requires httpd-mmn = 0:20051115 [mod_selinux] mod_selinux-2.2.2454-5.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64 [natus] libnatus-V8-0.1.5-2.fc15.x86_64 requires libv8-3.0.0.1.so()(64bit) [nip2] nip2-7.28.1-1.fc18.x86_64 requires libmatio.so.0()(64bit) [oca
Re: Update ImageMagick in Fedora 16
07.06.2012 12:52, Tadej Janež написал:
On Wed, 2012-06-06 at 21:27 +0400, Pavel Alexeev wrote:
With regard to the packages that depend on ImageMagick that you already
updated: will you revert those commits in git
I'm unsure I known how doing that correctly.
Does it enough do just:
git revert 56e05f..HEAD
or I must do something like:
git reset 56e05f
git reset --soft HEAD@{1}
git commit -m "Revert to 56e05fced"
git reset --hard
I'm not a git expert but I think you should use:
- git reset --hard HEAD^
- git push -f
to completely nuke the last commit and never see it again.
I tried doing that for my package (techne), however, it didn't work:
$ git push -f
Total 0 (delta 0), reused 0 (delta 0)
remote: error: denying non-fast-forward refs/heads/f16 (you should pull
first)
To ssh://ta...@pkgs.fedoraproject.org/techne
! [remote rejected] f16 -> f16 (non-fast-forward)
error: failed to push some refs to
'ssh://ta...@pkgs.fedoraproject.org/techne'
Am I doing something wrong here?
and delete the
corresponding builds in koji?
Do you mean koji untag-pkg or something other? Could you please
provide link on such procedure description?
I couldn't find a procedure description for deleting unwanted builds in
koji. Since this "purging issue" is clearly above our heads, the
sensible thing would be to ask for help of those who have more
experience handling these issues.
Maybe file a ticket at https://fedorahosted.org/rel-eng/report for the
Release Engineering team and ask them how to handle the issue.
Is it problem just unpush update and leave other tings as is? In case
you need build and update it in the future you just make such changes
(including clear changelog if you are willing) and again bump release.
Do you think there may be problems with it?
As we so speak there it shouldn't happened for most of packages in
stable branch at all.
Regards,
Tadej
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
FYI: ocaml 4.00.0 beta going into Rawhide
I'm going to try to get OCaml 4.00.0 beta 2 into Rawhide today. https://sympa.inria.fr/sympa/arc/caml-list/2012-06/msg00030.html http://caml.inria.fr/pub/distrib/ocaml-4.00/ It's supposed to be compatible. I will rebuild as many OCaml packages as I can over the next few days. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grive open source client for google drive
> For example if you configure empathy you *will* use it regardless if you > want it or not which makes one wonder how much of Gnome is truly > integrated with that stuff. You will use what? How will Empathy or any other GNOME component suddenly start using it (not sure what "it" is) if you have not explicitly given permission? > Fortunately pidgin exist and I use it =) And how is Pidgin different in this regard? > To give you an example of how much big pile of mess these online > accounts have come to be, now after my mobile phone upgrade to IOS 4.0.3 Irrelevant. Last time I checked, we don't ship IOS. Happy hacking, Debarshi -- K&R is like the Bible. The fervent read it from end to end, the religious keep a copy. -- Arjun Shankar pgpDxl6cJwq6n.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
VNC not eligible for active session ACLs. [was: [Bug 820675] startx does not work with systemd-logind]
Devel Mailling List may also help me Forwarded Message On Qua, 2012-06-06 at 18:55 +0200, Kevin Kofler wrote: > On Wednesday 06 June 2012, you wrote: > > I see, that we got this active=no (or =FALSE) problem with other cases > > like my remote server, where I need to work with vnc . > > VNC has always been considered a remote session and thus not eligible for > active session ACLs. See e.g.: > https://bugzilla.redhat.com/show_bug.cgi?id=711719 > (where the bug isn't really that ACLs aren't given out, but that the printer- > applet reacts to it with an uncaught Python exception). Hi, many thanks for your reply ! , Well how put my vnc with active ACLs ? I need it . ( I have root on machine :) ) x11vnc or x0vncserver also doesn't have active ACLs ? I think, I try it without success. which is strange since I have a desktop on console that I can access physically. But I will try it again to confirm (since I'm near to them now). Or other solution to work remotely on my server, with graphics. Others references : my comment https://bugzilla.redhat.com/show_bug.cgi?id=638344#c16 I admit is not completely related (again) with the bug itself . https://bugzilla.redhat.com/show_bug.cgi?id=638344 https://bugzilla.redhat.com/show_bug.cgi?id=573499 https://bugzilla.redhat.com/show_bug.cgi?id=546640 Thanks and best regards, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild
On Tue, Jun 5, 2012 at 11:30 AM, Adam Jackson wrote:
> I think we can also take this to mean that an explicit:
>
> Requires: udev
>
> is now redundant? In which case the following (F17) packages can be cleaned
> up:
>
> % repoquery --disablerepo=* --enablerepo=fedora --qf=%{sourcerpm}
> --whatrequires udev | sort -u
> iwl1000-firmware-39.31.5.1-2.fc17.src.rpm
> iwl100-firmware-39.31.5.1-3.fc17.src.rpm
> iwl5150-firmware-8.24.2.2-3.fc17.src.rpm
> iwl6000-firmware-9.221.4.1-3.fc17.src.rpm
> iwl6000g2a-firmware-17.168.5.3-2.fc17.src.rpm
> iwl6000g2b-firmware-17.168.5.2-2.fc17.src.rpm
> iwl6050-firmware-41.28.5.1-4.fc17.src.rpm
Those are actually going to be retired as soon as linville gets around
to it. They've been sucked into linux-firmware.
> linux-firmware-20120206-0.3.git06c8f81.fc17.src.rpm
Fixed.
josh
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grive open source client for google drive
On 06/07/2012 12:24 PM, drago01 wrote: You are not forced to use it though;) No shit captain obvious =) Not using it does not mean it's not doing something and potentially leaking/gathering what ever info from your desktop and your desktop activates to what ever "online" server/account it communicates with. For example if you configure empathy you *will* use it regardless if you want it or not which makes one wonder how much of Gnome is truly integrated with that stuff. Fortunately pidgin exist and I use it =) To give you an example of how much big pile of mess these online accounts have come to be, now after my mobile phone upgrade to IOS 4.0.3 I have roughly 1000 contacts many which are duplicates contact information of the same person since he potentially have multiple online accounts ( fb,g+ etc ) so I'm having hard time actually finding a) the right account b) sending him a freaking sms text message. Heck I the other day I was chatting on g+ with John Dulaney he turned on g+ video chat and instead of it going to my computer ( which I was chatting to him through ) it went to my mobile phone instead wtf! Well the good news ( beside the point it went to the wrong device ) is that g+ video chat works splendidly from the states to Iceland... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grive open source client for google drive
2012/6/7 Adrian Alves : > On Thu, Jun 7, 2012 at 8:48 AM, Vascom wrote: >> >> They can check this Package Review Request >> https://bugzilla.redhat.com/show_bug.cgi?id=829713 >> >> 2012/6/7 Stephen Gallagher : >> > On Thu, 2012-05-24 at 11:51 -0300, Adrian Alves wrote: >> >> >> >> >> >> Am about to package this: >> >> grive open source client for google drive >> >> http://match065.github.com/grive/ >> >> >> >> >> >> Just wondering in case if somebody else is working on it >> >> >> > >> > You may want to check with the Fedora Packaging Committee on whether >> > this is an acceptable project for Fedora. I seem to recall some concern >> > that packages that are only useful for communication with a non-Free >> > source may not be acceptable for inclusion. >> > >> > -- >> > devel mailing list >> > devel@lists.fedoraproject.org >> > https://admin.fedoraproject.org/mailman/listinfo/devel >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel > > We can work it out together an we can co maintain this pkg if u want i been > building an spec before of urs but we can merge our work if u want course > and i can review it It will be good. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Thu, Jun 7, 2012 at 4:33 AM, Benny Amorsen wrote: > Josh Boyer writes: > >> The magic was quite specified. You rebuild the initramfs with the >> convertfs module included, and pass the approriate arguments on boot. >> There's a wiki page covering exactly that. > > Yes, the invokation is specified in detail. There just isn't any > documentation of what it actually does, to enable you to e.g. do it by > hand or have a guess at fixing it if it goes wrong. That is just too > risky for me. It moves all the content from /lib and /bin to /usr/lib and /usr/bin respectively and then makes /lib and /bin symlinks. The wiki page actually tells you this. Also, this is Open Source software, not magic. You can always read the code, which is ultimately the best documentation if you want to know _exactly_ what it does. > You cannot upgrade from Fedora 16 to Fedora 17 in an OpenVZ guest, > because those don't run an initrd at all (or even a separate kernel). Yes you can. You just have to be willing to figure it out. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grive open source client for google drive
On Thu, Jun 7, 2012 at 8:48 AM, Vascom wrote: > They can check this Package Review Request > https://bugzilla.redhat.com/show_bug.cgi?id=829713 > > 2012/6/7 Stephen Gallagher : > > On Thu, 2012-05-24 at 11:51 -0300, Adrian Alves wrote: > >> > >> > >> Am about to package this: > >> grive open source client for google drive > >> http://match065.github.com/grive/ > >> > >> > >> Just wondering in case if somebody else is working on it > >> > > > > You may want to check with the Fedora Packaging Committee on whether > > this is an acceptable project for Fedora. I seem to recall some concern > > that packages that are only useful for communication with a non-Free > > source may not be acceptable for inclusion. > > > > -- > > devel mailing list > > devel@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/devel > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel We can work it out together an we can co maintain this pkg if u want i been building an spec before of urs but we can merge our work if u want course and i can review it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grive open source client for google drive
On Thu, Jun 7, 2012 at 2:13 PM, "Jóhann B. Guðmundsson" wrote: > On 06/07/2012 11:44 AM, Stephen Gallagher wrote: > > You may want to check with the Fedora Packaging Committee on whether > this is an acceptable project for Fedora. I seem to recall some concern > that packages that are only useful for communication with a non-Free > source may not be acceptable for inclusion. > > > Doubt that is true otherwise that libsocialweb and relevant stuff that came > with Gnome 3.x should be ripped out from the distribution. > > I personally would be happy man if i could simply uninstall it which was not > the case last time I checked =) You are not forced to use it though ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grive open source client for google drive
On 06/07/2012 11:44 AM, Stephen Gallagher wrote: You may want to check with the Fedora Packaging Committee on whether this is an acceptable project for Fedora. I seem to recall some concern that packages that are only useful for communication with a non-Free source may not be acceptable for inclusion. Doubt that is true otherwise that libsocialweb and relevant stuff that came with Gnome 3.x should be ripped out from the distribution. I personally would be happy man if i could simply uninstall it which was not the case last time I checked =) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grive open source client for google drive
On Thu, Jun 7, 2012 at 1:44 PM, Stephen Gallagher wrote: > On Thu, 2012-05-24 at 11:51 -0300, Adrian Alves wrote: >> >> >> Am about to package this: >> grive open source client for google drive >> http://match065.github.com/grive/ >> >> >> Just wondering in case if somebody else is working on it >> > > You may want to check with the Fedora Packaging Committee on whether > this is an acceptable project for Fedora. I seem to recall some concern > that packages that are only useful for communication with a non-Free > source may not be acceptable for inclusion. The software is free, whether the services it access are free or not is not a reason to block it (and never have been). We have other packages that can access google services, or twitter or So as long as the software is free and not patent encumbered I don't see a reason to block it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grive open source client for google drive
They can check this Package Review Request https://bugzilla.redhat.com/show_bug.cgi?id=829713 2012/6/7 Stephen Gallagher : > On Thu, 2012-05-24 at 11:51 -0300, Adrian Alves wrote: >> >> >> Am about to package this: >> grive open source client for google drive >> http://match065.github.com/grive/ >> >> >> Just wondering in case if somebody else is working on it >> > > You may want to check with the Fedora Packaging Committee on whether > this is an acceptable project for Fedora. I seem to recall some concern > that packages that are only useful for communication with a non-Free > source may not be acceptable for inclusion. > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
grive - An open source Linux client for Google Drive
Hi, I need a sponsor to include this package in Fedora. https://bugzilla.redhat.com/show_bug.cgi?id=829713 My Self introduction http://lists.fedoraproject.org/pipermail/devel/2012-June/168330.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grive open source client for google drive
On Thu, 2012-05-24 at 11:51 -0300, Adrian Alves wrote: > > > Am about to package this: > grive open source client for google drive > http://match065.github.com/grive/ > > > Just wondering in case if somebody else is working on it > You may want to check with the Fedora Packaging Committee on whether this is an acceptable project for Fedora. I seem to recall some concern that packages that are only useful for communication with a non-Free source may not be acceptable for inclusion. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self introduction: Vasiliy N. Glazov
My name is Vasiliy N. Glazov My nickname Vascom or vascom City, Country: Moscow, Russian Federation. Profession status: Engeneer. Company: Javad GNSS. I want be maintaner of packages for Fedora. I already have few review requests for packages https://bugzilla.redhat.com/show_bug.cgi?id=822329 https://bugzilla.redhat.com/show_bug.cgi?id=822328 https://bugzilla.redhat.com/show_bug.cgi?id=822327 https://bugzilla.redhat.com/show_bug.cgi?id=822049 https://bugzilla.redhat.com/show_bug.cgi?id=822046 https://bugzilla.redhat.com/show_bug.cgi?id=821406 https://bugzilla.redhat.com/show_bug.cgi?id=821404 https://bugzilla.redhat.com/show_bug.cgi?id=821423 and I need a sponsor for them. I have more packages in RussianFedora Project http://koji.russianfedora.ru/koji/userinfo?userID=vascom Also I make package for grive (http://lists.fedoraproject.org/pipermail/devel/2012-June/168319.html) want be maintainer of it too. I can program on bash, some C/C++, can make RPM packages. My FAS account vascom https://fedoraproject.org/wiki/User:Vascom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
On Wed, 2012-06-06 at 21:27 +0400, Pavel Alexeev wrote:
> >
> > With regard to the packages that depend on ImageMagick that you already
> > updated: will you revert those commits in git
> I'm unsure I known how doing that correctly.
> Does it enough do just:
> git revert 56e05f..HEAD
>
> or I must do something like:
> git reset 56e05f
> git reset --soft HEAD@{1}
> git commit -m "Revert to 56e05fced"
> git reset --hard
I'm not a git expert but I think you should use:
- git reset --hard HEAD^
- git push -f
to completely nuke the last commit and never see it again.
I tried doing that for my package (techne), however, it didn't work:
$ git push -f
Total 0 (delta 0), reused 0 (delta 0)
remote: error: denying non-fast-forward refs/heads/f16 (you should pull
first)
To ssh://ta...@pkgs.fedoraproject.org/techne
! [remote rejected] f16 -> f16 (non-fast-forward)
error: failed to push some refs to
'ssh://ta...@pkgs.fedoraproject.org/techne'
Am I doing something wrong here?
> > and delete the
> > corresponding builds in koji?
> Do you mean koji untag-pkg or something other? Could you please
> provide link on such procedure description?
I couldn't find a procedure description for deleting unwanted builds in
koji. Since this "purging issue" is clearly above our heads, the
sensible thing would be to ask for help of those who have more
experience handling these issues.
Maybe file a ticket at https://fedorahosted.org/rel-eng/report for the
Release Engineering team and ask them how to handle the issue.
Regards,
Tadej
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On 06/07/2012 10:33 AM, Benny Amorsen wrote: Yes, the invokation is specified in detail. There just isn't any documentation of what it actually does, I thought what convertfs does was quite clear. If you need to know the details how it does that, take a look at /usr/lib/dracut/modules.d/30convertfs/convertfs.sh Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
Josh Boyer writes: > The magic was quite specified. You rebuild the initramfs with the > convertfs module included, and pass the approriate arguments on boot. > There's a wiki page covering exactly that. Yes, the invokation is specified in detail. There just isn't any documentation of what it actually does, to enable you to e.g. do it by hand or have a guess at fixing it if it goes wrong. That is just too risky for me. You cannot upgrade from Fedora 16 to Fedora 17 in an OpenVZ guest, because those don't run an initrd at all (or even a separate kernel). /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: glusterfs rename
On 06/07/2012 01:04 PM, Rahul Sundaram wrote: On 06/07/2012 05:29 AM, Ric Wheeler wrote: Do we really need to create a feature page for that and follow the approval process? Seems too heavy weight to me for effectively rebasing a package... It is certainly not required. Feature process is a marketing and coordination tool. Not a bureaucracy to rubber stamp merely a rebase. Use it only where it makes sense. In this case, you only need it if you want to advertise this change heavily. Rahul Thanks - I think that it probably does make sense to highlight the updates in a Fedora Feature page going into gluster more generally, this could be one item of several that we want to highlight when we get to the newer community version Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild
On 06/06/2012 04:25 PM, Michal Schmidt wrote: We will split out a systemd-libs subpackage to be more multilib-friendly. Done in systemd-185-4.gita2368a3.fc18. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
On 06/07/2012 03:59 AM, Sérgio Basto wrote:
On Qua, 2012-06-06 at 14:03 -0400, Tom Callaway wrote:
https://fedoraproject.org/wiki/Packaging:Systemd
BTW ,
we don't have an %{_initrddir} for systemd ?
There's %{_unitdir}
Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
