date:20120616

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

2012-06-16 Thread Jochen Schmitt

On Fri, Jun 15, 2012 at 05:15:53PM -0600, Kevin Fenzi wrote:

 #topic ticket 863 F18 Feature: Clojure -
 https://fedoraproject.org/wiki/Features/Clojure 
 .fesco 863

I think Leiminger may be a better name for this feature.
the aim of this feature is the introduction of Lieminger
as an IDE for clojure. Clojure itselft is part of the
current Fedora releases.

Best Regards:

Jochen Schmitt
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F16: Sandy Bridge - lags, missing effects, ui-crashes

2012-06-16 Thread Roberto Ragusa

On 05/29/2012 11:29 PM, Reindl Harald wrote:

 the follwoing params making things better and stop especially
 the lags most of the time, but on the same machine over a long
 time was set to pcie_aspm=force and all i915 option at 1
 
 pcie_aspm=off i915.i915_enable_rc6=0 i915.semaphores=0 
 i915.i915_enable_fbc=0
 
 i think i have to mention taht VT-d is active in the BIOS and
 i was wondering that it was stable because the combination of the
 i915 options with VT-d (hardware supported virtualization IO) is
 classified to be unstable

No issues for a couple of weeks, after disabling VT-d in the BIOS,
but there were kernel updates too, in the meantime.
(And I now expect the problem to show up immediately
after sending this mail) :-)

-- 
   Roberto Ragusamail at robertoragusa.it
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

2012-06-16 Thread Jochen Schmitt

On Fri, Jun 15, 2012 at 05:15:53PM -0600, Kevin Fenzi wrote:

 #topic ticket 869 F18 Feature: Offline Updates using systemd and
 packagekit -
 https://fedoraproject.org/wiki/Features/OfflineSystemUpdates 
 .fesco 869

The titel of this feature is a lttle misleading for me and the
description of the feature sounds linke Windows where you get
the message: Pleaae reboot your system to activate the installed
updates.

One of the most inportant advance of Linux over Windows is the
fact, that there are only a few situations - like kernel updates -
which requires a reboot of your system.

This features is inpractical of server systems where you want to
avoid reboots to minimizize downtimes.

I oppsoite it may be beeter to tag the packages where a reboot may
be requrire to activate the installed update with a virtual provides.

Yum may detect this virtaul provide during the update and can take
accorate action in this case.

Best Regards:

Jochen Schmitt
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

2012-06-16 Thread Ralf Ertzinger

Hi.

On Sat, 16 Jun 2012 14:57:30 +0200, Jochen Schmitt wrote

 One of the most inportant advance of Linux over Windows is the
 fact, that there are only a few situations - like kernel updates -
 which requires a reboot of your system.

Linux has, in principle, the same problem as Windows, that while
you can replace files that are in use running processes will (of course)
not pick up the changes until restarted. Most daemons do so when updated
themselves, but, for example, updating zlib because of an exploit will
not restart all daemons using the exploitable library, so unless the
admin restarts those manually or the system is rebooted you might
still be vulnerable.

MS has choosen the reboot route to deal with this, and current versions
leave it up to the user to initiate the reboot while nagging about
it in regular intervals (which Fedora does not do, and I'm not sure
this is a good thing tbh).


-- 
Democracy is 3 wolves  a sheep voting on what to have for dinner.
-- 
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)

2012-06-16 Thread valent.turko...@gmail.com

On Fri, Jun 15, 2012 at 11:15 AM, Tim Waugh twa...@redhat.com wrote:
 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.
 */

OK, but why isn't this easy fix via new policy done, why is it sitting
in bugzilla for over two years?

-- 
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: Schedule for Monday's FESCo Meeting (2012-06-18)

2012-06-16 Thread Michael Scherer

Le samedi 16 juin 2012 à 14:57 +0200, Jochen Schmitt a écrit :
 On Fri, Jun 15, 2012 at 05:15:53PM -0600, Kevin Fenzi wrote:
 
  #topic ticket 869 F18 Feature: Offline Updates using systemd and
  packagekit -
  https://fedoraproject.org/wiki/Features/OfflineSystemUpdates 
  .fesco 869
 
 The title of this feature is a little misleading for me and the
 description of the feature sounds linke Windows where you get
 the message: Pleaae reboot your system to activate the installed
 updates.
 
 One of the most inportant advance of Linux over Windows is the
 fact, that there are only a few situations - like kernel updates -
 which requires a reboot of your system.

