Re: [X-post]Join Fedora SIG
On Thu, 2012-06-14 at 17:54 +0530, Ankur Sinha wrote: > Steps: > 1. File ticket at infra to set up fedora-join mailing list > 2. Set up IRC channel #fedora-join > 3. File ticket with websites SIG to make tiny changes to join.fp.o > to list Fedora-Join IRC and mailing list channels. > 4. Ask infra if we can set up a system to send "easyfix" > notifications to the channel/mailing list. > 5. Get started! Hi folks, The Fedora Join SIG[1] now has a mailing list[2] and an IRC channel[3] up and running! If you have some time to spare, please hang out here and help new folks. Even more importantly, if you know folks looking to contribute, please point them to the mailing list or the channel, which ever they prefer. [1] https://fedoraproject.org/wiki/Fedora_Join_SIG [2] https://admin.fedoraproject.org/mailman/listinfo/fedora-join [3] #fedora-join on Freenode -- Thanks, Warm regards, Ankur: "FranciscoD" Please only print if necessary. http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 17 ARM Release Candidate VFAD results - Follow up VFAD on Monday June 18th
Good day all, Thanks to everyone who was able to participate in our VFAD this afternoon. Below is a summary of the results: The following RC1 images (http://scotland.proximity.on.ca/arm-nightlies/vault/to-mirrors/RC1/) worked as expected and all tests were successful: Pandaboard w/serial console & SD Trimslice Bare/Value Pro/H/H250 w/serial console & SD Trimslice Pro/H/H250 w/serial console & SD/SATA Highbank w/serial console & SATA Kirkwood(Guruplug) w/serial console & MicroSD The following images had issues that should be resolved in RC2: Versatile Express(Qemu) - Did not boot, kernel oops. Resolved in RC2. Versatile Express+XFCE (Qemu) - Did not boot, kernel oops. Resolved in RC2. Pandaboard+XFCE w/SD - The RC1 image incorrectly booted to multi-user mode. Fixed in RC2. Using the GUI, options to reboot/shutdown, automatic mounting and updating failed with an authentication error. Bug to be filed. The following images had issues that require further investigation/action: Beagleboard XM w/SD - Booted successfully on a Rev B board, subsequent boots produce a kernel oops. Failed to boot using a Rev A2 board. Efika SmartTop iMX w/SD - Booted successfully, subsequent boots produce a kernel oops. The unofficial nightly images for the Raspberry Pi (http://scotland.proximity.on.ca/arm-nightlies/) were also tested: Raspberry Pi w/SD - Works as expected. Raspberry Pi+XFCE - X not installed. To be resolved in future nightly images. The full results and tests performed can be found here - http://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/2012-06-15-VFAD-Fedora_17_Test_Day New images for RC2 are being created now! Due to the overwhelming success of today, we are holding another VFAD next week: Fedora 17 - RC2 image validation VFAD Monday June 18th - 12pm EDT #fedora-arm on Freenode Special thanks to the participants today, and we hope you can join us next week. On behalf of the Fedora ARM Team, Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Schedule for Monday's FESCo Meeting (2012-06-18)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 17:00UTC (1:00pm EDT) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic ticket 861 - Cleanup of maintainers with bugzilla account .fesco 861 #topic ticket 857 F18 Feature: Initial Experience - https://fedoraproject.org/wiki/Features/InitialExperience .fesco 857 = New business = #topic ticket 863 F18 Feature: Clojure - https://fedoraproject.org/wiki/Features/Clojure .fesco 863 #topic ticket 864 F18 Feature: DNF - https://fedoraproject.org/wiki/Features/DNF .fesco 864 #topic ticket 865 F18 Feature: DragonEgg - https://fedoraproject.org/wiki/Features/DragonEgg .fesco 865 #topic ticket 866 F18 Feature: Dwarf Compressor - https://fedoraproject.org/wiki/Features/DwarfCompressor .fesco 866 #topic ticket 867 F18 Feature: Hawkey - https://fedoraproject.org/wiki/Features/Hawkey .fesco 867 #topic ticket 868 F18 Feature: MiniDebugInfo - https://fedoraproject.org/wiki/Features/MiniDebugInfo .fesco 868 #topic ticket 869 F18 Feature: Offline Updates using systemd and packagekit - https://fedoraproject.org/wiki/Features/OfflineSystemUpdates .fesco 869 #topic ticket 870 F18 Feature: SELinux Booleans Rename - https://fedoraproject.org/wiki/Features/SELinuxBooleansRename .fesco 870 #topic ticket 871 F18 Feature: SysV to systemd - https://fedoraproject.org/wiki/Features/SysVtoSystemd .fesco 871 #topic ticket 872 F18 Feature: systemd unit cleanup and enhancement - https://fedoraproject.org/wiki/Features/Systemd-unit-cleanup .fesco 872 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need some ocaml help: coq rebuild failing
On Thu, Jun 14, 2012 at 10:01 PM, Jerry James wrote: > I'm having a problem with building the coq package for the new OCaml > 4.00.0, and I'm at my wits' end. There were some bad interactions > between the new OCaml, camlp5, and coq which I think I have > successfully worked around. (It isn't pretty, but it seems to do the > job.) But now, after the tools are built, the documentation building > step is failing due to seemingly random segfaults in the coqdoc tool. I patched a few more things in the coq build process for OCaml 4 today and got builds that went all the way to completion in my 64-bit and 32-bit Fedora Rawhide VMs. I rejoiced and kicked off a koji build, which failed with a segfault in coqdoc during the 32-bit build again: http://koji.fedoraproject.org/koji/taskinfo?taskID=4168975 The apparently random pattern of segfaults makes me suspect that the garbage collector is involved somehow. Has anybody had experience with a relatively long-running OCaml 4 program (one that would go through multiple rounds of collecting garbage)? -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
On Jun 15, 2012, at 12:51 PM, Jon Ciesla wrote: >> They are using PBKDF2 with SHA-256, default 500 rounds up to 100,000 rounds. >> The database is locally encrypted. Offline access is possible. The free >> version supports Google Authenticator for TFA, other forms of TFA are >> available in the not free (but cheap, like $12 a year) version. They also >> have a mobile version for every mobile platform I've heard of and then some. > > It's exactly for those features that I use keepassx. :) Umm, so you mean you explicitly want a solution that does not offer TFA, PBKDF2, offline access, or synchronization across computers? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Thoughts on Canonical's Quickly
I poked a little bit and I got quickly up and running partially on an F16 system. I say partially because I can't use all the exposed commands in the ubuntu application template because some of the commands aimed at publication require a coherent debian system configuration to make a local .deb file to upload into launchpad. That difficulty is not really the point of this email. The point of this email is to say that I have quickly up and running on Fedora to the point where it is possible to build alternative templates to the provided ubuntu-application template that would point to Suse's obs system or to our koji for builds/publication instead of launchpad for publishing. We could even plumb in git/github or git/fedorahosted instead of bzr/launchpad..all the opinionated choices are in the template not in quickly itself. Is quickly with an alternative set of application templates something worth exposing as a rapid development tool? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
On Fri, Jun 15, 2012 at 11:22 AM, Adam Williamson wrote: > Well, not so much exit as shutdown. It seems to frequently throw an > exception of some kind on shutdown, which seems to block up the shutdown > process until you dismiss the error dialog. Maybe it's Just Me (TM) Successful rawhide scratch-build if you want to poke at it. http://koji.fedoraproject.org/koji/taskinfo?taskID=4168806 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
So yeah... revelation is back to being entirely noarch python again. Is bouncing a package from arch to noarch as an update going to cause problems? -jef On Fri, Jun 15, 2012 at 11:22 AM, Adam Williamson wrote: > On Fri, 2012-06-15 at 11:14 -0800, Jef Spaleta wrote: >> On Fri, Jun 15, 2012 at 11:05 AM, Adam Williamson >> wrote: >> > On Fri, 2012-06-15 at 10:56 -0800, Jef Spaleta wrote: >> >> It seems there is a new upstream for revelation as of March this year. >> >> I'll poke at them a little bit to see what's going on. It's been a >> >> while since there has been an active upstream for this codebase. >> > >> > Have they fixed the crash-on-exit bug yet? >> >> I'm pulling the May release now to see. There was crash on exit? I >> never encoutered that...lucky me. > > Well, not so much exit as shutdown. It seems to frequently throw an > exception of some kind on shutdown, which seems to block up the shutdown > process until you dismiss the error dialog. Maybe it's Just Me (TM) > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > http://www.happyassassin.net > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
On Fri, 2012-06-15 at 11:14 -0800, Jef Spaleta wrote: > On Fri, Jun 15, 2012 at 11:05 AM, Adam Williamson wrote: > > On Fri, 2012-06-15 at 10:56 -0800, Jef Spaleta wrote: > >> It seems there is a new upstream for revelation as of March this year. > >> I'll poke at them a little bit to see what's going on. It's been a > >> while since there has been an active upstream for this codebase. > > > > Have they fixed the crash-on-exit bug yet? > > I'm pulling the May release now to see. There was crash on exit? I > never encoutered that...lucky me. Well, not so much exit as shutdown. It seems to frequently throw an exception of some kind on shutdown, which seems to block up the shutdown process until you dismiss the error dialog. Maybe it's Just Me (TM) -- 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: Revelation password manager issue
On Fri, Jun 15, 2012 at 11:14 AM, Jef Spaleta wrote: > On Fri, Jun 15, 2012 at 11:05 AM, Adam Williamson wrote: >> On Fri, 2012-06-15 at 10:56 -0800, Jef Spaleta wrote: >>> It seems there is a new upstream for revelation as of March this year. >>> I'll poke at them a little bit to see what's going on. It's been a >>> while since there has been an active upstream for this codebase. >> >> Have they fixed the crash-on-exit bug yet? > > I'm pulling the May release now to see. There was crash on exit? I > never encoutered that...lucky me. > > I'm also watching the upstream code branches to watch when the > security enhancement lands in the main tree. I'll have test packages of the 0.4.13 build up today...cross my fingers. -jef".behind my back"spaleta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
On Fri, Jun 15, 2012 at 11:05 AM, Adam Williamson wrote: > On Fri, 2012-06-15 at 10:56 -0800, Jef Spaleta wrote: >> It seems there is a new upstream for revelation as of March this year. >> I'll poke at them a little bit to see what's going on. It's been a >> while since there has been an active upstream for this codebase. > > Have they fixed the crash-on-exit bug yet? I'm pulling the May release now to see. There was crash on exit? I never encoutered that...lucky me. I'm also watching the upstream code branches to watch when the security enhancement lands in the main tree. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
On Fri, 2012-06-15 at 10:56 -0800, Jef Spaleta wrote: > It seems there is a new upstream for revelation as of March this year. > I'll poke at them a little bit to see what's going on. It's been a > while since there has been an active upstream for this codebase. Have they fixed the crash-on-exit bug yet? -- 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: Revelation password manager issue
It seems there is a new upstream for revelation as of March this year. I'll poke at them a little bit to see what's going on. It's been a while since there has been an active upstream for this codebase. Here's a thought... what's Debian's policy concerning security issues is packages with a dead upstream? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
On Fri, Jun 15, 2012 at 1:48 PM, Chris Murphy wrote: > > On Jun 15, 2012, at 3:09 AM, Daniel P. Berrange wrote: > >> FWIW, I'd recommend KeePassX as an impressive alternative to Revelation, >> with much more advanced & flexible functionality > > I've been using Lastpass for a few months and like the automatic > synchronization between computers and browsers regardless of platform for > browser choice. > > They are using PBKDF2 with SHA-256, default 500 rounds up to 100,000 rounds. > The database is locally encrypted. Offline access is possible. The free > version supports Google Authenticator for TFA, other forms of TFA are > available in the not free (but cheap, like $12 a year) version. They also > have a mobile version for every mobile platform I've heard of and then some. It's exactly for those features that I use keepassx. :) -J > Chris Murphy > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
On Jun 15, 2012, at 3:09 AM, Daniel P. Berrange wrote: > FWIW, I'd recommend KeePassX as an impressive alternative to Revelation, > with much more advanced & flexible functionality I've been using Lastpass for a few months and like the automatic synchronization between computers and browsers regardless of platform for browser choice. They are using PBKDF2 with SHA-256, default 500 rounds up to 100,000 rounds. The database is locally encrypted. Offline access is possible. The free version supports Google Authenticator for TFA, other forms of TFA are available in the not free (but cheap, like $12 a year) version. They also have a mobile version for every mobile platform I've heard of and then some. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: julia language
On 06/14/2012 03:17 PM, Orion Poplawski wrote: I spent some time today trying to package up julia. It's pretty messy and this is no where near complete (it still downloads packages and fails to build due to https://github.com/JuliaLang/julia/issues/933), but thought I'd put it out there in case anyone else wants to play with it. http://www.cora.nwra.com/~orion/fedora/julia-0-0.1.giteecafbe656863a6a8ad4969f53eed358ec2e7555.fc17.src.rpm http://www.cora.nwra.com/~orion/fedora/julia.spec I put an updated copy there that seems to build and run now. Needs fftw 3.3.2 which I'll just fired off a build of in rawhide. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Fri, Jun 15, 2012 at 10:36:15AM -0700, Jesse Keating wrote: > On 06/15/2012 10:31 AM, Steve Clark wrote: > > +1 > > This really isn't adding anything to the discussion, just noise. Please > stop replying to large emails, quoting the entire thing, and just adding > a "+1". It's not helpful. +1 P.S. Sorry, I just couldn't hold the urge... -- Regards,-- Sir Raorn. --- http://thousandsofhate.blogspot.com/ signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Fri, 2012-06-15 at 12:05 -0400, Jay Sulzberger wrote: > In the case of ARM devices Microsoft's statement of its position > is different: If the ARM device is shipped with a Microsoft OS, > then Fedora will never be installed on the device. No putting > one's own key in, no getting a special > Microsoft/Vendor/Certificate-Authority managed key for the whole > Fedora project, no nothing, just gross suppression of Fedora and > all free OSes. I'm not sure that kind of language is really helpful to anyone. Locked devices are what they are. They exist and have for years. Everything is getting more blurred now, given that it's perfectly possible for a microwave oven or wristwatch to have enough power to qualify it as a 'personal computer' by 1980s standards, and very few of them permit easy use of arbitrary code. Cellphones and tablets are personal computers in all sorts of ways; ditto with them, there has never been any kind of convention in those products that the user should be granted easy access to running arbitrary software, and they almost invariably are not. It just is what it is. You can choose to draw a somewhat arbitrary position that all computing devices have to allow ultimate control to their users and refuse to use any that don't, if you really insist. But it seems a bit of a quixotic 'cause' to take up. The open nature of the x86 PC architecture is to a large extent a historical accident more than the result of some sort of great ideological conviction, and the results of trying to graft ideological convictions on to it after the fact seem, to me, slightly forced and unconvincing. So, look. A Windows RT device is going to be just like just about any cellphone or tablet - a device which can be used for many of the purposes for which we're accustomed to using x86-based PCs, with much more restriction on user freedom than x86-based PCs have usually had. If that's not a thing you want, then you're free not to buy one. I certainly wouldn't recommend anyone buy one for the purpose of installing another operating system on it; that'd be silly (except, of course, in cases where particularly compelling implementations turn out to be trivially easy to unlock/root, which is often the case with Android phones). But I find it really difficult to truly believe that the mere existence of such devices is in itself inherently evil or wrong. There's no particular deception or duplicity going on. No-one is telling people they'll easily be able to execute arbitrary code on such devices. You go in with your eyes open, you know what you're getting, and you can choose whether it's something you want to participate in or not. If you don't, well, don't. -- 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: *countable infinities only
On 06/15/2012 12:05 PM, Jay Sulzberger wrote: On Fri, 15 Jun 2012, Mathieu Bridon wrote: On Thu, 2012-06-14 at 15:46 -0400, Jay Sulzberger wrote: Please forgive this top posting. I will not answer now your radical defense of Microsoft, except to say two things: 1. Your defense would apply also to the decades long fraud of Microsoft saying in their EULA that, if you do not run the Microsoft OS installed at point of sale of the hardware, you get a refund for the OS. But Microsoft and the hardware vendors systematically refused refunds. No they haven't. People get their OS refunded in France. It is a long and frustrating process, but with each victory it gets easier. No, even in France, as you state, it is not easy to get a refund. Even though the practice of tying software to hardware is illegal. What this shows is that one must be careful to correctly estimate the size of various forces in tactical situation. The relevance to the present case is this: Some Fedora developers argue that it will still be possible to install Fedora on x86 hardware which, as shipped, has only the PK and the PK "authorized" Microsoft Hardware Key in the UEFI. But Microsoft has for over a decade promised to simply give a refund when requested. And today nowhere on Earth does Microsoft actually simply give a refund when requested. Now Microsoft has promised to always allow the owner sitting before the machine to install their own key. But we know that Microsoft has systematically broken its promise to give refunds. Thus we should not accept Microsoft's promise here. In the case of ARM devices Microsoft's statement of its position is different: If the ARM device is shipped with a Microsoft OS, then Fedora will never be installed on the device. No putting one's own key in, no getting a special Microsoft/Vendor/Certificate-Authority managed key for the whole Fedora project, no nothing, just gross suppression of Fedora and all free OSes. There's even a step-by-step guide (in French) : http://non.aux.racketiciels.info/guide/index Thank you for this pointer. Here is a story from 1999: http://www.nylug.org/articles/text/article.windowsrefundday.nytimes.shtml The story is partly inaccurate. In New York City, of all the vendors whose machines we installed a free OS on, after careful removal of the Microsoft OS, only Emachines gave us a refund. Emachines was courteous in their written response to our request, and prompt in sending us the refund. And recently: """ For the first time in a case related to the sale of hardware/software, a judge declares explicitly that the sale of an OS by the OEM when the customer never asked for it can be considered "unfair in any circumstance given its aggressive characteristic". The argument, more direct than ever (speaking about forced sale rather than bundled sale), is usable in all Europe. """ (quick translation from me, the inner quote is a translation of the actual words from the judge) http://aful.org/communiques/faire-payer-systeme-exploitation-non-demande-deloyal-en I am glad to see the court's clear statement. Of course this is wildly off-topic... -- Mathieu I hope that France enforces the law against tying of software to hardware. France for decades has not. Of course, neither has the United States of America, nor the UK, have enforced the laws and regulations here. Nor has any large European country enforced its analogous laws and regulations, as far as I am aware. This is not offtopic. This is the main topic. Fedora proposes to support Microsoft in Microsoft's attempt to directly control every home computer on Earth. The same arguments that are used in the present UEFI case to justify truckling to Microsoft could as well be applied to the Refund Clause question: "Why there is really no problem. It is just a minor inconvenience that the hardware ships with an OS you do not want. See the EULA says you get a refund, so you just have to carefully remove the Microsoft OS, careful don't start it up by accident, and then you get a refund.". But in fact the policy of Microsoft is not to give any refunds, ever. And in fact in the UEFI case, no matter what Microsoft says, the policy of Microsoft is to make it difficult to install Fedora on x86 hardware, and impossible on ARM hardware. oo--JS. +1 -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM is a dead end
On 06/14/2012 07:57 PM, Kevin Kofler wrote: So even smartphones are going x86 now. It looks like x86 is going to defeat ARM just like it defeated all the previous attempts at changing the instruction set, even Intel's own IA-64. The fastest x86 CPUs are still worlds faster than the fastest ARM CPUs. This new smartphone's single-core Atom is competitive in speed with other smartphones' multi-core ARMs. So I would urge Fedora not to waste our time on a low-end architecture filling a temporary niche which will become obsolete as demand for performance increases. There are three axis to this 3D space: performance, energy efficiency (MIPS per Watt or, rather, useful computation per Joule), and price. Intel did wonderfully on the first axis, but lags ARM persistently on the remaining two, and ARM seem to be catching up on performance. Watch the price, especially. Low end ARM Cortex M chips cost less than one dollar, and require just few passive components in a simplistic but complete running system. Raspberry Pi runs Linux for a total system cost of $15 ($20? $30). The goal here is computers so cheap that if one falls behind a really big and heavy desk that's hard to move, you sigh and get another unit. Seriously, only at this price point it'll be practical to deploy massive amounts of computers into scenarios like 'white goods' and party photo-balloons and such, and Linux wants to be there, so it's worth to pay attention to ARM. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Fri, 15 Jun 2012, Mathieu Bridon wrote: > On Thu, 2012-06-14 at 15:46 -0400, Jay Sulzberger wrote: > Please forgive this top posting. > > I will not answer now your radical defense of Microsoft, except to > say two things: > > 1. Your defense would apply also to the decades long fraud of > Microsoft saying in their EULA that, if you do not run the > Microsoft OS installed at point of sale of the hardware, you get > a refund for the OS. But Microsoft and the hardware vendors > systematically refused refunds. No they haven't. People get their OS refunded in France. It is a long and frustrating process, but with each victory it gets easier. No, even in France, as you state, it is not easy to get a refund. Even though the practice of tying software to hardware is illegal. What this shows is that one must be careful to correctly estimate the size of various forces in tactical situation. The relevance to the present case is this: Some Fedora developers argue that it will still be possible to install Fedora on x86 hardware which, as shipped, has only the PK and the PK "authorized" Microsoft Hardware Key in the UEFI. But Microsoft has for over a decade promised to simply give a refund when requested. And today nowhere on Earth does Microsoft actually simply give a refund when requested. Now Microsoft has promised to always allow the owner sitting before the machine to install their own key. But we know that Microsoft has systematically broken its promise to give refunds. Thus we should not accept Microsoft's promise here. In the case of ARM devices Microsoft's statement of its position is different: If the ARM device is shipped with a Microsoft OS, then Fedora will never be installed on the device. No putting one's own key in, no getting a special Microsoft/Vendor/Certificate-Authority managed key for the whole Fedora project, no nothing, just gross suppression of Fedora and all free OSes. There's even a step-by-step guide (in French) : http://non.aux.racketiciels.info/guide/index Thank you for this pointer. Here is a story from 1999: http://www.nylug.org/articles/text/article.windowsrefundday.nytimes.shtml The story is partly inaccurate. In New York City, of all the vendors whose machines we installed a free OS on, after careful removal of the Microsoft OS, only Emachines gave us a refund. Emachines was courteous in their written response to our request, and prompt in sending us the refund. And recently: """ For the first time in a case related to the sale of hardware/software, a judge declares explicitly that the sale of an OS by the OEM when the customer never asked for it can be considered "unfair in any circumstance given its aggressive characteristic". The argument, more direct than ever (speaking about forced sale rather than bundled sale), is usable in all Europe. """ (quick translation from me, the inner quote is a translation of the actual words from the judge) http://aful.org/communiques/faire-payer-systeme-exploitation-non-demande-deloyal-en I am glad to see the court's clear statement. Of course this is wildly off-topic... -- Mathieu I hope that France enforces the law against tying of software to hardware. France for decades has not. Of course, neither has the United States of America, nor the UK, have enforced the laws and regulations here. Nor has any large European country enforced its analogous laws and regulations, as far as I am aware. This is not offtopic. This is the main topic. Fedora proposes to support Microsoft in Microsoft's attempt to directly control every home computer on Earth. The same arguments that are used in the present UEFI case to justify truckling to Microsoft could as well be applied to the Refund Clause question: "Why there is really no problem. It is just a minor inconvenience that the hardware ships with an OS you do not want. See the EULA says you get a refund, so you just have to carefully remove the Microsoft OS, careful don't start it up by accident, and then you get a refund.". But in fact the policy of Microsoft is not to give any refunds, ever. And in fact in the UEFI case, no matter what Microsoft says, the policy of Microsoft is to make it difficult to install Fedora on x86 hardware, and impossible on ARM hardware. oo--JS. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 480129] Error at calling service amavisd restart when SELinux is in enforce mode
https://bugzilla.redhat.com/show_bug.cgi?id=480129 Karel Srot changed: What|Removed |Added CC||ks...@redhat.com -- 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
Re: ARM is a dead end
On 06/14/2012 07:57 PM, Kevin Kofler wrote: Hi, I've been pointed to a news item about a (apparently the first) x86 (Atom) based smartphone: http://www.engadget.com/2012/06/14/orange-san-diego-review/ So even smartphones are going x86 now. It's probably best not to extrapolate the extent of a trend from a single point. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Fri, Jun 15, 2012 at 4:06 AM, Eric Smith wrote: > Jesse Keating wrote: >> >> The point in which you find yourself arguing over the semantics of >> Goodwin's law is also a clear indication that the thread has lost any amount >> of usefulness. > > > Godwin's Meta-Law? Or maybe Keating's Corollary to Godwin's Law? > It is more of a dilemma than a law, as it represents the common misunderstanding. Godwin's law says nothing about the usefulness of the thread. The law, by definition, applies to any thread. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redhat-rpm-config and rpm-build (fwd)
- Original Message - > From: "Jan Kratochvil" > To: "Development discussions related to Fedora" > > Sent: Friday, June 15, 2012 11:35:19 AM > Subject: Re: redhat-rpm-config and rpm-build (fwd) > > On Fri, 15 Jun 2012 05:03:59 +0200, Jens Petersen wrote: > > Well I tend to agree: it would be the least surprising behaviour > > for most fedora packagers. > > Though I understand the point about keeping rpmbuild generic - > > I don't see how pulling in redhat-rpm-config would break generic > > rpms? > > Surely most people have it installed anyway. > > > > Have you filed a bug? :) > > Yes: > https://bugzilla.redhat.com/show_bug.cgi?id=482855 > > > Jan I filed a bug about it some time ago and it was closed as notabug :) This is the most annoying issue, which I need to solve after every reinstall. I would be really glad if it was fixed. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: redhat-rpm-config and rpm-build (fwd)
On 06/15/2012 05:03 AM, Jens Petersen wrote: yum install rpm-build should install an rpmbuild version that works as expected for fedora. Currently, it does not because it is missing the dependancy on redhat-rpm-config. Well I tend to agree: it would be the least surprising behaviour for most fedora packagers. I think it's a silly idea. rpm-build is a generic tool and redhat-rpm-config is a redhat specific/proprietary add-on/plugin to it. Though I understand the point about keeping rpmbuild generic - I don't see how pulling in redhat-rpm-config would break generic rpms? Though I don't have a current example of current redhat-rpm-config breaking generic rpms, history is full of such cases. I think I BZ'ed several of them several years ago. Surely most people have it installed anyway. Well, fedora packagers will have it installed, because fedora-packager pulls it in. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-XML-Simple-DTDReader] Specify all dependencies
commit cab930586b939289877c09fab22fb5a780681ebb
Author: Petr Písař
Date: Fri Jun 15 11:35:57 2012 +0200
Specify all dependencies
perl-XML-Simple-DTDReader.spec | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
---
diff --git a/perl-XML-Simple-DTDReader.spec b/perl-XML-Simple-DTDReader.spec
index 5101a05..fc271d3 100644
--- a/perl-XML-Simple-DTDReader.spec
+++ b/perl-XML-Simple-DTDReader.spec
@@ -9,9 +9,19 @@ Source0:
http://www.cpan.org/modules/by-module/XML/XML-Simple-DTDReader-%
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
+# Run-time
+BuildRequires: perl(Carp)
+BuildRequires: perl(Cwd)
+BuildRequires: perl(Data::Dumper)
+BuildRequires: perl(Exporter)
BuildRequires: perl(XML::Parser) >= 2.28
+# Tests
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
+Requires: perl(XML::Parser) >= 2.28
+
+# Filter under-specified dependencies
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(XML::Parser\\)$
%description
XML::Simple::DTDReader aims to be a XML::Simple drop-in replacement, but
@@ -50,6 +60,7 @@ rm -rf $RPM_BUILD_ROOT
%changelog
* Fri Jun 15 2012 Petr Pisar - 0.04-12
- Perl 5.16 rebuild
+- Specify all dependencies
* Fri Jan 13 2012 Fedora Release Engineering
- 0.04-11
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
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: redhat-rpm-config and rpm-build (fwd)
On Fri, 15 Jun 2012 05:03:59 +0200, Jens Petersen wrote: > Well I tend to agree: it would be the least surprising behaviour for most > fedora packagers. > Though I understand the point about keeping rpmbuild generic - > I don't see how pulling in redhat-rpm-config would break generic rpms? > Surely most people have it installed anyway. > > Have you filed a bug? :) Yes: https://bugzilla.redhat.com/show_bug.cgi?id=482855 Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Escalation - better desktop printing policy (over two years old issue)
On Fri, 2012-06-15 at 09:30 +0200, valent.turko...@gmail.com wrote: > Hi, > Fedora still has quite strict printing policies even if users choose > to be a part of Administrator group during installation still need to > input passwords while changing even the minor printer settings (like > unpausing). This is still an issue on Fedora 16 and 17, is has been in > bugzilla for over 2 years: > https://bugzilla.redhat.com/show_bug.cgi?id=596711 > > Why are Administrator users being asked for root pasword when editing > printer options? There is a fix from Fedora wiki page: > http://fedoraproject.org/wiki/Printing/ConfigurationTool > > Please make this fix permanent and enabled by default in Fedora. > > If I'm not mistaken this is the same issue that Linus Torvalds vented > regarding same issue on OpenSuse - > https://plus.google.com/102150693225130002912/posts/1vyfmNCYpi5 FWIW, a better way of doing print-to-remote-service is being planned which requires no special privilege: http://cyberelk.net/tim/2012/03/08/session-printing/ (This is no help for print-to-locally-attached-printer though.) Tim. */ 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: Revelation password manager issue
On Thu, Jun 14, 2012 at 11:24:20AM -0700, Adam Williamson wrote: > On Thu, 2012-06-14 at 17:21 +0200, Tomas Mraz wrote: > > On Thu, 2012-06-14 at 07:40 -0500, Josh Bressers wrote: > > > Hello all, > > > > > > I suspect this is going to be a weird problem to figure out. > > > > > > Relevation password manager > > > https://admin.fedoraproject.org/pkgdb/applications/Revelation Password > > > Manager > > > > > > Has been found to be unsafe. > > > http://knoxin.blogspot.co.uk/2012/06/revelation-password-manager-considered.html > > > > > > I would hope it gets fixed at some future point, but something should > > > probably be done in the short term. > > > > > > I'm not sure what Fedora precedent is on issues like this. We can't > > > really revoke such a package, and we also want to give users a warning > > > to use a different password manager (I'm not entirely sure how to best > > > do this). > > > > > > Does anyone have any thoughts? > > > > The insecurity of the Revelation db format is not as dire as the blog > > tries to picture it. Sure if you use password with low entropy then it > > is much worse than in case of properly salted PBKDF2 algorithm. But if > > your password contains enough entropy (100 bits or more) it is OK. > > Especially if you do not use it to protect passwords for classified > > materials. :) So perhaps warning to use only strong passwords could be > > added somewhere. > > Right. Honestly, as a Revelation user with a ten character password, the > blog post honestly did not make me feel like 'oh shit I need to change > everything immediately'. I don't use Revelation because I consider it > likely that some determined attacker is going to acquire a copy of my > database file (in itself not trivial) and then throw several weeks of > high-end processing power at accessing my password database. I use it > because it's a very effective way of ensuring things like the LinkedIn > password database breach have a very limited impact on me. FWIW, I'd recommend KeePassX as an impressive alternative to Revelation, with much more advanced & flexible functionality Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Jesse Keating wrote: The point in which you find yourself arguing over the semantics of Goodwin's law is also a clear indication that the thread has lost any amount of usefulness. Godwin's Meta-Law? Or maybe Keating's Corollary to Godwin's Law? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM is a dead end
- Original Message - > Hi, > > I've been pointed to a news item about a (apparently the first) x86 > (Atom) > based smartphone: > http://www.engadget.com/2012/06/14/orange-san-diego-review/ > > So even smartphones are going x86 now. It looks like x86 is going to > defeat > ARM just like it defeated all the previous attempts at changing the > instruction set, even Intel's own IA-64. The fastest x86 CPUs are > still > worlds faster than the fastest ARM CPUs. This new smartphone's > single-core > Atom is competitive in speed with other smartphones' multi-core ARMs. > > So I would urge Fedora not to waste our time on a low-end > architecture > filling a temporary niche which will become obsolete as demand for > performance increases. We should rather support only one primary > architecture (x86, i.e.: x86_64, and legacy i686 as long as there's a > need > for it) and support it well, as we have done since we finally got rid > of the > legacy PPC burden. Niche architectures are exactly what secondary > architectures are for. Intel promises mobile CPUs for several years and it's still a huge fail... My Intel based tablet has a fan (and it's not fun). I have to admit, I prefer x86 arch as it's easier to develop/work with but not in mobile world yet. R. > Kevin Kofler > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM is a dead end
On 15 June 2012 01:57, Kevin Kofler wrote: > So I would urge Fedora not to waste our time on a low-end architecture > filling a temporary niche which will become obsolete as demand for > performance increases. We should rather support only one primary > architecture (x86, i.e.: x86_64, and legacy i686 as long as there's a need > for it) and support it well, as we have done since we finally got rid of the > legacy PPC burden. Niche architectures are exactly what secondary > architectures are for. Servers are moving to ARM as well, HP and Dell for example: http://h17007.www1.hp.com/us/en/iss/110111.aspx http://en.community.dell.com/techcenter/high-performance-computing/b/weblog/archive/2012/06/01/better-density-less-power-consumption-at-heart-of-dell-s-arm-based-ecosystem-building-program.aspx We could guess RHEL 7 will build on the ARM development in Fedora. And I personally would really like to run something that's not x86. Regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Escalation - better desktop printing policy (over two years old issue)
Hi, Fedora still has quite strict printing policies even if users choose to be a part of Administrator group during installation still need to input passwords while changing even the minor printer settings (like unpausing). This is still an issue on Fedora 16 and 17, is has been in bugzilla for over 2 years: https://bugzilla.redhat.com/show_bug.cgi?id=596711 Why are Administrator users being asked for root pasword when editing printer options? There is a fix from Fedora wiki page: http://fedoraproject.org/wiki/Printing/ConfigurationTool Please make this fix permanent and enabled by default in Fedora. If I'm not mistaken this is the same issue that Linus Torvalds vented regarding same issue on OpenSuse - https://plus.google.com/102150693225130002912/posts/1vyfmNCYpi5 Thanks, Valent. -- follow me - www.twitter.com/valentt & http://kernelreloaded.blog385.com linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM is a dead end
On Fri, Jun 15, 2012 at 1:08 AM, Matthew Garrett wrote: > On Fri, Jun 15, 2012 at 01:57:18AM +0200, Kevin Kofler wrote: > >> So I would urge Fedora not to waste our time on a low-end architecture >> filling a temporary niche which will become obsolete as demand for >> performance increases. We should rather support only one primary >> architecture (x86, i.e.: x86_64, and legacy i686 as long as there's a need >> for it) and support it well, as we have done since we finally got rid of the >> legacy PPC burden. Niche architectures are exactly what secondary >> architectures are for. > > If Fedora ARM is currently causing you problems then please do point out > the specifics. But if it's not, then why do you expect it to get any > worse if it becomes a primary architecture? I don't see why it would have as we've not reported a single bug to him. He's only ever had one point and that is wrt build time and that has already been addressed in the guidelines produced for Secondary Arch promotion. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM is a dead end
On Fri, Jun 15, 2012 at 12:57 AM, Kevin Kofler wrote: > Hi, > > I've been pointed to a news item about a (apparently the first) x86 (Atom) > based smartphone: > http://www.engadget.com/2012/06/14/orange-san-diego-review/ > > So even smartphones are going x86 now. It looks like x86 is going to defeat > ARM just like it defeated all the previous attempts at changing the > instruction set, even Intel's own IA-64. The fastest x86 CPUs are still > worlds faster than the fastest ARM CPUs. This new smartphone's single-core > Atom is competitive in speed with other smartphones' multi-core ARMs. > > So I would urge Fedora not to waste our time on a low-end architecture > filling a temporary niche which will become obsolete as demand for > performance increases. We should rather support only one primary > architecture (x86, i.e.: x86_64, and legacy i686 as long as there's a need > for it) and support it well, as we have done since we finally got rid of the > legacy PPC burden. Niche architectures are exactly what secondary > architectures are for. Phones have never been a target for Fedora ARM so the point you make is completely irrelevant and doesn't change any of our aims or goals. Intel has been producing Atom processors aimed at phones for a couple of generations of processor now. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM is a dead end
On Fri, Jun 15, 2012 at 6:42 AM, tim.laurid...@gmail.com wrote: > > [...] > > Linux is about choices No it isn't: http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html (I do disagree with Kevin though). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
