Re: *countable infinities only
On 06/02/2012 11:32 PM, Orcan Ogetbil wrote: On Sat, Jun 2, 2012 at 1:53 PM, Rahul Sundaram wrote: You are responsible as a package maintainer for bugs against the package. If you don't want to deal with it, give up the package or find a co-maintainer who will deal with such issues. When you work within a community, it is a project wide decision. Not just personal preference on which bugs you can reasonably ignore. In which part of the agreement [1] that I signed is this stated? I am sure you are aware of the difference between policies and a legal agreement. You cannot seriously believe that you can neglect bugs deliberately ignoring clearly documented and frankly common sense responsibilities. Feel free to try if you must. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/03/2012 12:12 AM, Orcan Ogetbil wrote: At the same time I don't want to be obliged to support something I don't want to. There are many more important things to deal with in the distribution than a stupid secure boot feature. Let's narrow it down. Can you give a clear and specific example of a situation where you believe one of the packages you maintain will be affected by this feature? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/03/2012 07:05 AM, Steve Clark wrote: But don't you think that if they are determined enough to go to bugzilla and make an entry they are smart enough to turn off secure boot? I guess my feeling is that people that have the where withall to attempt to load another OS on their Windows box won't be afraid to disable secure boot especially if it is explained to them why they need to. I am not sure you can validate your feelings by the people who you talk to. You got to be aware that there a number of users who have installed Fedora but never have posted in bugzilla at all and dont equate interest and ability to fiddle BIOS settings with smartness. Just because people have the ability to install Fedora and post in a forum doesn't mean that you can reliably assume that they are willing to fiddle with BIOS settings on their system or they would prefer that over a installation that just works. We have worked for years to make Fedora more usable and be easily installable for users who are transitioning from Windows. One could argue that the regression in usability is not as important as the loss of freedom in this specific instance but it is undeniable that it is a usability regression that would affect a number of users. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Sun, Jun 3, 2012 at 2:14 AM, Rahul Sundaram wrote: On 06/03/2012 12:12 AM, Orcan Ogetbil wrote: At the same time I don't want to be obliged to support something I don't want to. There are many more important things to deal with in the distribution than a stupid secure boot feature. Let's narrow it down. Can you give a clear and specific example of a situation where you believe one of the packages you maintain will be affected by this feature? No. The I in the above sentence(s) is not meant to be restricted to my own self. I tried to use I as a placeholder for _any_ packager's own will. Sorry if this was not clear. As long as the secure boot is detectable in runtime, the maintainer (I) will have the choice to support or not support users using or not using this feature. This is the freedom I was afraid to lose. But I learned that this is not the case. So no further questions. Best, Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fwd: Review swap requests for Lars Wirzenius' new Obnam backup tool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Accidentally sent the earlier message to the old Red Hat-hosted devel list. - Original Message Subject: Review swap requests for Lars Wirzenius' new Obnam backup tool Date: Sun, 03 Jun 2012 13:45:12 +0700 From: Michel Alexandre Salim sali...@fedoraproject.org Organization: Fedora Project To: Fedora Python list python-de...@lists.fedoraproject.org, fedora-devel list fedora-devel-l...@redhat.com - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I've just packaged Obnam, Lars Wirzenius' new B-tree-based backup tool (think btrfs for backup), whose 1.0 release was recently announced on Linux Weekly News on Friday, June 1st: http://lwn.net/Articles/499845/ It consists of 8 packages, and there are two more (seivot, for benchmarking, and summain, for generating diff-able file manifests) that I have not packaged yet, all eight are in Bugzilla, in descending order (packages at the bottom are depended on by the ones on top) obnam - An easy, secure backup program https://bugzilla.redhat.com/show_bug.cgi?id=827810 genbackupdata - A program to generate test data for testing backup software https://bugzilla.redhat.com/show_bug.cgi?id=827809 python-larch - Python B-tree library https://bugzilla.redhat.com/show_bug.cgi?id=827808 python-tracing - Python debug logging helper https://bugzilla.redhat.com/show_bug.cgi?id=827807 cmdtest - Black-box testing for Unix command line tools https://bugzilla.redhat.com/show_bug.cgi?id=827806 python-ttystatus - Progress and status updates on terminals for Python https://bugzilla.redhat.com/show_bug.cgi?id=827805 python-cliapp - Python framework for Unix command line programs https://bugzilla.redhat.com/show_bug.cgi?id=827804 python-coverage-test-runner - Python module for enforcing code coverage completeness https://bugzilla.redhat.com/show_bug.cgi?id=827803 I've so far tested it for local unencrypted backups -- there's a problem with Obnam's locking mechanism I've emailed Lars about, so some related test cases are disabled, and it seems that it also affects going GPG-encrypted backups. There's a Yum repository for F-17 x86_64 for your testing convenience: http://hircus.multics.org/yum-repos/obnam.repo http://hircus.multics.org/yum-repos/obnam/ As usual, please reply to the list with which package you want to review and if you want to swap with any of your own review requests. Thanks, - - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPywf4AAoJEEr1VKujapN61HcH/Rnxed1S0n+ZOh6nTusp2Iyl 3WSZEnCUxRGEInrHRxjnnHZKz1fgGQG96lxKPAosVrO8Ll+oHldEWvuxchgg5QYt sy7yFaFImQ78Z858bdS2AyywKp3KFcingATFNHukXlwhMSYTxN74u4bgAG5uYJL0 DStqtVzExsQckJW3fAd7PvE7TWVy3ytL/O+6oRijlHGH+bpiQjrb3N6Ht007klT+ IfMz9yMcSyXtEEpUAH1jWyiZ3ZYdHTyp3GsvJr4O4hv1yMuD+Mt1uHtDMyxdiPyt BzzksfLPb6+SLYQhcXVJPgXL2nkDOxiUxc6CsF61Q7n6qTa7yRMv03qLpD6svpo= =Btyg - -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPyxQAAAoJEEr1VKujapN6ydgH/jXBKnIAHDZxbVLha9eKbiQr 1JjN/3ROlCKmcVwQP1Qc2uHg9vZPQ+9sSothIROdvzoeaP30gwaIvksZaKOmReZF TcWM+NWONoDPkOevr52bRyjAZ69o7fWiIaRd5ok1sYKtiLUrHtmqPl11fBEB4Y3p 1Q/JUgHLjIr/SskSlhjqiyC41G3k9HDDilP3XSAssf0tDR+FyLOrFmLyX/OYUgf5 hle35Gw+jDllDrn3ZiTFpXtwGLcJM0Lppa+lDILovoepIOhJyTe/IgPAPzvdob10 mwi4G7TJBbx9W/lZRrkcgtPZThonag+Ecj7TOgrhS2j9fZ2RYDePkPNI+3cfOfc= =VoTX -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap requests for Lars Wirzenius' new Obnam backup tool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/03/2012 01:45 PM, Michel Alexandre Salim wrote: Hi all, I've just packaged Obnam, Lars Wirzenius' new B-tree-based backup tool (think btrfs for backup), whose 1.0 release was recently announced on Linux Weekly News on Friday, June 1st: http://lwn.net/Articles/499845/ It consists of 8 packages, and there are two more (seivot, for benchmarking, and summain, for generating diff-able file manifests) that I have not packaged yet, all eight are in Bugzilla, in descending order (packages at the bottom are depended on by the ones on top) I've now also packaged the remaining two auxiliary packages: seivot - Benchmarking tool for backup programs https://bugzilla.redhat.com/show_bug.cgi?id=827818 summain - File manifest generator https://bugzilla.redhat.com/show_bug.cgi?id=827819 PS please reply to this rather than the original message; I accidentally used the old fedora-devel email address. As usual, please reply to the list with which package you want to review and if you want to swap with any of your own review requests. Thanks, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPyxSbAAoJEEr1VKujapN6YZAH/izJNSfHS6SnJgAsMr5w9kMY iBJiyh9PGxJgljaPOE4/3fPPzAHduD8crk3hhYJkHEKki0nzyza+yb7/jorFohKe mpyTYaSrJ6E2zntBfa7zgm69nHT6TNTsEh1KlkRG4HhGoNSJZ3eUoOdqrc5szO3x /a1uEIdzxQ+QC0jIQzAWZ4Uh9nC8UJVMBybZgPUa2YRJXkTtGW3+NUzGThX8K04M 9MQk9nnBKGq6spniBPs8w9idp1UNJEa430tB7NySuHPxsgkQY1hP4tMh1bT4/+EL /4QCO5KAKaPrj9lsUYot7ui+YVQQyl6vn17+Ku9u6WizlcjBX70nX1bE5ClBfxM= =lX3d -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Two more Python packages for review swaps: python-qrcode and gnuhealth
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Two more Python packages, if anyone is interested in swapping: https://bugzilla.redhat.com/show_bug.cgi?id=827722 - for python-qrcode, a dependency for GNU Health https://bugzilla.redhat.com/show_bug.cgi?id=827723 - GNU Health Feel free to take them up -- and I'll do my best to help out with package reviews, just let me know what needs reviewing. Thanks, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPyxaJAAoJEEr1VKujapN6Rn4H/0Jgdj2jAMGImhgeb0cofRMD BCMszsMeG2JGTIZNocj1UMhq/HGHNfzqgepPrBzfyXoC7NRf0aUZFYocoIEgLXPZ BmtDLo3udZ5iBuZ1+epkMZ2oDRtBH1ZqdZ6NbZXbg9PraQRh6s1ctOKT32fIEeYb 2GEmlB2VL4Rgtb01PbP6p4Cmu7K9mYKPTB4d0Kl02xcYQzr7tdifW3loh9Kcg5wk UcZc/Mdms+6ZImQK8EBtwd/iZqc3O92mwDUhtf2coiDKzUWJludI+lLO8PyLGLgf skiwyIXLoCR/QeUb49wX52OC02qWtVT0MK5rcba67KNbllG2ZE4bwq+NIvWlHiY= =+gcR -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
fre 2012-06-01 klockan 09:48 -0700 skrev Adam Williamson: Frankly, I'd prefer it if we more strongly recommended that people do DVD/netinst upgrades. That path is less complex than preupgrade and involves fewer moving parts; it's easier to test and easier to fix and more likely, in general, to be working at any given point. Please no. Once Fedora is installed it really ought to be able to upgrade itself without needing new boot media twice a year, that's just not user friendly. It's also much safer to first download everything and then start the RPM transaction. (IIUC a normal Anaconda upgrade will download packages during the upgrade.) /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redeclipse: packaging symlinks and directory ownership
On Mon, 2012-05-28 at 16:00 -0700, Toshio Kuratomi wrote:
On Mon, May 28, 2012 at 11:25:43PM +0200, Martin Erik Werner wrote:
On Mon, 2012-05-28 at 19:31 +0200, Martin Erik Werner wrote:
Hello,
I have a couple of packaging questions for a new package, the FPS game
redeclipse[0], which are currently in testing[1].
1.
I have three resulting binary packages {redeclipse, redeclipse-server,
redeclipse-data} where redeclipse depends on redeclipse-data as the only
inter-dependency. (Splitting -data into a separate source package is a
future todo item...)
Currently all packages place files in %{_libexecdir}/%{name}/ (client
binary, server binary, and a symlink to the data dir).
In this case, should only the -server and -data packages own this
directory, or would it be more appropriate if all three owned it?
I would lean towards only the -server and -data package owning this due to
the client depending on -data.
2.
I was thinking of moving the symlink from the -data package to the
client (redeclipse) package, which would mean that unless the -data
dependency is installed, there would be a broken symlink, is this
something that's acceptable? Or need symlinks be unbroken within a
single package regardless of dependencies?
As long as the dependency from -client to -data exist, this should be fine.
3.
redeclipse is currently pushed as an update to testing[1] (not in stable
yet), and this version includes the unowned directory
%{_libexecdir}/%{name}/ (which I discovered recently).
What would be my course of action with regards to the f17 update? Should
I abort it and push a new one (and go through the review process?), or
should I let it go and fix this in a subsequent update; how critical are
unowned dirs like this?
I'd abort, build a fixed version, and push that. there's no need for
a re-review for that. For the end user it shouldn't have much effect.
For how serious, here's the Packaging Guideline page that explains the
various issues it can cause:
http://fedoraproject.org/wiki/Packaging:UnownedDirectories
-Toshio
Ok, I've unpushed it, moved the symlink and repushed, thanks for the
help :)
(Now I just need to find testers :/)
--
Martin Erik Werner martinerikwer...@gmail.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Two more Python packages for review swaps: python-qrcode and gnuhealth
On Sun, 2012-06-03 at 14:47 +0700, Michel Alexandre Salim wrote: https://bugzilla.redhat.com/show_bug.cgi?id=827722 - for python-qrcode, a dependency for GNU Health Don't forget to check the bugzilla before submitting a package: https://bugzilla.redhat.com/show_bug.cgi?id=824628 Pure python QR Code generator Plus, there are comments on your spec file which you apparently did not read. Exchanged against: https://bugzilla.redhat.com/show_bug.cgi?id=821267 Review Request: R-BiocGenerics - Generic functions for Bioconductor Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Two more Python packages for review swaps: python-qrcode and gnuhealth
On Sun, 2012-06-03 at 11:48 +0200, Pierre-Yves Chibon wrote: Plus, there are comments on your spec file which you apparently did not read. I should have said, that you forgot. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
drago01 wrote: We have to make our software better then the competition being free by itself is not enough to gain market traction. Having a complicated installation procedure sure does not help this case. Our goal is freedom, not market share! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Rahul Sundaram wrote: Just because people have the ability to install Fedora and post in a forum doesn't mean that you can reliably assume that they are willing to fiddle with BIOS settings on their system or they would prefer that over a installation that just works. We have worked for years to make Fedora more usable and be easily installable for users who are transitioning from Windows. One could argue that the regression in usability is not as important as the loss of freedom in this specific instance but it is undeniable that it is a usability regression that would affect a number of users. It's a usability regression in the firmware, not our fault at all. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Gregory Maxwell wrote: Create a pre-bootloder. If secureboot is enabled only permitting this boot because it's signed with the msft key, then display the most helpful instructions WRT secureboot we can display and then halt. If secureboot is not enabled, pass control to grub. This should meet the signing requirements and it removes the opacity without locking down any of Fedora. Such a bootloader should meet whatever requirements to get signed, since if secureboot is turned on it wont boot anything at all. I'm not sure that the CA will be willing to sign something that says Secure Boot is evil and needs to be disabled. And anyway, I think there's no point in doing this, a generic boot failed or silent fallback to another OS (one of which is what the firmware is going to do) is sufficient. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Orcan Ogetbil wrote: As long as the secure boot is detectable in runtime, the maintainer (I) will have the choice to support or not support users using or not using this feature. This is the freedom I was afraid to lose. But I learned that this is not the case. Uh, it IS the case. Arbitrarily making your program fail based on some boot- related kernel flag which has nothing whatsoever to do with your software WILL be considered a bug that needs to be fixed. If Fedora as a whole decides to support Secure Boot, you will have to support it too. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Sun, Jun 3, 2012 at 12:09 PM, Kevin Kofler kevin.kof...@chello.at wrote: drago01 wrote: We have to make our software better then the competition being free by itself is not enough to gain market traction. Having a complicated installation procedure sure does not help this case. Our goal is freedom, not market share! Please don't take statements out of context. (i.e read the part that I have replied to). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Gregory Maxwell wrote: The goal you've set—Fedora working out of the box on this hardware without user fuss—can't be accomplished via technical means, except by restricting the bootloader and kernel. There is no law of nature which says that this must be your goal, however. There's at least theoretically another technical means: exploiting firmware bugs to bypass the signature requirements. Of course, it is probably not practical because there will be several different firmware implementations and because the firmware vendors will be fixing bugs which get exploited. But it is definitely possible (assuming such bugs can be found). Would it be legal? I think it would. I don't see under what law it would be illegal. Secure Boot is NOT a copy protection mechanism, so I don't see how the DMCA would apply here. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Sat, Jun 2, 2012 at 8:17 PM, Andrea Musuruane musur...@gmail.com wrote: On Tue, May 29, 2012 at 10:42 PM, Neal Becker ndbeck...@gmail.com wrote: Basically the same kind of failure as the last several times I did updates. This time f16-f17. Used preupgrade. I'd like to share with you my experience about installing Fedora 17/x86_64. It is a real PITA. No doubts about it. 6th attempt: I did a minimal install also enabling remote updates and at last I can boot Fedora 17. Now the problem is how to install a graphical desktop environment from minimal install. I googled without finding nothing really useful. As previously, any help is really appreciated. Thanks. Andrea. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Sun, Jun 03, 2012 at 01:21:55PM +0200, Andrea Musuruane wrote: On Sat, Jun 2, 2012 at 8:17 PM, Andrea Musuruane musur...@gmail.com wrote: On Tue, May 29, 2012 at 10:42 PM, Neal Becker ndbeck...@gmail.com wrote: Basically the same kind of failure as the last several times I did updates. This time f16-f17. Used preupgrade. I'd like to share with you my experience about installing Fedora 17/x86_64. It is a real PITA. No doubts about it. 6th attempt: I did a minimal install also enabling remote updates and at last I can boot Fedora 17. Now the problem is how to install a graphical desktop environment from minimal install. I googled without finding nothing really useful. As previously, any help is really appreciated. yum groupinstall GNOME Desktop Environment -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
The discussion has been very interesting, and it is probably being followed by a lot of non-Fedora developers as well. [To be honest, I first bought the pro-find-a-simple-enough-work-around-to-SecureBoot-issue arguments. But, reading through the arguments from KK, Adam and some others, I must admit I would now favour the If you want Fedora, just disable SecureBoot solution] My point is: Fedora has long been criticised for never having natively supported (https://fedoraproject.org/wiki/Forbidden_items) non-free media codecs (MP4, DivX, etc), non-free databases (Oracle, IBM DB2, etc), without speaking about basic software pieces such as Adobe Acrobat Reader, Adobe Flash, Oracle/Sun's Java JDK. And every time the argument is the same ( https://fedoraproject.org/wiki/Multimedia/MP3, https://fedoraproject.org/wiki/Flash, https://fedoraproject.org/wiki/Java ), along the lines of: Adobe's Flash plugin cannot be included in Fedora because it is not free/libre and open source software, Fedora is unable to include encoding and decoding support for the MP3 format because it requires patented technologies and the patent holder has not provided licenses that are compatible with Fedora's requirements, If it is proprietary, it cannot be included in Fedora. (Binary firmware is the only exception to this); If it is legally encumbered, it cannot be included in Fedora The official Fedora wiki barely explains ( https://fedoraproject.org/wiki/Third_party_repositories) how to install all those license-encumbered packages, so that most of the time, Fedora users have to search on the web for those procedures. Fortunately enough, a lot of blog entries explain that much better than the official Fedora wiki. Understand me: I am perfectly fine with Fedora not messing with license-encumbered packages and relying on third party repositories for that. My point is just that I do not find it consistent to then compromise our great principles in supporting SecureBoot, at least indirectly. In other terms: if Fedora users are supposed to know how to install multimedia codecs, Flash, pristine Java JDK, Google suites (Chrome, Earth, Picasa, Desktop), Oracle database clients, without explicit Fedora support(!), is it a big deal to also ask them to know how to disable SecureBoot (with explicit Fedora support)? That question is just food for thoughts. So, no need to start new flame wars :) Cheers Denis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Sun, Jun 3, 2012 at 6:26 AM, Kevin Kofler wrote: Orcan Ogetbil wrote: I am more concerned about the package maintenance level. At the package maintenance level, it does not make sense to patch against the upstream decision. It does. If upstream arbitrarily refuses to support a use case we support, that must be patched. Now I don't think Fedora should be supporting Secure Boot in the first place, but if it does, it needs to be distro-wide. You mean like pulseaudio, which is still a horrid mess after 11(?) releases? Sorry, I respectfully disagree. Best, Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/02/2012 12:31 PM, Kevin Fenzi wrote: What happens if you try and boot an unsigned image? I assume the error you get is up to the BIOS folks? So, it could be misleading, confusing, depressing or all three. It may be that people will see just Failed to secure boot and think there's something wrong with Fedora. They may not even be looking for a bios option. They may burn or download multiple media in an attempt to get it working. All kinds of possible issues... ;( To add to Matthew's reply here, depending on the vendor it'll show up in boot selection UI either as boot media that just happens to fail when you try it, or, if they do a really surprisingly good job, it won't show up at all as boot media. If they do a much different job then that, it might show up but be listed as unsupported somehow, and may tell you why. I have my doubts that you'll often see anything but the first option. On the systems I have to test with, from the UEFI shell (which likely won't ever be something you can run in SB=1 mode on a retail machine), the typical user-visible error from running an unsigned executable is file not found. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/02/2012 05:47 PM, Gregory Maxwell wrote: There is no additional security provided by the feature as so far described—only security theater. So I can't modify the kernel or bootloader, great—but the kernel wouldn't have let me do that in the first place unless it had an exploit. So I just put my rootkit inside systemd so that it executes the kernel exploit right after reboot, and the exploited kernel now silently keeps updates from being applied. You've sortof missed the point. A privilege escalation exploit, currently, can sabotage your bootloader, insert its own ahead of it, and modify the kernel to perpetually hide itself. Right now such exploits are generally bounded by selinux, which would, in most cases, stop them from performing the systemd trick that you describe. At that point it has escalated past the point where it's confined by selinux or anything else, and can do your trick and far worse. And again, there *are* bootkit exploits in the wild now. So any argument that there's no legitimate security benefit to securing the bootloader is prima facie false. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/02/2012 03:28 PM, Gregory Maxwell wrote: On Sat, Jun 2, 2012 at 12:36 PM, Matthew Garrettmj...@srcf.ucam.org wrote: Per spec the machine simply falls back to attempting to execute the next entry in the boot list. An implementation may provide some feedback that that's the case, but there's no requirement for it to do so, so it's perfectly valid for it to just fall back to booting Windows with no notification. If the issue were just the opaque and unpredictable behavior on failure this could be addressed without signing any of the distribution proper. Create a pre-bootloder. If secureboot is enabled only permitting this boot because it's signed with the msft key, then display the most helpful instructions WRT secureboot we can display and then halt. If secureboot is not enabled, pass control to grub. This should meet the signing requirements and it removes the opacity without locking down any of Fedora. Such a bootloader should meet whatever requirements to get signed, since if secureboot is turned on it wont boot anything at all. So let me get this straight. Your solution is to write a shim bootloader that differs from the one we've proposed in that instead executing the kernel, if Efi:SecureBoot is set to 1 in the firmware, it tells the user to fumble around in the firmware menus, which don't necessarily even exist, until they find the switch that tells them to disable security, to turn that and probably anything similar they find before finding the right switch off, and then to try again. And maybe you want to explain to them that the system was somehow configured wrong from the factory even though windows worked and the system manufacturer probably did have some reason for flipping the switch labeled security to the enabled position. And you want us to get that signed, and just have it not bother to boot the system. For freedom. You've just drawn the higher barrier for freedom-to-modify line at a different point in Fedora, but it's still there. But in your version it also tells the user to expose themselves to a legitimate security problem so that they're free-er to do something they could already do, if only they had the will to do it. It may also be telling them to do something they cannot, with any reasonable amount of effort, do, depending on if apple decide to ship with SB enabled and the MS keys installed in DB, since they certainly won't be shipping windows logos, and they're not too keen on bootloader menus. Do I even need to explain why I don't think this is better than our plan? -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Two more Python packages for review swaps: python-qrcode and gnuhealth
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/03/2012 04:48 PM, Pierre-Yves Chibon wrote: On Sun, 2012-06-03 at 14:47 +0700, Michel Alexandre Salim wrote: https://bugzilla.redhat.com/show_bug.cgi?id=827722 - for python-qrcode, a dependency for GNU Health Don't forget to check the bugzilla before submitting a package: https://bugzilla.redhat.com/show_bug.cgi?id=824628 Pure python QR Code generator Ah yes, thanks. I've been looking at so many software that are all not packaged yet, over the past several days, this one slipped past the radar. Plus, there are comments on your spec file which you apparently did not read. Yup. sitelib/sitearch -- heh. In fact, per Packaging:Python neither of them are actually needed outside of RHEL 5 Exchanged against: https://bugzilla.redhat.com/show_bug.cgi?id=821267 Review Request: R-BiocGenerics - Generic functions for Bioconductor Assigning to myself; will do that tomorrow. Thanks! - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPy3aZAAoJEEr1VKujapN67VYIAI06OEwfz74EMJp87m2K9Xnz 3iMF1E1HlbxqI04c59OSh53w6vVMf0FYjzVXaHV8ICc+5lSm0PR5MIBNjI0kTrZQ mVXgpitumWBjpd48QOy3RkP1C9l+f0FfrDMBt6oE6iFdvdprZ/iG9YXvvJBNa7di 4gpmTUzT01rZkomvZBrXXz2CcMPZZH1wNXGb5aDIs8B/xC2apgVTwoYd9s4tZEVT 81YYKax1bZUij8PwFPZgc+oy6IuG819OED3jSE87LpIo0WdxSqj9+0HGUuXF8pdD ND8C+6QDWNCwbFdDKu9D+F3/sJiLR7QMa4SCyx2BKMqeMx99rXv1ZWkOjSSZX7I= =+ymL -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Two more Python packages for review swaps: python-qrcode and gnuhealth
On Sun, 2012-06-03 at 21:37 +0700, Michel Alexandre Salim wrote: Exchanged against: https://bugzilla.redhat.com/show_bug.cgi?id=821267 Review Request: R-BiocGenerics - Generic functions for Bioconductor Assigning to myself; will do that tomorrow. Thanks! Thank you :) Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20120603 changes
Compose started at Sun Jun 3 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) [389-dsgw] 389-dsgw-1.1.9-2.fc17.x86_64 requires libicuuc.so.48()(64bit) 389-dsgw-1.1.9-2.fc17.x86_64 requires libicui18n.so.48()(64bit) 389-dsgw-1.1.9-2.fc17.x86_64 requires libicudata.so.48()(64bit) [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 [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) [calligra] calligra-core-2.4.90-1.fc18.x86_64 requires calligra-kexi-map-form-widget 0:2.4.90-1.fc18 [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) [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) [kdegraphics-thumbnailers] kdegraphics-thumbnailers-4.8.3-1.fc18.x86_64 requires libkexiv2.so.10()(64bit) kdegraphics-thumbnailers-4.8.3-1.fc18.x86_64 requires libkdcraw.so.20()(64bit) [kdeplasma-addons] kdeplasma-addons-4.8.3-1.fc18.x86_64 requires libkexiv2.so.10()(64bit) plasma-wallpaper-marble-4.8.3-1.fc18.x86_64 requires libmarblewidget.so.13()(64bit) [ksnapshot] ksnapshot-4.8.3-2.fc18.x86_64 requires libkipi.so.8()(64bit) [mapnik] mapnik-2.0.0-4.fc17.i686 requires libicuuc.so.48 mapnik-2.0.0-4.fc17.x86_64 requires libicuuc.so.48()(64bit) mapnik-utils-2.0.0-4.fc17.x86_64 requires libicuuc.so.48()(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)
Looking for sponsor
Hi, I'm looking for sponsor for the following proposed packages: Lithuanian dictionaries for StarDict https://bugzilla.redhat.com/show_bug.cgi?id=781766 Double-array trie implementation library https://bugzilla.redhat.com/show_bug.cgi?id=733925 Thanks. -- Aurimas signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
3.5.0 kernel problem
First - If this is the wrong place for this please tell me where. Rawhide (Fedora 18) I have never been able to install and configure any of the 3.5.0 kernels. They install but fail to create a initramfs file. Hence they will not boot. I have seen two different 'failed' messages. One from today is Non-fatel POSTTRANS scriptlet failure in rpm package kernel-3.5.0-0.rc0.git11.1.fc18.x86_64. I got no initramfs file for this kernel. The other 'failed' message, which I unfortunately did not write down, was a failure to 'find modules' that showed the path to where they expected to find these modules. I got no initramfs file for these kernels either. In all cases I did not get an initramfs. In all cases these kernels will not boot. -- David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
Adam Williamson wrote: Frankly, I'd prefer it if we more strongly recommended that people do DVD/netinst upgrades. I refuse to buy writable DVDs or CDs, because if I did I would be giving money to the copyright lobby, helping to finance its campaign for ever-increasing mass surveillance and censorship of the Net. It is possible to boot a DVD image from the hard disk, but it's anything but easy and rarely succeeds at the first attempt, so that's not something I want to fiddle around with twice a year on both of my Fedora boxes. I also won't install anything that I haven't checked the PGP signature on. That excludes netinst.iso and Preupgrade, and if I use Anaconda I have to be careful to not let it download anything. Therefore I usually upgrade by Yum. That's also a laborious process, but I usually get a mostly working system in the end. 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: another upgrade, another disaster
On Sun, Jun 03, 2012 at 07:56:48PM +0200, Björn Persson wrote: Adam Williamson wrote: Frankly, I'd prefer it if we more strongly recommended that people do DVD/netinst upgrades. I refuse to buy writable DVDs or CDs, because if I did I would be giving money to the copyright lobby, helping to finance its campaign for ever-increasing mass surveillance and censorship of the Net. It is possible to boot a DVD image from the hard disk, but it's anything but easy and rarely succeeds at the first attempt, so that's not something I want to fiddle around with twice a year on both of my Fedora boxes. You can write .iso image to USB key¹ and boot from it, you know. ¹ using 'dd' or Disks → gear icon → restore image. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/3/2012 1:56 PM, Björn Persson wrote: Adam Williamson wrote: Frankly, I'd prefer it if we more strongly recommended that people do DVD/netinst upgrades. I refuse to buy writable DVDs or CDs, because if I did I would be giving money to the copyright lobby, helping to finance its campaign for ever-increasing mass surveillance and censorship of the Net. It is possible to boot a DVD image from the hard disk, but it's anything but easy and rarely succeeds at the first attempt, so that's not something I want to fiddle around with twice a year on both of my Fedora boxes. I also won't install anything that I haven't checked the PGP signature on. That excludes netinst.iso and Preupgrade, and if I use Anaconda I have to be careful to not let it download anything. Therefore I usually upgrade by Yum. That's also a laborious process, but I usually get a mostly working system in the end. Björn Persson Do you also wear a tinfoil hat? - -- David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPy6gzAAoJEObJ14kUYB6pxwMH/RM4TetkkGYswFQymelIz5h1 meRLfoCPT1SXqc3bAu3u2J8m9y2CdWULbaf6jqU1ce2y/Cu0zSJ3A02FvlSYlu30 okt6z8wn5gfKNqk6fpvwCYbMHP+TJsFLC41YE3vg86JDCo9JzEKSDt1oMuRYysTm Qb3gUbu/C0rmKAgp0DrHdaMypCbr/4wKDNmk2/8VFp2Tsh/709+jHxyJnxAGCiyC LutHtVh1mn1hMWmwcZ9hDb/hFUqNMasSl3EBpWYP8eS/zThkldo/W53wfQbnuSy2 UTqqx1hFXcFPpTCAb0URh8cImFWGV+7rxSj6+vTOjHv0iunxlTrXOCs1rnvi0zo= =4z2F -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
3.5.0 kernel problem
David dgboles at gmail.com writes: In all cases I did not get an initramfs. In all cases these kernels will not boot. I have kernel-3.4.0-1.fc18.x86_64 kernel-3.5.0-0.rc0.git11.1.fc18.x86_64 kernel-3.5.0-0.rc0.git12.1.fc18.x86_64 installed, I have an initramfs for all of them, and testing the latest one, it boots properly (most of the time I just boot into a non-debug kernel in runlevel 3, apply updates, and shut down). I see a different problem - for the latest 3.5.0 kernels, kernel-devel does not contain the file /usr/src/kernels/*/System.map. For example, when installing the latest kernel I saw Processing delta metadata /usr/src/kernels/3.5.0-0.rc0.git11.1.fc18.x86_64/System.map: No such file or directory delta does not match installed data and surely enough the file does not exist, even though rpm -ql kernel-devel-3.5.0-0.rc0.git11.1.fc18.x86_64 | grep System.map lists it. The two 3.5.0 kernels have this problem, the 3.4.0 kernel does not. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
Pavel, On Tue, 2012-05-29 at 20:21 +0400, Pavel Alexeev wrote: It is main reason why I request provenpackager rights. In fedora 17 it was so painful because I several times asks build dependencies and then ask help to push updates too. I think in that turn now I can do all that myself, so it should be smoother. As there around 6 security issues, I think update upstream release is easiest, and furthermore robust way handle it. I've seen you didn't listen to Tomáš's or Kalev's advice on not bumping the ImageMagick's soname in a stable release. Furthermore, you didn't give any warning to the maintainers of the dependent packages (except for the message on this list). In my opinion, being a provenpackager is no excuse for not doing that. Please, use the packagename-ow...@fedoraproject.org addresses to send out emails to the appropriate package maintainers. For techne (one of the dependent packages which I maintain) you bumped the release from 0.2.3-2 to 0.2.3-3, which breaks upgrades to F-17 and rawhide. Is there a way to revert the change and make a 0.2.3-2.fc16.1 build? Best regards, Tadej Janež -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 3.5.0 kernel problem
On Sun, Jun 3, 2012 at 1:02 PM, David dgbo...@gmail.com wrote: First - If this is the wrong place for this please tell me where. Rawhide (Fedora 18) I have never been able to install and configure any of the 3.5.0 kernels. They install but fail to create a initramfs file. Hence they will not boot. I have seen two different 'failed' messages. One from today is Non-fatel POSTTRANS scriptlet failure in rpm package kernel-3.5.0-0.rc0.git11.1.fc18.x86_64. I got no initramfs file for this kernel. The other 'failed' message, which I unfortunately did not write down, was a failure to 'find modules' that showed the path to where they expected to find these modules. I got no initramfs file for these kernels either. In all cases I did not get an initramfs. In all cases these kernels will not boot. https://bugzilla.redhat.com/show_bug.cgi?id=826689 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 3.5.0 kernel problem
On Sun, Jun 3, 2012 at 2:47 PM, Andre Robatino robat...@fedoraproject.org wrote: David dgboles at gmail.com writes: In all cases I did not get an initramfs. In all cases these kernels will not boot. I have kernel-3.4.0-1.fc18.x86_64 kernel-3.5.0-0.rc0.git11.1.fc18.x86_64 kernel-3.5.0-0.rc0.git12.1.fc18.x86_64 installed, I have an initramfs for all of them, and testing the latest one, it boots properly (most of the time I just boot into a non-debug kernel in runlevel 3, apply updates, and shut down). I see a different problem - for the latest 3.5.0 kernels, kernel-devel does not contain the file /usr/src/kernels/*/System.map. For example, when installing the latest kernel I saw Processing delta metadata /usr/src/kernels/3.5.0-0.rc0.git11.1.fc18.x86_64/System.map: No such file or directory delta does not match installed data That sounds like a deltarpm problem. The kernel-devel package has that file in it, and it's a normal file not a symlink or something. If you download the full RPM and install it via RPM (not yum, or disable the deltarpm plugin) does it exist? Dependencies Resolved Package Arch Version Repository Size Installing: kernel-devel x86_64 3.5.0-0.rc0.git12.1.fc18 /kernel-devel-3.5.0-0.rc0.git12.1.fc18.x86_64 28 M Removing: kernel-devel x86_64 3.3.4-5.fc17 @updates-testing 28 M Transaction Summary Install 1 Package Remove 1 Package Total size: 28 M Is this ok [y/N]: y Downloading Packages: Running Transaction Check Running Transaction Test Transaction Test Succeeded Running Transaction Installing : kernel-devel-3.5.0-0.rc0.git12.1.fc18.x86_64 1/2 Cleanup: kernel-devel-3.3.4-5.fc17.x86_64 2/2 Verifying : kernel-devel-3.5.0-0.rc0.git12.1.fc18.x86_64 1/2 Verifying : kernel-devel-3.3.4-5.fc17.x86_64 2/2 Removed: kernel-devel.x86_64 0:3.3.4-5.fc17 Installed: kernel-devel.x86_64 0:3.5.0-0.rc0.git12.1.fc18 Complete! [jwboyer@vader ~]$ ls /usr/src/kernels/3.5.0-0.rc0.git12.1.fc18.x86_64/System.map /usr/src/kernels/3.5.0-0.rc0.git12.1.fc18.x86_64/System.map [jwboyer@vader ~]$ ls -l /usr/src/kernels/3.5.0-0.rc0.git12.1.fc18.x86_64/System.map -rw-r--r--. 1 root root 2611877 Jun 2 08:16 /usr/src/kernels/3.5.0-0.rc0.git12.1.fc18.x86_64/System.map [jwboyer@vader ~]$ file /usr/src/kernels/3.5.0-0.rc0.git12.1.fc18.x86_64/System.map /usr/src/kernels/3.5.0-0.rc0.git12.1.fc18.x86_64/System.map: ASCII text [jwboyer@vader ~]$ josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
Tomasz Torcz wrote: You can write .iso image to USB key¹ and boot from it, you know. Even the installation DVD images? What I've heard is that that only works with the live CD images. (The copyright lobby taxes even USB keys in Sweden now, but I have some that I bought before they started doing that.) 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: another upgrade, another disaster
On Sun, Jun 3, 2012 at 4:32 PM, Björn Persson bj...@xn--rombobjrn-67a.se wrote: Tomasz Torcz wrote: You can write .iso image to USB key¹ and boot from it, you know. Even the installation DVD images? What I've heard is that that only works with the live CD images. Indeed, even the DVD images. I did this on last Friday. That used to not be the case, and it used to only work with the liveCD and boot.iso images, but now DVD works as well. It even uses the repo contained on the key instead of just acting like netboot.iso. It's as if someone somewhere is off making real beneficial progress. Whoever you are, I salute you and your dogged determinedness to ignore emails! josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 3.5.0 kernel problem
On 6/3/2012 4:26 PM, Josh Boyer wrote: On Sun, Jun 3, 2012 at 1:02 PM, David dgbo...@gmail.com wrote: First - If this is the wrong place for this please tell me where. Rawhide (Fedora 18) I have never been able to install and configure any of the 3.5.0 kernels. They install but fail to create a initramfs file. Hence they will not boot. I have seen two different 'failed' messages. One from today is Non-fatel POSTTRANS scriptlet failure in rpm package kernel-3.5.0-0.rc0.git11.1.fc18.x86_64. I got no initramfs file for this kernel. The other 'failed' message, which I unfortunately did not write down, was a failure to 'find modules' that showed the path to where they expected to find these modules. I got no initramfs file for these kernels either. In all cases I did not get an initramfs. In all cases these kernels will not boot. https://bugzilla.redhat.com/show_bug.cgi?id=826689 That sounds exactly what I am seeing. I did search for 'something like this' but I found nothing. I must have asked the wrong question. Thank you for the link. -- David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
Josh Boyer wrote: On Sun, Jun 3, 2012 at 4:32 PM, Björn Persson bj...@xn--rombobjrn-67a.se wrote: Tomasz Torcz wrote: You can write .iso image to USB key¹ and boot from it, you know. Even the installation DVD images? What I've heard is that that only works with the live CD images. Indeed, even the DVD images. I did this on last Friday. That used to not be the case, and it used to only work with the liveCD and boot.iso images, but now DVD works as well. It even uses the repo contained on the key instead of just acting like netboot.iso. OK, that's a welcome improvement. I might try that. 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
3.5.0 kernel problem
Josh Boyer jwboyer at gmail.com writes: That sounds like a deltarpm problem. The kernel-devel package has that file in it, and it's a normal file not a symlink or something. If you download the full RPM and install it via RPM (not yum, or disable the deltarpm plugin) does it exist? Yum-presto shouldn't matter since when it sees an error like this, it would download the full RPM instead, and even if it didn't, if the rebuild subsequently failed it would download the full RPM after that. It shouldn't be possible for a corrupted RPM to get into the transaction. Anyway, I downloaded kernel-devel-3.5.0-0.rc0.git12.1.fc18.x86_64.rpm from Koji and used yum reinstall on it. After this, the corresponding System.map file exists, though it didn't before. While doing this, I was running the 3.4.0 non-debug kernel as usual. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 3.5.0 kernel problem
On 03/06/12 21:26, Josh Boyer wrote: In all cases I did not get an initramfs. In all cases these kernels will not boot. https://bugzilla.redhat.com/show_bug.cgi?id=826689 https://bugzilla.redhat.com/show_bug.cgi?id=824981 I've had this a while, as discussed on test list. I blame dracut, dracut blames grubby. Which is a duplicate of which, systemd obliterating udev, hasn't helped the mix. -- Regards, Frank Jack of all, fubars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On Qui, 2012-05-31 at 14:58 -0700, Adam Williamson wrote: On Thu, 2012-05-31 at 22:21 +0200, Caterpillar wrote: I would like to share my experience about upgrading from Fedora 16 to 17 a quiet number of machines. 100% percenteage computer base have putted my hands on, had problems during the upgrade from Fedora 16 to 17. Which problems? First of all, the most happening error (~80%) is after preupgrade-anaconda upgrade. Once the installation of fc17 packages has finished, at reboot, grub2 still had Fedora 16 kernels. To fix that you had to start one of those kernels (and conseguentely having a kernel panic when doing a system restart) I can confirm that , seems a grub problem doesn't add F17 kernel to menu , and boots with F16 kernel Yes. We know about that one. We've had it filed since before release. Actually, there are at least two issues in this area. See https://bugzilla.redhat.com/show_bug.cgi?id=820340 , https://bugzilla.redhat.com/show_bug.cgi?id=820351 . No, that is not the case. See above. The issues with old kernel sticking around after upgrade were already known and reported before release. The #820351 case is fundamentally more or less impossible to solve entirely, outside of sticking Epochs in the kernel package. So there was no point holding up the release for that. The #820340 case is specific to preupgrade and isn't a showstopper, so we didn't hold the release for that one either. There is an upgrade currently in testing that ought to fix it. To me seems grub2 bugs and I see more 2 bugs, 1- If have grub with some custom items, I don't know exactly what, I got for example: background_image -m stretch /usr/share/backgrounds/verne/default/normalish/verne.png upgrade boot entry miss at least definition of root so I have to add set root='(hd0,msdos1)' to upgrade boot entry. 2- If I put load_video on upgrade boot entry , preupgrade boots with a blank screen and I don't see any graphic, is a video problem. (I read some bug block about this) Hope that can help something. ah and for recover a fail upgrade system , I got many tips here: http://fedorasolved.org/Members/fenris02/post_upgrade_cleanup but be careful not all of document is correct and is a little old. Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Problem pairing mouse with F17
Hi all, I've installed F17 x86_64 on my Thinkpad T400s and have not been able to pair my razer orochi bluetooth mouse. When I put my F16 x86_64 HDD back in and boot, the mouse works fine over bluetooth. When I put the mouse into pairing mode, the bluetooth applet sees the mouse. However, when I click on it and try to pair, it simply says failed and I have the option to try again. This is what is shown in syslog; Jun 3 22:20:27 lework bluetoothd[770]: bluetoothd[770]: Discovery session 0x7f0ab7114aa0 with :1.142 activated Jun 3 22:20:27 lework bluetoothd[770]: Discovery session 0x7f0ab7114aa0 with :1.142 activated Jun 3 22:20:31 lework bluetoothd[770]: bluetoothd[770]: Stopping discovery Jun 3 22:20:31 lework bluetoothd[770]: Stopping discovery Jun 3 22:20:32 lework udevd[525]: specified group 'plugdev' unknown Jun 3 22:20:32 lework dbus-daemon[837]: dbus[837]: [system] Rejected send message, 3 matched rules; type=method_return, sender=:1.142 (uid=1000 pid=13040 comm=bluetooth-wizard ) interface=(unset) member=(unset) error name=(unset) requested_reply=0 destination=:1.0 (uid=0 pid=770 comm=/usr/sbin/bluetoothd -n ) Jun 3 22:20:32 lework dbus[837]: [system] Rejected send message, 3 matched rules; type=method_return, sender=:1.142 (uid=1000 pid=13040 comm=bluetooth-wizard ) interface=(unset) member=(unset) error name=(unset) requested_reply=0 destination=:1.0 (uid=0 pid=770 comm=/usr/sbin/bluetoothd -n ) Jun 3 22:21:56 lework udevd[525]: specified group 'plugdev' unknown Jun 3 22:21:56 lework bluetoothd[770]: bluetoothd[770]: Refusing input device connect: No such file or directory (2) Jun 3 22:21:56 lework bluetoothd[770]: bluetoothd[770]: Refusing connection from 00:02:76:20:8B:21: setup in progress Jun 3 22:21:56 lework bluetoothd[770]: Refusing input device connect: No such file or directory (2) Jun 3 22:21:56 lework bluetoothd[770]: Refusing connection from 00:02:76:20:8B:21: setup in progress Jun 3 22:22:01 lework udevd[525]: specified group 'plugdev' unknown Jun 3 22:22:01 lework bluetoothd[770]: bluetoothd[770]: Discovery session 0x7f0ab711d790 with :1.142 activated Jun 3 22:22:01 lework bluetoothd[770]: Discovery session 0x7f0ab711d790 with :1.142 activated I can confirm that selinux is disabled (as sestatus shows 'disabled'). Any idea what I should next? Thanks. -- Digimer Papers and Projects: https://alteeve.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem pairing mouse with F17
On 06/04/2012 02:30 AM, Digimer wrote: I can confirm that selinux is disabled (as sestatus shows 'disabled'). Any idea what I should next? File a bug report against Gnome-Bluetooth you can try running this hciconfig hci0 sspmode 0 from the command line as root which was the only way I manage to get my Samsung Galaxy S-II running Android ICS 4.0.3 to pair with my laptop which is running F17 with the latest 3.5 rc kernel. If the workaround works for you and you need to keep the change across reboots you can create a simple type oneshot unit that does that for you. Like... # vim /etc/systemd/system/bluetooth-legacy-pairing.service which contains [Unit] Description=Persistant Bluetooth Legacy Pairing Hack [Service] Type=oneshot ExecStart=/sbin/hciconfig hci0 sspmode 0 RemainAfterExit=yes [Install] WantedBy=graphical.target JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MATE 1.2
Stefan Schulze Frielinghaus wrote: On Sat, 2012-06-02 at 10:21 -0400, Randall Berry wrote: Does anyone plan to package MATE 1.2[1] for Fedora? MATE is a promising A Gnome 2.3 fork. If so I would like to be a co-maintainer. Or if nobody is planning on it I'll gladly start the project with a little help from a co-maintainer. I do not remember the outcome of the discussion but there was something going on in December last year: http://lists.fedoraproject.org/pipermail/devel/2011-December/160369.html The outcome was that a bunch of people were deriding MATE and not wanting it in Fedora. After some time without anyone willing to review the first few packages, I abandoned my effort. At this point I do not have the time or energy to go back to work on it. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Regarding fedora 17 grub problem
Hello, I am trying to install to install fedora 17 from 3 days.But failed due to some warning. I have downloaded the fedora 17 32 bit image from torrent. I burned its image file and start installing fedora 17. already Window 7 is installed in in my laptop /dev/sda1. So, i am installing fedora 17 on /dev/sda5-root, /dev/sda6-/boot, /dev/sda7-swap, /dev/sda8-/home. On the last phase of installation, when boootloader is going to installed. A warning flashed out there: There is an error in the bootloader.you may not reboot your system. on clicking reboot!! following messages comes: grub loading welcome to grub! error:file not found. entering rescue mode.. grub rescue i have done some experiments grub rescuels (hd0) (hd0,msdos8) (hd0,msdos7) (hd0,msdos6) (hd0,msdos5) (hd0,msdos4) (hd0,msdos3) (hd0,msdos2) (hd0,msdos1) how can i get rid from it? -- Chandan Kumar 3rd year,computer science engineering. Dr.B.C.Roy Engineering College,Durgapur ciypro.wordpress.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
On 06/03/12 at 01:34pm, Tomasz Torcz wrote: On Sun, Jun 03, 2012 at 01:21:55PM +0200, Andrea Musuruane wrote: On Sat, Jun 2, 2012 at 8:17 PM, Andrea Musuruane musur...@gmail.com wrote: On Tue, May 29, 2012 at 10:42 PM, Neal Becker ndbeck...@gmail.com wrote: Basically the same kind of failure as the last several times I did updates. This time f16-f17. Used preupgrade. I'd like to share with you my experience about installing Fedora 17/x86_64. It is a real PITA. No doubts about it. 6th attempt: I did a minimal install also enabling remote updates and at last I can boot Fedora 17. Now the problem is how to install a graphical desktop environment from minimal install. I googled without finding nothing really useful. As previously, any help is really appreciated. yum groupinstall GNOME Desktop Environment This alone unfortunately doesn't do the trick. You will probably have to yum groupinstall X Window System as well as some drivers for your graphic card to get it working. I also had to order selinux to relabel my entire /home to be able to get into any gnome session. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-Net-OpenSSH
perl-Net-OpenSSH has broken dependencies in the rawhide tree:
On x86_64:
perl-Net-OpenSSH-0.57-3.fc18.noarch requires
openssh-clients(%{__isa_name}-%{__isa_bits})
On i386:
perl-Net-OpenSSH-0.57-3.fc18.noarch requires
openssh-clients(%{__isa_name}-%{__isa_bits})
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File MooseX-Daemonize-0.15.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-MooseX-Daemonize: 49311a9d08079308f37aa2bcbb43f9dc MooseX-Daemonize-0.15.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-MooseX-Daemonize] update to 0.15
commit 7bf053a01ffb2e241b0f252b4f5e6e6bd5aa5933
Author: Iain Arnell iarn...@gmail.com
Date: Sun Jun 3 12:06:31 2012 -0600
update to 0.15
.gitignore |1 +
perl-MooseX-Daemonize.spec | 10 ++
sources|2 +-
3 files changed, 8 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 32285a1..1a5d93e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
MooseX-Daemonize-0.09.tar.gz
/MooseX-Daemonize-0.12.tar.gz
/MooseX-Daemonize-0.13.tar.gz
+/MooseX-Daemonize-0.15.tar.gz
diff --git a/perl-MooseX-Daemonize.spec b/perl-MooseX-Daemonize.spec
index f0a98a7..a7bde97 100644
--- a/perl-MooseX-Daemonize.spec
+++ b/perl-MooseX-Daemonize.spec
@@ -1,11 +1,11 @@
Name: perl-MooseX-Daemonize
-Version:0.13
-Release:2%{?dist}
+Version:0.15
+Release:1%{?dist}
Summary:Role for daemonizing your Moose based application
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/MooseX-Daemonize/
-Source0:
http://www.cpan.org/authors/id/S/ST/STEVAN/MooseX-Daemonize-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/M/MI/MICHAELR/MooseX-Daemonize-0.15.tar.gz
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Moose) = 0.33
@@ -34,7 +34,6 @@ make %{?_smp_mflags}
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
@@ -47,6 +46,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Sun Jun 03 2012 Iain Arnell iarn...@gmail.com 0.15-1
+- update to latest upstream version
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.13-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
diff --git a/sources b/sources
index 5326580..af73622 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-fede7bd0885a41e2156afea00b19cf5a MooseX-Daemonize-0.13.tar.gz
+49311a9d08079308f37aa2bcbb43f9dc MooseX-Daemonize-0.15.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-MooseX-Daemonize/f17] update to 0.15
Summary of changes: 7bf053a... update to 0.15 (*) (*) 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
[perl-MooseX-Daemonize/f16] (3 commits) ...update to 0.15
Summary of changes: 7f99c1b... update to 0.13 (*) 72fc0f6... - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass (*) 7bf053a... update to 0.15 (*) (*) 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 827944] New: abi-compliance-checker-1.97.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=827944 Bug ID: 827944 Keywords: FutureFeature, Triaged QA Contact: extras...@fedoraproject.org Severity: unspecified Version: rawhide Priority: unspecified CC: hobbes1...@gmail.com, perl-devel@lists.fedoraproject.org Assignee: hobbes1...@gmail.com Summary: abi-compliance-checker-1.97.7 is available Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: upstream-release-monitor...@fedoraproject.org Type: --- Documentation: --- Hardware: Unspecified Mount Type: --- Status: NEW Component: abi-compliance-checker Product: Fedora Latest upstream release: 1.97.7 Current version in Fedora Rawhide: 1.97.5 URL: http://ispras.linuxbase.org/index.php/ABI_compliance_checker_Downloads 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 -- 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