In fact, this cause various subtles issues :
http://neugierig.org/software/chromium/notes/2011/08/zygote.html

I do see mysterious crash from time to time due to upgrade.
 This feature is inpractical of server systems where you want to
 avoid reboots to minimizize downtimes.

Then you can still use yum update to do it instead of doing it with
packagekit and systemd.

-- 
Michael Scherer

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ARM is a dead end

2012-06-16 Thread Richard W.M. Jones

On Fri, Jun 15, 2012 at 06:42:45AM +0200, tim.laurid...@gmail.com wrote:
 On Fri, Jun 15, 2012 at 1:57 AM, Kevin Kofler kevin.kof...@chello.atwrote:
 
  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.
 
 Kevin Kofler
 
  --
  devel mailing list
  devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/devel
 
 
 troll mode
 Why do we waste time on Linux, when we all just can use Windows, the
 desktop market leader 
 /troll mode
 
 Linux is about choices and is driven by people by by people with passions
 for something, even if not what every body else think is importent.
 So telling people to don't waste time on something they care about, Is
 wrong in so many ways.

Damn right!  I'm running Linux (not Fedora, sadly) on my OpenRISC FPGA.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F16: Sandy Bridge - lags, missing effects, ui-crashes

2012-06-16 Thread Reindl Harald



Am 16.06.2012 14:55, schrieb Roberto Ragusa:
 On 05/29/2012 11:29 PM, Reindl Harald wrote:
 
 the follwoing params making things better and stop especially
 the lags most of the time, but on the same machine over a long
 time was set to pcie_aspm=force and all i915 option at 1

 pcie_aspm=off i915.i915_enable_rc6=0 i915.semaphores=0 
 i915.i915_enable_fbc=0

 i think i have to mention taht VT-d is active in the BIOS and
 i was wondering that it was stable because the combination of the
 i915 options with VT-d (hardware supported virtualization IO) is
 classified to be unstable
 
 No issues for a couple of weeks, after disabling VT-d in the BIOS,
 but there were kernel updates too, in the meantime.
 (And I now expect the problem to show up immediately
 after sending this mail) :-)

in the meantime upgraded to F17 and Kernel 3.4
currently all fine again - knock on wood



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

2012-06-16 Thread Reindl Harald



Am 16.06.2012 14:57, schrieb Jochen Schmitt:
 On Fri, Jun 15, 2012 at 05:15:53PM -0600, Kevin Fenzi wrote:
 
 #topic ticket 869 F18 Feature: Offline Updates using systemd and
 packagekit -
 https://fedoraproject.org/wiki/Features/OfflineSystemUpdates 


 Owner
 Name: Richard Hughes Lennart Poettering

Make updating of system components more reliable by doing it in an minimal,
controlled environment.

the next have solution, searching problem of Lennart?
hopefully this leads not sooner or later in uncareful
designs where it get more and more a must

after around 400 fedora DIST-Upgrades - who needs this?
better fixing systemd taht VMwareWorkstation suspends running
VM's as reliable as before Fedora 15

 The system update mode is implemented by booting into a special target.
 The target installs the downloaded  updates and then reboots back into
 the regular default target.
 For more details, see 
 http://freedesktop.org/wiki/Software/systemd/SystemUpdates

 Note that this feature does not prevent you from using yum and other 
 commandline
 tools to install updates whenever you want to. We also differentiate 
 updates of
 'OS components' (which we want to do in this offline fashion) from 
 application
 updates and installations, which should still be possible from the UI 
 without
 restarting the system.



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

2012-06-16 Thread Reindl Harald



Am 16.06.2012 15:06, schrieb Ralf Ertzinger:
 Hi.
 
 On Sat, 16 Jun 2012 14:57:30 +0200, Jochen Schmitt wrote
 
 One of the most inportant advance of Linux over Windows is the
 fact, that there are only a few situations - like kernel updates -
 which requires a reboot of your system.
 
 Linux has, in principle, the same problem as Windows, that while
 you can replace files that are in use running processes will (of course)
 not pick up the changes until restarted. 

this is not the problem in windows
the problem in windows is that you CAN NOT replace a open file

 Most daemons do so when updated themselves

which is a really bad behavior on production systems
and was introduced not soo long ago with no way to disable
this systemwide because each package has this restart crap

 but, for example, updating zlib because of an exploit will
 not restart all daemons using the exploitable library, so unless the
 admin restarts those manually or the system is rebooted you might
 still be vulnerable.

yes you have to restart the services
but at a time YOU decide and controlled

without any dumb restarts you can rollout testsed updates
at business-time and do the restarts ina small time window

 MS has choosen the reboot route to deal with this, and current versions
 leave it up to the user to initiate the reboot while nagging about
 it in regular intervals (which Fedora does not do, and I'm not sure
 this is a good thing tbh).

no, no and again: no

microsoft has chosen this way because windows can not replace
open files and so you can not compare linux and windows here
in any way



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 17 ARM Release Candidate VFAD results - Follow up VFAD on Monday June 18th

2012-06-16 Thread Brendan Conoboy


On 06/15/2012 05:25 PM, Paul Whalen wrote:

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


If anybody wants to get a jump on Monday's testing the latest nightlies 
have fixes for all blockers from yesterday's RC1.  The images can be 
retrieved from:


http://scotland.proximity.on.ca/arm-nightlies/

Cheers,

--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Revelation password manager issue

2012-06-16 Thread Jon Ciesla

On Fri, Jun 15, 2012 at 4:18 PM, Chris Murphy li...@colorremedies.com wrote:

 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?

Sorry, I was being unintentionally vague.  No, TFA and BBKDF2 are
great.  I want something with *only* offline access, and no
cross-machine sync.  Both lastpass and keepassx encrypt locally, but I
can verify that by looking at keepassx's source.  I just can't quite
make myself put my passwords in anything stored online, and if someone
can't trust me with their code, I certainly can't trust them with my
passwords. :)

But that's me. ;)

-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: *countable infinities only

2012-06-16 Thread Richard Vickery

On Tue, Jun 12, 2012 at 7:58 AM, Jay Sulzberger j...@panix.com wrote:

On Tue, 12 Jun 2012, drago01 drag...@gmail.com wrote:

On Tue, Jun 12, 2012 at 12:11 PM, Nicu Buculei nicu_fed...@nicubunu.ro
wrote:
On 06/12/2012 12:58 PM, drago01 wrote:

On Tue, Jun 12, 2012 at 9:44 AM, Nicu Buculei wrote:

The point is we have a target audience:
http://fedoraproject.org/wiki/**User_basehttp://fedoraproject.org/wiki/User_base

Our desired users ARE contributors.

We do have a mission as well:
http://fedoraproject.org/wiki/**Overview#Our_Missionhttp://fedoraproject.org/wiki/Overview#Our_Mission

The Fedora Project consistently seeks to create, improve, and spread
free/libre code and content.

And Bingo! the mission is all about freedom.

I didn't deny that.

Which you don't do by excluding users ... sure we want to gain new
contributors but that does not mean that we should exclude other
users.

Not if it affects our freedom, is a problem of freedom versus
convenience.

No because secure boot does not limit your freedom in *any* way. If
you want to hack on the kernel or other low level stuff flip a switch
in the firmware.
It is reasonable to expect this type of users to be able to do that.

Up until now, installing a free OS did not require the extra
moves, which Fedora admits are irksome. If Microsoft succeeds in
imposing Microsoft Root Control, then it becomes even harder to
install free software, as compared to running a Microsoft OS
which is already loaded on the box at point of sale. If we let
them, Microsoft will have erected yet another barrier to running
free software.

ad diction: SecureBoot does not mean secure boot in the
situation where a large rich entity hostile to free software
holds the unique key which allows booting on the hardware. To
continue to call the arrangement under which Microsoft holds the
root key to the hardware SecureBoot is inaccurate. If any
Fedora developer uses the term without explanation of its real
meaning, that developer suggests to those listening, that the
developer thinks that Microsoft holding the root key is more
secure than Fedora holding the root key, or the owner of the
hardware holding the root key.

It is ridiculous to use a term invented by Microsoft to mislead
people who do not understand that SecureBoot means Root Control
by Microsoft.

If spreading to some users means losing some freedom, then I think that
is
against the mission.

We are not loosing any freedom we are implementing a technology that
makes fedora work out of the box on newer hardware.

No, if we have to beg Microsoft for permission to conveniently
install Fedora, we have lost our freedom to conveniently, without
asking permission of Microsoft, install Fedora. Why should we
beg Microsoft for a power which last month we had, and which
Microsoft has seized to itself?

Of course the actions by Microsoft are against anti-trust law in
the US and in Europe grossly violate the rule against tying of
software and hardware. And claiming Why you could pirouette and
do a handspring backwards, and if Microsoft agrees, then you can
install Fedora, so there is no extra bar to installation. is
incorrect. Before now we did not have to do the pirouette and
handspring. Before the New Microsoft Regime of Booting, we did
not have to beg Microsoft to sign our keys.

No. Our side must here stand and fight.

oo--JS.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel

(The following reply contains language that may be offensive to some
readers (a swear word). Reader discretion is advised)

Why do we need to bring Microsoft into this, much less listen to, or
communicate with them? Forget about them. Our fight may be with them, but
if we let them continue on their merry way, they will most certainly
fail. What we need to do is let the broader public know that there are
better options available - perhaps leaving out the term better because it
may give Micro-shit (my own term for Microsoft) something to fight against.
Is there some kind of commercial that we could put out to ask people to try
it out?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

LLVM [Was: julia language]

2012-06-16 Thread Andrew Haley

On 06/14/2012 10: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.

I'm interested in your experience with LLVM.  We used it to create the
Shark Java VM, but we had a lot of difficulty with LLVM JIT stability
on non-x86 targets.  If LLVM is looking healthier it might be
interesting to revisit Shark, which essentially combines HotSpot and
LLVM to create a portable JVM.

Andrew.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

2012-06-16 Thread Kevin Kofler

Kevin Fenzi wrote:
 #topic ticket 868 F18 Feature: MiniDebugInfo -
 https://fedoraproject.org/wiki/Features/MiniDebugInfo
 .fesco 868

I really hope this is rejected. As already discussed in the relevant thread, 
it would add bloat to the live images which would force us to drop useful 
software from the KDE spin to fit the size target. And for what gain? We 
have -debuginfo packages, we have ways to auto-install them when needed, and 
we even have the Retrace Server.

I shall also point out that the percentages given for the size increase are 
very misleading, because they are for (xz-)compressed debugging information 
vs. uncompressed executables. But on the live images, EVERYTHING is xz-
compressed. And of course already xz-compressed data will not compress any 
further with another xz run. So 43 MiB of xz-compressed symbols means a live 
image size increase of 6.14%! That is HUGE, and will require dropping a lot 
of other things to compensate for.

IMHO, it is just plain unacceptable that this feature is being pushed 
through by its submitter without any regard to the live images, and I 
strongly hope FESCo will block this.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

2012-06-16 Thread drago01

On Sat, Jun 16, 2012 at 11:58 PM, Kevin Kofler kevin.kof...@chello.at wrote:
 Kevin Fenzi wrote:
 #topic ticket 868 F18 Feature: MiniDebugInfo -
 https://fedoraproject.org/wiki/Features/MiniDebugInfo
 .fesco 868

 I really hope this is rejected. As already discussed in the relevant thread,
 it would add bloat to the live images which would force us to drop useful
 software from the KDE spin to fit the size target.

Well as I said in the other thread ... we are in 2012 there is *no*
reason why we should be restricted by a medium from the 90s.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

2012-06-16 Thread Chris Murphy


On Jun 16, 2012, at 12:17 PM, Richard Vickery wrote:
 
 Why do we need to bring Microsoft into this, much less listen to, or 
 communicate with them? Forget about them.

Ahh, the Ostrich Maneuver. 

Had this been the policy of others working on this issue, Microsoft would not 
have updated their Windows 8 certification to require the user be able to 
disable Secure Boot. And then we'd all be in a significantly worse position. So 
congratulations on locating a really hideously bad idea, one that actually 
supports the original Microsoft position.


 Our fight may be with them, but if we let them continue on their merry way, 
 they will most certainly fail.

Fortunately people making informed decisions aren't so passive aggressive. 
Waiting for shit to hit the fan, and then using sprayed feces over everyone as 
justification for more shit flinging is about as stupid an idea as I've read in 
this thread. Yeah, great idea. Let's get pissy, but do nothing, wait for a net 
worse policy to develop that affects everyone, and then do nothing but get 
pissed off, bitch, and whine about it.


 What we need to do is let the broader public know that there are better 
 options available

Please provide an example of a better option, with sufficient detail as to 
constitute a successful relay of the baton.

The point of the thread from the outset was to explore alternatives, but so far 
those alternatives are vaporware.

Chris Murphy-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

2012-06-16 Thread Gregory Maxwell

On Sat, Jun 16, 2012 at 7:14 PM, Chris Murphy li...@colorremedies.com wrote:
 Ahh, the Ostrich Maneuver.

 Had this been the policy of others working on this issue, Microsoft would
 not have updated their Windows 8 certification to require the user be able
 to disable Secure Boot. And then we'd all be in a significantly worse
 position. So congratulations on locating a really hideously bad idea, one
 that actually supports the original Microsoft position.

Or, perhaps, they would have found themselves behind the gun-sights of
the DOJ again and dropped the whole thing in order to avoid years of
costly antitrust litigation.  (Or do you think they would have backed
off at all, just because someone asked, if they didn't think that risk
was at least somewhat credible?)

Hypotheticals are like that. Who knows?

Certainly people who are of the opinion that Fedora shouldn't run on
devices that need signed kernels aren't going to be convinced that
gaining the ability to make that choice was a big improvement.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

2012-06-16 Thread Chris Murphy


On Jun 16, 2012, at 5:44 PM, Gregory Maxwell wrote:

 Or, perhaps, they would have found themselves behind the gun-sights of
 the DOJ again and dropped the whole thing in order to avoid years of
 costly antitrust litigation.  (Or do you think they would have backed
 off at all, just because someone asked, if they didn't think that risk
 was at least somewhat credible?)

Calls for speculation. We know what the certification policy used to be. We 
also know how long DOJ takes to do anything, let alone politicking behind the 
scenes to arrive at compromise, let alone its day in court. Years. Generations 
of computers without a disable feature.

No, but in the view of a handful, it's better for the entire community to 
experience this pain, for years, in order to arrive at some asinine conclusion 
that XX is the source of all evil in the computing world. Then all would be 
right as rain, unified tribal behavior against an enemy that some people 
thought could be negotiated with.

This handful are the people who use adversarial words like: fight, war, battle, 
attack, surrender, engagement, tactical, etc. to describe this topic. This 
verbiage is the hallmark of propaganda, designed to cause emotive reactions in 
people, so they don't consider inconvenient things like facts.

 
 Certainly people who are of the opinion that Fedora shouldn't run on
 devices that need signed kernels aren't going to be convinced that
 gaining the ability to make that choice was a big improvement.

Oh, the same people who must think boot loader malware is somewhere in the 
continuum of people's imaginations to being exclusively a Windows threat.

The Windows 8 certification is the most significant change in Microsoft's 
hardware requirements ever, as far as I can tell. It's a significant departure 
from their support legacy at most any cost position prior to this. Clearly 
they are more than a bit concerned about boot loader malware than they are 
gaining, what, 1%, by obliterating the entirety of desktop Linux with this 
conspiracy.


Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

2012-06-16 Thread Gregory Maxwell

On Sat, Jun 16, 2012 at 8:16 PM, Chris Murphy li...@colorremedies.com wrote:
 Calls for speculation. We know what the certification policy used to be. We 
 also know how long DOJ takes to do anything, let alone politicking behind the 
 scenes to arrive at compromise, let alone its day in court. Years. 
 Generations of computers without a disable feature.

Good job selectively quoting the part of my message where I was saying
that it was a call for speculation either way.

 This handful are the people who use adversarial words like: fight, war, 
 battle, attack, surrender, engagement, tactical, etc. to describe this topic. 
 This verbiage is the hallmark of propaganda, designed to cause emotive 
 reactions in people, so they don't consider inconvenient things like facts.

I certainly have not done this and by using this argument against me I
feel you're guilty of the same:  It appears to me that you're
suggesting that I'm somehow asscoiated with propaganda (an
emotionally laden word too) and that people should not bother with an
inconvenient thing like contemplating my position.

 Oh, the same people who must think boot loader malware is somewhere in the 
 continuum of people's imaginations to being exclusively a Windows threat.

Except, as I argued early in these thread, for Fedora the
cryptographic lockdown will not meaningfully inhibit boot _time_
malware.  If malware can exploit your kernel to infect the bootloader
so that the kernel rootkit is reinstalled at every boot to prevent
updates from removing it then it can just as well infect systemd to
the exact same end.  It only helps if the whole system runs no
unsigned code at least upto the point where it connects to the
internet and gets updates.

There are a great many things Fedora could do which would have clear
security benefit without the compromises. Where is the effort to fully
seccomp-2 restrict and/or SELinux lockdown every use app that handles
hostile network input, for example.   Closing the door on botnet
software long after the machine is compromised is a pretty weak
security feature and thats the most the signed bootloader/kernel can
offer, and even that requires signing up half the userspace too.

 The Windows 8 certification is the most significant change in Microsoft's 
 hardware requirements ever, as far as I can tell. It's a significant 
 departure from their support legacy at most any cost position prior to 
 this. Clearly they are more than a bit concerned about boot loader malware 
 than they are gaining, what, 1%, by obliterating the entirety of desktop 
 Linux with this conspiracy.

Old hardware will continue to run Windows 8. I don't see that I've
seen any evidence of Microsoft adopting policy to ensure that new
hardware would continue to run Windows, are you saying they have?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: redhat-rpm-config and rpm-build (fwd)

2012-06-16 Thread Paul Wouters


On Fri, 15 Jun 2012, Ralf Corsepius wrote:


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.


Then add redhat-rpm-config as a buildrequire for all fedora packages.
(though that might be a catch22)


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.


Someone building non-fedora/non-epel rpms should be expected to create
their own version of foo-rpm-config that satisfies/obsoletes the same
dependancy as redhat-rpm-config.


Surely most people have it installed anyway.

Well, fedora packagers will have it installed, because
fedora-packager pulls it in.


group names are no replacements for proper dependancies. People who
build rpms need to be able to yum install rpmbuild and get a working
setup. They should not need to spend an hour googling on why their
debuginfo packages don't get build.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

2012-06-16 Thread Jay Sulzberger




On Sat, 16 Jun 2012, Chris Murphy li...@colorremedies.com wrote:



On Jun 16, 2012, at 12:17 PM, Richard Vickery wrote:


Why do we need to bring Microsoft into this, much less listen to, or 
communicate with them? Forget about them.


Ahh, the Ostrich Maneuver.

Had this been the policy of others working on this issue, Microsoft would not 
have updated their Windows 8 certification to require the user be able to 
disable Secure Boot. And then we'd all be in a significantly worse position. So 
congratulations on locating a really hideously bad idea, one that actually 
supports the original Microsoft position.



Our fight may be with them, but if we let them continue on their merry way, 
they will most certainly fail.


Fortunately people making informed decisions aren't so passive aggressive. 
Waiting for shit to hit the fan, and then using sprayed feces over everyone as 
justification for more shit flinging is about as stupid an idea as I've read in 
this thread. Yeah, great idea. Let's get pissy, but do nothing, wait for a net 
worse policy to develop that affects everyone, and then do nothing but get 
pissed off, bitch, and whine about it.



What we need to do is let the broader public know that there are better options 
available


Please provide an example of a better option, with sufficient detail as to 
constitute a successful relay of the baton.

The point of the thread from the outset was to explore alternatives, but so far 
those alternatives are vaporware.

Chris Murphy


I have made several suggestions.

If you want, read them and tell me what you think.

Thank you!

oo--JS.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Heads-up: Twisted-12.1.0 landing in rawhide

2012-06-16 Thread Julian Sikorski

Dear all,

I have just submitted python-twisted* 12.1.0 builds for rawhide. Please
check if everything still works as intended.

Regards,
Julian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Replacing grubby with grub2-mkconfig in kernel install process

2012-06-16 Thread Ben Rosser

In Fedora 17, when you install grub2 and generate a fresh config file, that
config is produced by grub2-mkconfig. However, when you install a kernel
update, the kernel's entry is added to the grub2 boot menu by grubby.

This produces messy grub boot menus. The entries added by grubby read
something like Fedora (%kernel_version). grub2-mkconfig, on the other
hand, only displays one Fedora Linux boot option and places the other
kernels and their recovery mode environments in a submenu called Advanced
Options.

Now, I never really liked seeing three kernels on the main menu to begin
with, and I think the new grub2 approach of hiding the other kernels in a
submenu is nice. But then as soon as I start installing updates the submenu
becomes incomplete (and eventually useless, as the new kernels won't be
listed there) and the grubby options take over the menu.

It seems to me that we should make the boot menu more consistent somehow. I
feel like the simplest solution is just to run grub2-mkconfig at every
kernel update, and stop using grubby for this. Then everything would look
consistent- the Fedora Linux boot option would have the latest kernel
and all kernels would always be listed under the submenu. (As far as I
know, this would just be a change to the kernel specfile, right?).

Alternatively, if Fedora does want boot menus that look like the ones
produced by grubby, then the grub2 default configuration should be changed
to reflect that, so the boot menu will always look consistent.

I should add that I did see a reference to possibly replacing grubby with a
grub-updconf (though I'm not aware of such a program) on the wiki-
http://fedoraproject.org/wiki/Features/Grub2 - so possibly there are
already plans for this?

Ben
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: redhat-rpm-config and rpm-build (fwd)

2012-06-16 Thread TASAKA Mamoru


Paul Wouters wrote, at 06/17/2012 09:46 AM +9:00:

On Fri, 15 Jun 2012, Ralf Corsepius wrote:


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.


Then add redhat-rpm-config as a buildrequire for all fedora packages.
(though that might be a catch22)


I guess you know this:
https://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2




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.


Someone building non-fedora/non-epel rpms should be expected to create
their own version of foo-rpm-config that satisfies/obsoletes the same
dependancy as redhat-rpm-config.


Surely most people have it installed anyway.

Well, fedora packagers will have it installed, because
fedora-packager pulls it in.


group names are no replacements for proper dependancies. People who
build rpms need to be able to yum install rpmbuild and get a working
setup. They should not need to spend an hour googling on why their
debuginfo packages don't get build.


Same as above.

Regards,
Mamoru


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

2012-06-16 Thread Bruno Wolff III


On Sat, Jun 16, 2012 at 23:58:03 +0200,
  Kevin Kofler kevin.kof...@chello.at wrote:


I really hope this is rejected. As already discussed in the relevant thread,
it would add bloat to the live images which would force us to drop useful
software from the KDE spin to fit the size target. And for what gain? We


Be aware that there is a plan to switch to livemedia-creator for F18. That 
does things a bit differently and may have an effect on the size of the 
images. (I don't know whether they will be larger or smaller, but expect 
some change.)

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 832644] New: abi-compliance-checker-1.98.0 is available

2012-06-16 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=832644

Bug ID: 832644
  Keywords: FutureFeature, Triaged
QA Contact: extras...@fedoraproject.org
  Severity: unspecified
   Version: rawhide
  Priority: unspecified
CC: hobbes1...@gmail.com, or...@cora.nwra.com,
perl-devel@lists.fedoraproject.org
  Assignee: hobbes1...@gmail.com
   Summary: abi-compliance-checker-1.98.0 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.98.0
Current version in Fedora Rawhide: 1.97.8
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

[Bug 789557] perl-Bio-Graphics-2.29 is available

2012-06-16 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=789557

--- Comment #2 from Upstream Release Monitoring 
upstream-release-monitor...@fedoraproject.org ---
Latest upstream release: 2.29
Current version in Fedora Rawhide: 2.25
URL: http://search.cpan.org/dist/Bio-Graphics/

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

[Bug 832661] New: perl-DateTime-Format-Flexible-0.23 is available

2012-06-16 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=832661

Bug ID: 832661
  Keywords: FutureFeature, Triaged
QA Contact: extras...@fedoraproject.org
  Severity: unspecified
   Version: rawhide
  Priority: unspecified
CC: mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
psab...@redhat.com
  Assignee: ppi...@redhat.com
   Summary: perl-DateTime-Format-Flexible-0.23 is available
Regression: ---
  Story Points: ---
Classification: Fedora
OS: Unspecified
  Reporter: upstream-release-monitor...@fedoraproject.org
  Type: ---
 Documentation: ---
  Hardware: Unspecified
Mount Type: ---
Status: NEW
 Component: perl-DateTime-Format-Flexible
   Product: Fedora

Latest upstream release: 0.23
Current version in Fedora Rawhide: 0.22
URL: http://search.cpan.org/dist/DateTime-Format-Flexible/

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

[Bug 832663] New: perl-IO-Socket-IP-0.12 is available

2012-06-16 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=832663

Bug ID: 832663
  Keywords: FutureFeature, Triaged
QA Contact: extras...@fedoraproject.org
  Severity: unspecified
   Version: rawhide
  Priority: unspecified
CC: mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, psab...@redhat.com
  Assignee: psab...@redhat.com
   Summary: perl-IO-Socket-IP-0.12 is available
Regression: ---
  Story Points: ---
Classification: Fedora
OS: Unspecified
  Reporter: upstream-release-monitor...@fedoraproject.org
  Type: ---
 Documentation: ---
  Hardware: Unspecified
Mount Type: ---
Status: NEW
 Component: perl-IO-Socket-IP
   Product: Fedora

Latest upstream release: 0.12
Current version in Fedora Rawhide: 0.11
URL: http://search.cpan.org/dist/IO-Socket-IP/

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

[Bug 832665] New: perl-Perl-Critic-Pulp-72 is available

2012-06-16 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=832665

Bug ID: 832665
  Keywords: FutureFeature, Triaged
QA Contact: extras...@fedoraproject.org
  Severity: unspecified
   Version: rawhide
  Priority: unspecified
CC: mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Assignee: ppi...@redhat.com
   Summary: perl-Perl-Critic-Pulp-72 is available
Regression: ---
  Story Points: ---
Classification: Fedora
OS: Unspecified
  Reporter: upstream-release-monitor...@fedoraproject.org
  Type: ---
 Documentation: ---
  Hardware: Unspecified
Mount Type: ---
Status: NEW
 Component: perl-Perl-Critic-Pulp
   Product: Fedora

Latest upstream release: 72
Current version in Fedora Rawhide: 71
URL: http://search.cpan.org/dist/Perl-Critic-Pulp/

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

[Bug 832667] New: perl-podlinkcheck-9 is available

2012-06-16 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=832667

Bug ID: 832667
  Keywords: FutureFeature, Triaged
QA Contact: extras...@fedoraproject.org
  Severity: unspecified
   Version: rawhide
  Priority: unspecified
CC: mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Assignee: ppi...@redhat.com
   Summary: perl-podlinkcheck-9 is available
Regression: ---
  Story Points: ---
Classification: Fedora
OS: Unspecified
  Reporter: upstream-release-monitor...@fedoraproject.org
  Type: ---
 Documentation: ---
  Hardware: Unspecified
Mount Type: ---
Status: NEW
 Component: perl-podlinkcheck
   Product: Fedora

Latest upstream release: 9
Current version in Fedora Rawhide: 8
URL: http://search.cpan.org/dist/podlinkcheck/

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

[Bug 832668] New: perl-Text-CSV_XS-0.90 is available

2012-06-16 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=832668

Bug ID: 832668
  Keywords: FutureFeature, Triaged
QA Contact: extras...@fedoraproject.org
  Severity: unspecified
   Version: rawhide
  Priority: unspecified
CC: mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org
  Assignee: mmasl...@redhat.com
   Summary: perl-Text-CSV_XS-0.90 is available
Regression: ---
  Story Points: ---
Classification: Fedora
OS: Unspecified
  Reporter: upstream-release-monitor...@fedoraproject.org
  Type: ---
 Documentation: ---
  Hardware: Unspecified
Mount Type: ---
Status: NEW
 Component: perl-Text-CSV_XS
   Product: Fedora

Latest upstream release: 0.90
Current version in Fedora Rawhide: 0.88
URL: http://search.cpan.org/dist/Text-CSV_XS/

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

File CGI-Application-Plugin-ValidateRM-2.5.tar.gz uploaded to lookaside cache by eseyman

2012-06-16 Thread Emmanuel Seyman

A file has been added to the lookaside cache for 
perl-CGI-Application-Plugin-ValidateRM:

529ed1a5ae534fb5429eb0cde041b0ae  CGI-Application-Plugin-ValidateRM-2.5.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

90 matches

Mail list logo