Re: bodhi 0.9.3 deployed to production
On Thu, 2012-11-15 at 06:31 +, Peter Robinson wrote: > > Still, even in RHEL's policy, CURRENTRELEASE is clearly wrong for a > > straightforward 'this was a bug that got fixed and we pushed an update' > > case, so I don't know why people are suddenly plumping for it, other > > than that it somehow 'sounds right'. > > Unless it's a bugfix that is pushed to multiple releases and the one > your after isn't the one that made it stable first at which point > errata IMO makes slightly more sense. After all in our case > CURRENTRELEASE changes roughly every 6 months so it becomes a moving > target. In RHEL CR makes more sense because it would be the current > dot release in the X cycle, where X is 4/5/6/7 etc. CURRENTRELEASE is clearly only for niche cases by both the RHEL and Fedora definitions. RHEL: "CURRENTRELEASE - The problem described has been fixed and only ever appeared in unsupported or unreleased products." Fedora: "The resolution CURRENTRELEASE is to be used in the case where a bug is reported before a release is made, and subsequently discovered to be fixed in the final release. For instance, a bug is reported against Fedora 18 while it is still in the pre-release stages, and remains open when the release is made; however, when the final Fedora 18 is made, the reporter re-tests and discovers the bug was actually fixed. In this case, the CURRENTRELEASE resolution is used." Both of those make it pretty clear it's only to be used in specific, fairly unusual circumstances, not as the routine resolution for a bug filed through Bugzilla, accepted by the maintainer, and fixed in the normal course of events. (Though I think the name is a bit confusing if you're just trying to figure out what resolution to use based on the names alone). ERRATA is the 'correct' resolution for that case for both RHEL (post-release at least) and Fedora (post-Branched). -- 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: bodhi 0.9.3 deployed to production
On Thu, Nov 15, 2012 at 6:15 AM, Adam Williamson wrote: > On Thu, 2012-11-15 at 05:52 +0100, Kevin Kofler wrote: >> Luke Macken wrote: >> > A new bugfix release of Bodhi has just been deployed to production. >> > >> > https://admin.fedoraproject.org/updates >> > >> > Bugs and enhancement requests can be filed here: >> > >> > http://bodhi.fedorahosted.org >> >> This seems to be closing bugs as CURRENTRELEASE rather than ERRATA now, is >> that intentional? If yes, why? > > There seems to be a mania for CURRENTRELEASE lately. I don't know where > it's coming from. > > The policy clearly states ERRATA: > > https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#CLOSED > > Now admittedly the policy is more or less something I pulled out of my > ass a few years ago and I have my suspicions as to how many people a) > have ever read it (few) or b) care (fewer). But hey, it's there. > > In the end we rarely do anything with the resolutions anyway, so I > stopped caring as much as I used to, but at least our official tools > should probably follow what are nominally our policies. > > Note that Fedora's policy differs *significantly* from Red Hat's here, > as Fedora's update workflow is entirely different from RHEL's. > https://bugzilla.redhat.com/page.cgi?id=fields.html - the 'help' page > you get by clicking on various bits of a bug page - is RHEL's policy, > not Fedora's. There is a link to the Fedora policy at the top of it. > Unfortunately, most of the links to the fields.html page jump into the > middle of it with anchors, so no-one sees the link. > > The other problem with our policy is that it's somewhat of a hack job, > because it involves taking the resolutions that were written for RHEL's > update process and make sense in that context and applying them the > Fedora update process, in which context they really don't make sense at > all. So several of the choices are just arbitrary decisions I made when > I was writing the smegging thing. This is of course one of the drawbacks > of sharing a bug tracker with RHEL, but then the point is always made > that the effort of having our own would outweigh the benefits. > > Still, even in RHEL's policy, CURRENTRELEASE is clearly wrong for a > straightforward 'this was a bug that got fixed and we pushed an update' > case, so I don't know why people are suddenly plumping for it, other > than that it somehow 'sounds right'. Unless it's a bugfix that is pushed to multiple releases and the one your after isn't the one that made it stable first at which point errata IMO makes slightly more sense. After all in our case CURRENTRELEASE changes roughly every 6 months so it becomes a moving target. In RHEL CR makes more sense because it would be the current dot release in the X cycle, where X is 4/5/6/7 etc. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bodhi 0.9.3 deployed to production
On Thu, 2012-11-15 at 05:52 +0100, Kevin Kofler wrote: > Luke Macken wrote: > > A new bugfix release of Bodhi has just been deployed to production. > > > > https://admin.fedoraproject.org/updates > > > > Bugs and enhancement requests can be filed here: > > > > http://bodhi.fedorahosted.org > > This seems to be closing bugs as CURRENTRELEASE rather than ERRATA now, is > that intentional? If yes, why? There seems to be a mania for CURRENTRELEASE lately. I don't know where it's coming from. The policy clearly states ERRATA: https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#CLOSED Now admittedly the policy is more or less something I pulled out of my ass a few years ago and I have my suspicions as to how many people a) have ever read it (few) or b) care (fewer). But hey, it's there. In the end we rarely do anything with the resolutions anyway, so I stopped caring as much as I used to, but at least our official tools should probably follow what are nominally our policies. Note that Fedora's policy differs *significantly* from Red Hat's here, as Fedora's update workflow is entirely different from RHEL's. https://bugzilla.redhat.com/page.cgi?id=fields.html - the 'help' page you get by clicking on various bits of a bug page - is RHEL's policy, not Fedora's. There is a link to the Fedora policy at the top of it. Unfortunately, most of the links to the fields.html page jump into the middle of it with anchors, so no-one sees the link. The other problem with our policy is that it's somewhat of a hack job, because it involves taking the resolutions that were written for RHEL's update process and make sense in that context and applying them the Fedora update process, in which context they really don't make sense at all. So several of the choices are just arbitrary decisions I made when I was writing the smegging thing. This is of course one of the drawbacks of sharing a bug tracker with RHEL, but then the point is always made that the effort of having our own would outweigh the benefits. Still, even in RHEL's policy, CURRENTRELEASE is clearly wrong for a straightforward 'this was a bug that got fixed and we pushed an update' case, so I don't know why people are suddenly plumping for it, other than that it somehow 'sounds right'. -- 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: [@core] working definition for the minimal package set
On Wed, 2012-11-14 at 22:23 -0500, Scott Schmit wrote: > On Wed, Nov 14, 2012 at 09:36:17AM -0500, Matthew Miller wrote: > > Based on the conversation so far, I think the target is: > > > > - mandatory install of everything up to yum install from the network > > - default install of a small set of packages necessary for a consistent > > Fedora experience including minimal admin tools > > Is there any reason those two can't be split up? Maybe @really-hard-core > for the first, and @core for the second. ;-) That's basically what Kevin proposed several mails back, and I agree it seems like we have two broadly definable cases here rather than one. -- 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: [@core] working definition for the minimal package set
On Wed, 2012-11-14 at 18:49 -0800, M. Edward (Ed) Borasky wrote: > On Wed, Nov 14, 2012 at 6:02 PM, Adam Williamson wrote: > > On Wed, 2012-11-14 at 16:27 -0800, M. Edward (Ed) Borasky wrote: > >> On Tue, Nov 13, 2012 at 9:59 PM, Ian Pilcher wrote: > >> > On 11/13/2012 06:55 PM, Adam Williamson wrote: > >> >> It might be worth re-evaluating whether that's realistic any more, > >> >> though, and whether we're _really_ committed to finally replacing > >> >> network with NM in some kind of reasonable timeframe. > In the current context, a minimal Fedora, I'd argue that > NetworkManager is overkill too. We're going round in circles, here. The post of mine quoted above - five levels of quotation deep, 11/13/2012 - was a reply to someone saying the same thing. Please just read back to there, and break us out of this eternal loop. :) -- 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: bodhi 0.9.3 deployed to production
Luke Macken wrote: > A new bugfix release of Bodhi has just been deployed to production. > > https://admin.fedoraproject.org/updates > > Bugs and enhancement requests can be filed here: > > http://bodhi.fedorahosted.org This seems to be closing bugs as CURRENTRELEASE rather than ERRATA now, is that intentional? If yes, why? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, Nov 14, 2012 at 09:36:17AM -0500, Matthew Miller wrote: > Based on the conversation so far, I think the target is: > > - mandatory install of everything up to yum install from the network > - default install of a small set of packages necessary for a consistent > Fedora experience including minimal admin tools Is there any reason those two can't be split up? Maybe @really-hard-core for the first, and @core for the second. ;-) Alternatively, I could see where the first is marked "required", but the second is marked "default" so it can be deselected in a kickstart config without needing to rpm -e it in %post. -- Scott Schmit smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LuaJIT - an alternative for current Python C bindings
On 15.11.2012 04:51, M. Edward (Ed) Borasky wrote: How much Python code are you proposing "someone" ports to Lua? ;-) I am proposing mostly porting C code to Lua/FFI (the code of the problematic Python C bindings) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 15.11.2012 04:32, Kevin Kofler wrote: Unlike the others, it generates the native code at runtime (Just In Time), so there is a performance penalty (especially for nontrivial programs) for the (JIT) compilation which gcc and ocamlopt won't have. The quality of the generated code could also be a problem (for nonempty programs): Optimized compilation takes time! So there's a tradeoff between the time of the JIT compilation and the time of the actual execution, a very fast JIT is not necessarily optimal because it may be missing important optimizations of the compiled code. All above is correct, with the small nuance that all practically significant slowdowns are always result of repeatable code paths (loops, recursions, etc) but these lands to near optimal native code after the first few iterations with this concrete implementation (Mike Pall is well known with his in-depth theoretical background). In other words: Try nontrivial benchmarks before claiming victory. I am. Check GSL shell for example. Nobody claims any victories (especially against gcc). The point is, that this concrete JIT is probably the fastest existing one and brings bunch of advantages at the cost of negligible footprint (compared with v8 for example). Have you played with LuaJIT apps already ... or speaking from common sense POV ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LuaJIT - an alternative for current Python C bindings (was: Re: raising warning flag on firewalld-default feature)
How much Python code are you proposing "someone" ports to Lua? ;-) On Wed, Nov 14, 2012 at 4:49 PM, Alek Paunov wrote: > On 12.11.2012 21:34, Steve Grubb wrote: >> >> >> But the problem I see is a lot of libraries are wrapped by swig, which >> leaks >> memory like a sieve. If swig didn't generate such leaky code, Python >> based >> daemons wouldn't be as scary. >> > > IMHO, Python is one of the best ways to express management logic. As have > stated elsewhere in the thread, from the footprint perspective, python-libs > can be decomposed to something including much smaller python-libs-core. The > remaining problem is the quality of part of the C bindings. Otherwise, it is > great advantage for Fedora that huge part of the system tools are already > polished in Python (my own experience is that the C code in many tools/libs > shipped with Fedora is of relative poor quality, as already Miloslav > explained). > > David Malcolm already has some real results addressing the Python bindings > issues trough static analysis based on his great > gcc-python-plugin/libcpychecker work. In the future, this machinery can be > used for bug free bindings generation too. > > Another option for addressing this is ... to just get rid of part of them in > their current form. > > LuaJIT 2.0 is a reimplementation of Lua scripting language, which has build > the reputation of one of the fastest compilers (comparable only with gcc) in > the course of his 3 years! beta cycle (2.0 final release was announced early > this week) > > The size of luajit.so (interpreter + trace compiler + C parser for the FFI > definitions) is 452088 bytes (on x86_64, for comparison sqlite3.so, which is > a python requirement is 677672) > > Unlike other FFI implementations LuaJIT FFI works compiling the functions > calls/C structs access to native code. Another difference is that the > foreign C definitions are presented in native C syntax: > > http://luajit.org/ext_ffi_tutorial.html#zlib > > On top of this kind of FFI, LuaJIT already have bunch of library bindings - > as instance the kernel ABI wrapper: > > https://github.com/justincormack/ljsyscall > > For a long time already Fedora ships lunatic-python (loading and bridging > the Lua interpreter as python module) > > More recent and feature complete bridge is: > > https://github.com/scoder/lupa > > from the author of lxml module. > > So, to me it seems natural joining all above together to start thinking for > replacing the classic python C bindings with thin textual or bytecode(*) > LuaJIT/FFI shims in benefit of things with great set of dependencies like > Anaconda (thanks to lupa, Lua objects behaves like Python ones in Python). > The result will be order of magnitude easier for maintenance (towards the > APIs evolution) and faster code. > > Furthermore, we can get LuaJIT for free, because it is full API/ABI > compatible with current Fedora (PUC Rio) Lua 5.1, which is pulled by RPM > anyway - we can just replace Lua with LuaJIT as RPM provider for F20. > > Kind Regards, > Alek > > (*) Unlike original Lua, LuaJIT bytecode is portable across architectures. > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing "A weem oh way!" at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, Nov 14, 2012 at 6:02 PM, Adam Williamson wrote: > On Wed, 2012-11-14 at 16:27 -0800, M. Edward (Ed) Borasky wrote: >> On Tue, Nov 13, 2012 at 9:59 PM, Ian Pilcher wrote: >> > On 11/13/2012 06:55 PM, Adam Williamson wrote: >> >> It might be worth re-evaluating whether that's realistic any more, >> >> though, and whether we're _really_ committed to finally replacing >> >> network with NM in some kind of reasonable timeframe. >> > >> > To this point, NetworkManager has failed to gain basic bridge support. >> > In the meantime, Open vSwitch, which has a ton more configuration >> > options has been recently added to the distro. >> > >> > I'd argue that NM actually continues to fall farther behind. >> >> Yeah, I love NetworkManager until it bites me - I've lost count of how >> many times I've been in a coffee shop and had to use 'sudo nmcli con >> del id' to get back online. ;-) > > SCOPE CREEP ALARM! AWOOGA! AWOOGA! > > Unless you actually think the network scripts are a better way of > managing casual wireless connections, I think this is a bit out of > scope, as we can already chalk up 'casual wireless connections' in the > 'win' column for NetworkManager - it's already better than > network.service at that. it may not be *perfect*, but it's *better*. > > The context here is not 'let's all get our NM pet peeves out of our > systems', but 'what does network.service still do better than NM, and > how long is it going to take to fix that?' > -- > 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 In the current context, a minimal Fedora, I'd argue that NetworkManager is overkill too. An openSUSE / SUSE Studio JEOS or server appliance defaults to some kind of DHCP client built on top of whatever the base networking tools are in openSUSE. You have to specifically *ask* for NetworkManager if you want it. I don't even think the bridge tools are included at that minimalist level. You get a firewall, yes, and DHCP too but ssh is optional - you probably have to go in with 'vi' from the console and edit configuration files to make networking happen beyond that. While we're on the subject of minimalism, does yum default to installing "suggested" packages on top of required ones? -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing "A weem oh way!" at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
Alek Paunov wrote: > On 13.11.2012 18:35, Richard W.M. Jones wrote: >> This seems about right to me: Both ocamlopt & gcc generate native >> x86-64 programs, but there's a small amount of overhead in the OCaml >> binary (initializing the minor heap of the GC). >> > > luajit too (it is one of the fastest compilers) Unlike the others, it generates the native code at runtime (Just In Time), so there is a performance penalty (especially for nontrivial programs) for the (JIT) compilation which gcc and ocamlopt won't have. The quality of the generated code could also be a problem (for nonempty programs): Optimized compilation takes time! So there's a tradeoff between the time of the JIT compilation and the time of the actual execution, a very fast JIT is not necessarily optimal because it may be missing important optimizations of the compiled code. In other words: Try nontrivial benchmarks before claiming victory. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 15.11.2012 02:19, Lennart Poettering wrote: For containers a yum group for usage with --installroot= is the only thing that matters. FWIW, For me Anaconda is overkill for the KVM guest images too. I am used to do that with small xquery script (easy for the libvirt domain definition) containing: yum (conf, root) install setup kernel acpid chrony acl attr audit rsyslog dhclient openssh-server openssh-clients rootfiles yum (yum dep-solves the above to 152 packages for F17, x86_64) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Setting the default firewall configuration (was Re: Attention, dependency fighters)
Miloslav Trmač wrote: > Looking at hour original warning flag: Squeezing every last megabyte > out of the running system for cloud is a really new thing that we > haven't historically required. Sure, it would be great to make > firewalld smaller (and rewriting firewalld to C is one of those things > that have been promised a long time ago and never happened), but I > don't really see that as a blocker. The C rewrite should be treated as a requirement for being considered anything other than a prototype. > We'd get the 8-years duplication of init.d/network vs. NetworkManager > all over again, and I personally strongly want to avoid that (this was > a third of my FESCo election platform). Well, I'm not too happy about having 2 ways of doing things either. However, I really don't see the point of running a Python daemon to dynamically control something I never change in the first place. Now, sure, firewalld also does connection tracking and I'd personally have no problems running a lightweight C daemon to handle that, but why on Earth does it have to be in Python? And what about the many system administrators using handwritten rules (see Harald Reindl's reply)? system-config-firewall is a Fedora- specific UI with limited functionality which it makes sense to replace with something more flexible, but iptables rules are a long-established cross- distribution interface, won't firewalld stomp on those rules, by the way it works? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, 2012-11-14 at 16:27 -0800, M. Edward (Ed) Borasky wrote: > On Tue, Nov 13, 2012 at 9:59 PM, Ian Pilcher wrote: > > On 11/13/2012 06:55 PM, Adam Williamson wrote: > >> It might be worth re-evaluating whether that's realistic any more, > >> though, and whether we're _really_ committed to finally replacing > >> network with NM in some kind of reasonable timeframe. > > > > To this point, NetworkManager has failed to gain basic bridge support. > > In the meantime, Open vSwitch, which has a ton more configuration > > options has been recently added to the distro. > > > > I'd argue that NM actually continues to fall farther behind. > > Yeah, I love NetworkManager until it bites me - I've lost count of how > many times I've been in a coffee shop and had to use 'sudo nmcli con > del id' to get back online. ;-) SCOPE CREEP ALARM! AWOOGA! AWOOGA! Unless you actually think the network scripts are a better way of managing casual wireless connections, I think this is a bit out of scope, as we can already chalk up 'casual wireless connections' in the 'win' column for NetworkManager - it's already better than network.service at that. it may not be *perfect*, but it's *better*. The context here is not 'let's all get our NM pet peeves out of our systems', but 'what does network.service still do better than NM, and how long is it going to take to fix that?' -- 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: remove polkit from core?
On Thu, 2012-11-15 at 02:10 +0100, Lennart Poettering wrote: > On Sat, 10.11.12 09:26, Richard W.M. Jones (rjo...@redhat.com) wrote: > > > On Sat, Nov 10, 2012 at 02:33:53AM +0100, Kevin Kofler wrote: > > > Matthew Miller wrote: > > > > Apparently the new version of polkit brings in javascript. The js > > > > package > > > > is 6.5MB. I think anything that uses polkit will depend on it -- can we > > > > remove it from core? > > > > > > Of course, the real question is why the heck PolicyKit needs a Turing- > > > complete rule language (which also forced everyone to port their existing > > > rules) when the previously-used simple INI-style pkla rule format did the > > > job just fine! > > > > And Unix groups worked OK before that (and still do for the majority > > of purposes). > > OK, I'll bite. So: Did they really? > > If you want to allow a user to execute a specific privileged operation > once (let's say format a USB stick), and you grant him group membership > for that, then he can drop a SETGID binary for that group somewhere and > will have the permission forever. Effectively, you can never take group > membership away. Not saying that groups are always the best option, but I am always amused by this permanent group membership. Makes it sound like nobody invented mounting homes with the nosuid mount option and that admins haven't yet discovered "find -perm" if indeed there is a file system where users are allowed to drop sgid set binaries ... > Also, creating individual groups for all the various > privileged operations we have simply doesn't scale. This is a better argument. > So, PK's usecase is a valid and an important one. You cannot replace > that by Unix groups. You might say that it would be difficult or inconvenient, but it can be replaced if you really want to. Whether it would make sense to try is a different story ... Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Sat, 10.11.12 09:26, Richard W.M. Jones (rjo...@redhat.com) wrote: > On Sat, Nov 10, 2012 at 02:33:53AM +0100, Kevin Kofler wrote: > > Matthew Miller wrote: > > > Apparently the new version of polkit brings in javascript. The js package > > > is 6.5MB. I think anything that uses polkit will depend on it -- can we > > > remove it from core? > > > > Of course, the real question is why the heck PolicyKit needs a Turing- > > complete rule language (which also forced everyone to port their existing > > rules) when the previously-used simple INI-style pkla rule format did the > > job just fine! > > And Unix groups worked OK before that (and still do for the majority > of purposes). OK, I'll bite. So: Did they really? If you want to allow a user to execute a specific privileged operation once (let's say format a USB stick), and you grant him group membership for that, then he can drop a SETGID binary for that group somewhere and will have the permission forever. Effectively, you can never take group membership away. Also, creating individual groups for all the various privileged operations we have simply doesn't scale. So, PK's usecase is a valid and an important one. You cannot replace that by Unix groups. Making PK uninstallable hence really is not about removing something that was generally not necessary. It is simply about removing something that is not necessary in the specific usecase of a server setup where no local unprivileged users exist that might need to execute privileged operations interactively. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On Tue, 13.11.12 18:03, Thomas Woerner (twoer...@redhat.com) wrote: > The security team asked me not to make firewalld a D-BUS driven > mechanism, because of security concerns and also because of SELinux. Uh? If you write a new D-Bus service and want to use bus activation, then you should SystemdService= in the dbus service snippet, so that the actual activation is done by systemd. If you do that, then the effective difference regarding the execution environment of the service is next to zero, you just have two different triggers ("start this on boot" vs. "start this when dbus tells systemd to"). In fact, all system bus services should be configured to defer activation to systemd, so that all services regardless how they are triggered are executed in the same clean execution environment, and can be manipulated with the same commands (systemctl stop/kill/restart/mask/...) as any other services. In fact, even if you write a bus service that is started at boot, you should *always* make it bus activatable as well. Why? For two reasons: you make things robust that way, as the service is restarted when needed should it have died, and you enable parallelized boot-up, since services requiring your services don't have to be ordered explicitly after yours, but can just talk to your service name and dbus will queue all messages until your service is actually up. Hence: please make your service bus-activatable. In all cases. There are no security concerns, and you make things faster and more robust by doing this. > Additionally every load of the mechanism could have to load modified > or removed configuration files. So how should it get to the same > state then again? How should it react on and reflect configuration > changes? So it would have to write out everything - the state and > all configuration files. I am sorry, but this is overkill and a most > likely a source of big problems. Actually, no, it's not overkill, it's good coding practice. Most of systemd's various little services (not all though) are written that they can be killed and restarted at any time without losing any state (such as logind, udevd, timedated, localed, hostnamed, ...). In fact even systemd itself can exit and be reexecuted while recovering almost all previous state. (In fact, currently the one exception of the systemd services that can't just be killed without negative effect is journald, but we are working on that). It's really not that hard. I think it's a really good rule to make all low-level system daemons work that way, to keep things robust and resource usage minimal. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
LuaJIT - an alternative for current Python C bindings (was: Re: raising warning flag on firewalld-default feature)
On 12.11.2012 21:34, Steve Grubb wrote: But the problem I see is a lot of libraries are wrapped by swig, which leaks memory like a sieve. If swig didn't generate such leaky code, Python based daemons wouldn't be as scary. IMHO, Python is one of the best ways to express management logic. As have stated elsewhere in the thread, from the footprint perspective, python-libs can be decomposed to something including much smaller python-libs-core. The remaining problem is the quality of part of the C bindings. Otherwise, it is great advantage for Fedora that huge part of the system tools are already polished in Python (my own experience is that the C code in many tools/libs shipped with Fedora is of relative poor quality, as already Miloslav explained). David Malcolm already has some real results addressing the Python bindings issues trough static analysis based on his great gcc-python-plugin/libcpychecker work. In the future, this machinery can be used for bug free bindings generation too. Another option for addressing this is ... to just get rid of part of them in their current form. LuaJIT 2.0 is a reimplementation of Lua scripting language, which has build the reputation of one of the fastest compilers (comparable only with gcc) in the course of his 3 years! beta cycle (2.0 final release was announced early this week) The size of luajit.so (interpreter + trace compiler + C parser for the FFI definitions) is 452088 bytes (on x86_64, for comparison sqlite3.so, which is a python requirement is 677672) Unlike other FFI implementations LuaJIT FFI works compiling the functions calls/C structs access to native code. Another difference is that the foreign C definitions are presented in native C syntax: http://luajit.org/ext_ffi_tutorial.html#zlib On top of this kind of FFI, LuaJIT already have bunch of library bindings - as instance the kernel ABI wrapper: https://github.com/justincormack/ljsyscall For a long time already Fedora ships lunatic-python (loading and bridging the Lua interpreter as python module) More recent and feature complete bridge is: https://github.com/scoder/lupa from the author of lxml module. So, to me it seems natural joining all above together to start thinking for replacing the classic python C bindings with thin textual or bytecode(*) LuaJIT/FFI shims in benefit of things with great set of dependencies like Anaconda (thanks to lupa, Lua objects behaves like Python ones in Python). The result will be order of magnitude easier for maintenance (towards the APIs evolution) and faster code. Furthermore, we can get LuaJIT for free, because it is full API/ABI compatible with current Fedora (PUC Rio) Lua 5.1, which is pulled by RPM anyway - we can just replace Lua with LuaJIT as RPM provider for F20. Kind Regards, Alek (*) Unlike original Lua, LuaJIT bytecode is portable across architectures. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, Nov 14, 2012 at 4:03 PM, Lennart Poettering wrote: > On Thu, 15.11.12 00:56, Lennart Poettering (mzerq...@0pointer.de) wrote: > >> I think a good way to approach this is by looking for the interesting >> usecases for a minimal installation: >> >> A) Containers >> B) VMs >> C) Bare-Metal Servers >> D) Paranoid people (not relevant) >> E) Embedded (out of focus for Fedora) >> ... anything else? >> >> I list A and B as separate items, since they have different needs. For >> A you don't want SSH or bootloader (the bootloader is not necessary, as >> the container manager will directly invoke init, and you can login via >> local console). For B you you need a bootloader and probably SSH. >> >> I think it would make sense to focus on the intersection of installation >> set for these usecases. And hence: >> >> No SSH. No Boot loader. And definitely not Sendmail. > > Also, no kernel and no kmod for A, as that is provided by the container > host. > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel It's been a while since I did anything with containers (LXC) but as I recall they're pretty much unmanageable without being able to ssh into them. But yes, I do think the bare-assed minimum viable Fedora is an LXC guest that one can get a console of some kind on and install packages into via yum. I'd even be willing to give up vim for nano. I don't need bash-completion or locate or man pages. ;-) -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing "A weem oh way!" at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Time synchronization inside virtual machines is a. Hypervisor-dependent. See the docs for VirtualBox, VMware, Xen and kvm and read the fine print. I don't even know if there *is* documentation for EC2. b. Poorly documented and difficult to test. If you don't *need* anything better than NTP / one second synchronization, don't waste your time. c. A mine field if you *do* need something better. Stay safe out there. ;-) On Wed, Nov 14, 2012 at 7:22 AM, wrote: >> From: Stephen John Smoogen >> > On Tue, Nov 13, 2012 at 08:00:23PM -0500, Ben Cotton wrote: >> > On EC2 (as in many virt environments) the hardware clock source is >> > actually >> > synced and running an ntpd service on the client is redundant. >> > >> >> >> They say it is but it is not always. I have had multiple cases >> in KVM and some in Xen where supposedly the clock is kept up but what >> you end up is actually watching time go backwards if you hit heavy >> load in IO or CPU or Mem. Of course if you run into hardware like >> that.. you can install it after your DB has gone poopsies. >> > > I've seen that happen as well. I found this by hitting the pause button on > the guest IIRC. I just always use NTP to avoid the worry, but I agree NTP > (whether ntpd or chronyd) belongs in @standard not @core. > > -- > John Florian > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing "A weem oh way!" at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Tue, Nov 13, 2012 at 9:59 PM, Ian Pilcher wrote: > On 11/13/2012 06:55 PM, Adam Williamson wrote: >> It might be worth re-evaluating whether that's realistic any more, >> though, and whether we're _really_ committed to finally replacing >> network with NM in some kind of reasonable timeframe. > > To this point, NetworkManager has failed to gain basic bridge support. > In the meantime, Open vSwitch, which has a ton more configuration > options has been recently added to the distro. > > I'd argue that NM actually continues to fall farther behind. Yeah, I love NetworkManager until it bites me - I've lost count of how many times I've been in a coffee shop and had to use 'sudo nmcli con del id' to get back online. ;-) -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing "A weem oh way!" at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 14 November 2012 17:19, Lennart Poettering wrote: > On Wed, 14.11.12 17:15, Stephen John Smoogen (smo...@gmail.com) wrote: > >> >> How about a separate group for containers, since the packages and use >> >> case are very different than 'core' provides? >> >> >> >> @core-container ? or @container ? >> > >> > Well, it would be weird that the "minimal" installation is actually not >> > "minimal" at all, but the "container" installation is. >> >> I didn't think one installed an OS inside a container.. but basically >> copied what one wanted into it... eg running anaconda to build a >> container means you already went too far :). > > Oh, I wasn't aware that this is solely about anaconda-based installs, > sorry. Well actually I think the correct question here is.. is this about anaconda based installs which was my guess when reading through this. However it is an assumption.. which means I am probably as much an ass as an umption in it. > For containers a yum group for usage with --installroot= is the only > thing that matters. Where I think the core-container would go to define that. But again.. my assumptions may be as wrong as anything. -- Stephen J Smoogen. "Don't derail a useful feature for the 99% because you're not in it." Linus Torvalds "Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "network" service fails to set wireless parameters.
Dan Williams wrote: > Could be because your wifi adapter is a recent one, and thus uses the > preferred upstream nl80211 kernel configuration API. It's an Intel PRO/Wireless 2200bg, so not exactly recent. > In addition, the wext api of "operation 1, then operation 2, then > operation 3" simply doesn't work well for newer devices, and never > worked very well for old ones, and it's possible that the driver for > your wifi device doesn't like the sequence that the initscripts use. When I use iwconfig manually I have to set the mode before the SSID and the channel, if that's what you mean. You don't seem to think the problem is in my ifcfg file, so I filed a bug report: https://bugzilla.redhat.com/show_bug.cgi?id=876786 Björn Persson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, 14.11.12 17:15, Stephen John Smoogen (smo...@gmail.com) wrote: > >> How about a separate group for containers, since the packages and use > >> case are very different than 'core' provides? > >> > >> @core-container ? or @container ? > > > > Well, it would be weird that the "minimal" installation is actually not > > "minimal" at all, but the "container" installation is. > > I didn't think one installed an OS inside a container.. but basically > copied what one wanted into it... eg running anaconda to build a > container means you already went too far :). Oh, I wasn't aware that this is solely about anaconda-based installs, sorry. For containers a yum group for usage with --installroot= is the only thing that matters. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On 14 November 2012 17:13, Lennart Poettering wrote: > On Wed, 14.11.12 17:05, Kevin Fenzi (ke...@scrye.com) wrote: > >> On Thu, 15 Nov 2012 01:03:03 +0100 >> Lennart Poettering wrote: >> >> ...snip... >> >> > > >> > > I think it would make sense to focus on the intersection of >> > > installation set for these usecases. And hence: >> > > >> > > No SSH. No Boot loader. And definitely not Sendmail. >> > >> > Also, no kernel and no kmod for A, as that is provided by the >> > container host. >> >> That doesn't look like an intersection to me. ;) > > Well, if you look at all the usecases it happens that the container > usecase ends up being the most minimal, and hence the intersection of > all of them. > >> How about a separate group for containers, since the packages and use >> case are very different than 'core' provides? >> >> @core-container ? or @container ? > > Well, it would be weird that the "minimal" installation is actually not > "minimal" at all, but the "container" installation is. I didn't think one installed an OS inside a container.. but basically copied what one wanted into it... eg running anaconda to build a container means you already went too far :). > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Stephen J Smoogen. "Don't derail a useful feature for the 99% because you're not in it." Linus Torvalds "Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, 14.11.12 17:05, Kevin Fenzi (ke...@scrye.com) wrote: > On Thu, 15 Nov 2012 01:03:03 +0100 > Lennart Poettering wrote: > > ...snip... > > > > > > > I think it would make sense to focus on the intersection of > > > installation set for these usecases. And hence: > > > > > > No SSH. No Boot loader. And definitely not Sendmail. > > > > Also, no kernel and no kmod for A, as that is provided by the > > container host. > > That doesn't look like an intersection to me. ;) Well, if you look at all the usecases it happens that the container usecase ends up being the most minimal, and hence the intersection of all of them. > How about a separate group for containers, since the packages and use > case are very different than 'core' provides? > > @core-container ? or @container ? Well, it would be weird that the "minimal" installation is actually not "minimal" at all, but the "container" installation is. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, 14.11.12 10:34, john.flor...@dart.biz (john.flor...@dart.biz) wrote: > > From: Chris Adams > > > > Well, as soon as you have cron, you'll have things wanting to send > > email, and even sendmail mail to "root" on the local system requires > > some type of MTA in most cases. > > >From my experience, an MTA is still not required. Any stdout/err from the > cron jobs just go to the syslog, but this may be systemd's journal magic > that I've been seeing. cronie is actually able to log the cron output to syslog since a long time. I haven't been running MTAs on any of my machines for a many years now. If you deinstall the MTA then cronie will log a error message that sendmail wasn't around, and then go on and log job output to syslog. This error message is really pointless and should go away. Honestly, we really should drop sendmail from the default install of *all* systems, not just the minimal installations. It is simply not useful without configuration, and nothing else we install requires it, not even cronie. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, 14.11.12 08:18, Chris Adams (cmad...@hiwaay.net) wrote: > Once upon a time, Thomas Bendler said: > > Does an MTA really make sense in the core definition? The configuration of > > MTA is nowadays much more complex compared to the "old" days. Normaly you > > need a FQDN, you need a SMTP relay and lot other stuff more. So you will > > only get the mails off the system after a lot of configuration work which > > can, from my point of view, also include the installation of an MTA. > > Well, as soon as you have cron, you'll have things wanting to send > email, and even sendmail mail to "root" on the local system requires > some type of MTA in most cases. I am pretty sure the default should be to push everything to the logs. But note that in the container case you are likely to encounter a setup where you install the host host, and then add one container for mail, another one for web, a third one for database, and so on. If you do that it would be really bogus to include sendmail in the minimal set... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Thu, 15 Nov 2012 01:03:03 +0100 Lennart Poettering wrote: ...snip... > > > > I think it would make sense to focus on the intersection of > > installation set for these usecases. And hence: > > > > No SSH. No Boot loader. And definitely not Sendmail. > > Also, no kernel and no kmod for A, as that is provided by the > container host. That doesn't look like an intersection to me. ;) How about a separate group for containers, since the packages and use case are very different than 'core' provides? @core-container ? or @container ? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Thu, 15.11.12 00:56, Lennart Poettering (mzerq...@0pointer.de) wrote: > I think a good way to approach this is by looking for the interesting > usecases for a minimal installation: > > A) Containers > B) VMs > C) Bare-Metal Servers > D) Paranoid people (not relevant) > E) Embedded (out of focus for Fedora) > ... anything else? > > I list A and B as separate items, since they have different needs. For > A you don't want SSH or bootloader (the bootloader is not necessary, as > the container manager will directly invoke init, and you can login via > local console). For B you you need a bootloader and probably SSH. > > I think it would make sense to focus on the intersection of installation > set for these usecases. And hence: > > No SSH. No Boot loader. And definitely not Sendmail. Also, no kernel and no kmod for A, as that is provided by the container host. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Mon, 12.11.12 11:28, Matthew Miller (mat...@fedoraproject.org) wrote: > Okay, cool -- there's a lot of enthusiasm for a SIG for the core package > set. > > So, first up on the SIG goals: clarifying our target. > > It's been suggested before that there's so many possibilities that this is > useless, but the point here is to *pick* a reasonable choice as a group and > to work with that (even if we can't get complete consensus). Then, later, > when someone says "but minimal could mean so many differen things!" we > simply say "sure, but *this* is what we mean". > > I see three basic options for the target: > > A) kernel + init system and we're done > B) "boot to yum (with network)": a text-mode bootstrap environment on which > other things can be added by hand (or by kickstart) > C) a traditional Unix command line environment with the expected basic > tools available > > To me, 'C' is too wide for two reasons. First, it's too open for continual > debate, because different people might expect different tools. Second, it's > not necessarily the right base for the rest of the distribution, because > many use cases might not really need that traditional Unix environment. > > I think 'A' is interesting and useful, but I don't think it should be our > target, because it's not *useful enough*. We may want to eventually define a > sub-group which covers just this tiny base (maybe with busybox?), but I > think that's a different project. > > So that leaves me at *mostly B*, although I have some sympathy to the idea > that we should include a few other things like a man page reader, since > we're installing man pages, and a way to deliver e-mail to root, since we're > installing things that send such mail. And I think the core environment > should include ssh, but I'm open to the idea that even that should be an > add-on. > > What do you think? I think a good way to approach this is by looking for the interesting usecases for a minimal installation: A) Containers B) VMs C) Bare-Metal Servers D) Paranoid people (not relevant) E) Embedded (out of focus for Fedora) ... anything else? I list A and B as separate items, since they have different needs. For A you don't want SSH or bootloader (the bootloader is not necessary, as the container manager will directly invoke init, and you can login via local console). For B you you need a bootloader and probably SSH. I think it would make sense to focus on the intersection of installation set for these usecases. And hence: No SSH. No Boot loader. And definitely not Sendmail. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hdf5 1.8.10 being pushed to rawhide
On 11/14/2012 09:02 AM, Orion Poplawski wrote: I'll be building hdf5 1.8.10 for rawhide shortly. This will require a rebuild of all hdf5 using packages. I'll try to get to most of them today. This has been delayed due to an unexpected issue. -- 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: raising warning flag on firewalld-default feature
On 13.11.2012 18:35, Richard W.M. Jones wrote: Hmmm: $ echo '' > true.ml $ ocamlopt.opt true.ml -o true $ time ./true real 0m0.002s user 0m0.000s sys0m0.001s time luajit -e "require'os'; os.exit(42)" real0m0.001s user0m0.000s sys 0m0.000s But, check here for a far more important feature: http://luajit.org/ext_ffi_tutorial.html#zlib all this in 452088 bytes (libluajit.so, x86_64): This seems about right to me: Both ocamlopt & gcc generate native x86-64 programs, but there's a small amount of overhead in the OCaml binary (initializing the minor heap of the GC). luajit too (it is one of the fastest compilers) I will try to formulate an approach for Fedora to benefit from this little miracle in additional note (SWIG bindings problems above in the thread). Kind Regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora ARM weekly status meeting minutes 2012-11-14
Good day all, Thanks to those who were able to join us for the weekly status meeting today. For those that were unable, the minutes are posted below: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-11-14/fedora-meeting-1.2012-11-14-21.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2012-11-14/fedora-meeting-1.2012-11-14-21.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-11-14/fedora-meeting-1.2012-11-14-21.00.log.html Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revamping the non responsive maintainer process
On 11/11/2012 10:01 PM, Orion Poplawski wrote: On 11/06/2012 06:07 AM, Marcela Mašláňová wrote: Oh no, you are top posting again ;-) And please, please, please could we trim quotes to relevant ones? Thanks! Ohmahgerd, thank you for saying that. I am all for bottom posting but the _reason_ for bottom posting is that one responds to a specific phrase in the original. When people bottom-post a short reply under dozen-quoting-levels, multi-paragraph quote, it's actually less useful than if they just top-posted. In other words, bottom posting should not be a cargo cult, but instead a result of commitment to careful editing and meaningful communication. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
- Original Message - > On Wed, Nov 14, 2012 at 1:24 PM, Matthew Miller > > If David is unwilling to just resurrect the old .pkla parser, one > option for "solving" the problem might be writing a piece of code > that > would provide compatibility with the .pkla files. > > This could be (the only) JS config snippet parsing the files directly > if the JS environment allowed file system access, or alternatively a > generator run before starting polkit to generate a large JS config > representing the contents of .pkla files. > > Anyone interested in implementing it? The .pkla syntax wasn't particularly appealing or expressive, and there was only a handful of packages using it. I don't really think it is particularly worth reviving. If a declarative syntax is needed, I suggest that the security team simply picks their favourite language, and then implements a single js rule that calls out to a commandline utility implementing that language. Checking compliance should be very simple then - just check that the single single rule is the one you put in place. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On 11/14/2012 07:33 PM, Richard W.M. Jones wrote: On Wed, Nov 14, 2012 at 09:44:55AM -0500, Gregory Maxwell wrote: On Wed, Nov 14, 2012 at 9:26 AM, Chris Adams wrote: Great - let's take something that people are using, remove that functionality, and not announce it! This is not cool; it represents one of my biggest frustrations with a bunch of the "new and improved" ways of doing things. You track down how to do something, it works for a few releases, and then it doesn't anymore with no notice. I don't mind this much in isolation— and to some extent its unavoidable if there is to be progress. I also have the experience and impression that Fedora often dismisses use cases in the 'long tail' as things that "power users" can get by twiddling some opaque config file or registry entry or hacking some bit of code— this happens more often the closer you get to the desktop, but believe its a culture which permeates the project more generally than that. In isolation this too would be occasionally frustrating but finite in baddness. The combination of the two— that anything non-stock is subject to constant and often undocumented breakage _and_ that many non nearly-universal use cases are too non-mainstream to consider supportable stock features really diminishes the value I receive from using a distribution at all. I was trying yesterday to formulate a question for the people running for FESCo along these lines; also what they thought about: https://news.ycombinator.com/item?id=4772133 However I wasn't able to formulate a snappy and non-carping question in time for the deadline. Still, I do believe it's something that FESCo (those elected and those standing for election) ought to address. Why are other OS and upstream decision/discussion int their regard fesco problem? Should not their focus be first and foremost on our own distribution and our own OS? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Wed, Nov 14, 2012 at 09:44:55AM -0500, Gregory Maxwell wrote: > On Wed, Nov 14, 2012 at 9:26 AM, Chris Adams wrote: > > Great - let's take something that people are using, remove that > > functionality, and not announce it! > > > > This is not cool; it represents one of my biggest frustrations with a > > bunch of the "new and improved" ways of doing things. You track down > > how to do something, it works for a few releases, and then it doesn't > > anymore with no notice. > > I don't mind this much in isolation— and to some extent its > unavoidable if there is to be progress. > > I also have the experience and impression that Fedora often dismisses > use cases in the 'long tail' as things that "power users" can get by > twiddling some opaque config file or registry entry or hacking some > bit of code— this happens more often the closer you get to the > desktop, but believe its a culture which permeates the project more > generally than that. In isolation this too would be occasionally > frustrating but finite in baddness. > > The combination of the two— that anything non-stock is subject to > constant and often undocumented breakage _and_ that many non > nearly-universal use cases are too non-mainstream to consider > supportable stock features really diminishes the value I receive from > using a distribution at all. I was trying yesterday to formulate a question for the people running for FESCo along these lines; also what they thought about: https://news.ycombinator.com/item?id=4772133 However I wasn't able to formulate a snappy and non-carping question in time for the deadline. Still, I do believe it's something that FESCo (those elected and those standing for election) ought to address. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora ARM weekly status meeting 2012-11-14
On Wed, Nov 14, 2012 at 6:20 PM, Paul Whalen wrote: > Good day all, > > This weeks Fedora ARM status meeting will take place today (Wednesday Nov > 14th) in #fedora-meeting-1 on Freenode. > Times in various time zones (please let us know if these do not work): > > PDT: 1pm > MDT: 2pm > CDT: 3pm > EDT: 4pm > UTC: 8pm > BST: 9pm > CST: 10pm > > Current items on the agenda: > > 1) Problem packages needing attention > > 2) Exynos 5 (Chromebook) Kernel - Is anyone currently working on this? > > 3) SE Linux issue with F18 kernels - status update > > 4) SFP images for F18 Beta - What images will be produced? > > 5) FUDCon Lawrence ARM activity planning > > If you have any other items you would like to discuss that are not mentioned, > please feel free to send an email to the list or bring it up at the end of > the meeting. Issues with koji builds/builders/rewRepos. Preferably if we could put this before 5) so I can depart and go to sleep I would appreciate it. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 876523] perl-Text-CSV_XS-0.92 is available
https://bugzilla.redhat.com/show_bug.cgi?id=876523 --- Comment #2 from Fedora Update System --- perl-Text-CSV_XS-0.92-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/perl-Text-CSV_XS-0.92-1.fc18 -- 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
Summary/Minutes for today's FESCo Meeting (2012-11-14)
=== #fedora-meeting: FESCO (2012-11-14) === Meeting started by mmaslano at 18:01:05 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-11-14/fesco.2012-11-14-18.01.log.html . Meeting summary --- * init process (mmaslano, 18:01:23) * #963 change of names of configuration files (mmaslano, 18:03:20) * AGREED: defer for now and see if mjg59 can get them access to the info they seek (+8,-0) (mmaslano, 18:12:34) * #971 Freezing for Fedora 18 Beta (mmaslano, 18:12:55) * Fedora 18 was already frozen (mmaslano, 18:13:52) * #969 libexecdir guideline conflicts with extant packages (mmaslano, 18:16:16) * AGREED: defer the decision (until Java rulling comes down) (+9,-0) (mmaslano, 18:29:11) * #970 F19 Feature: RPM 4.11 http://fedoraproject.org/wiki/Features/RPM4.11 (mmaslano, 18:34:14) * AGREED: rpm was accepted as f19 feature (+9,-0) (mmaslano, 18:35:15) * Next week's chair (mmaslano, 18:35:29) * nirik will be the chairman next week (mmaslano, 18:36:19) * Open Floor (mmaslano, 18:36:30) Meeting ended at 18:44:15 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * nirik (38) * mmaslano (36) * mjg59 (25) * mitr (17) * notting (15) * jwb (12) * zodbot (10) * pjones (9) * limburgher (9) * t8m (7) * gholms (5) * jreznik (4) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot 18:01:05 #startmeeting FESCO (2012-11-14) 18:01:05 Meeting started Wed Nov 14 18:01:05 2012 UTC. The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:05 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:10 Hi 18:01:10 #meetingname fesco 18:01:10 The meeting name has been set to 'fesco' 18:01:16 hello 18:01:19 morning 18:01:19 #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb 18:01:20 Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m 18:01:23 #topic init process 18:01:33 morning. 18:01:51 * limburgher here 18:02:02 Hello 18:02:28 * notting is here 18:02:37 * jreznik is lurking 18:02:47 let' start 18:03:10 .fesco #963 18:03:10 mmaslano: Error: '#963' is not a valid integer. 18:03:20 #topic #963 change of names of configuration files 18:03:30 .fesco 963 18:03:30 .fesco 963 18:03:31 pjones: #963 (change of names of configuration files) – FESCo - https://fedorahosted.org/fesco/ticket/963 18:03:34 mmaslano: #963 (change of names of configuration files) – FESCo - https://fedorahosted.org/fesco/ticket/963 18:03:42 mjg59: could you help michal or Kay? 18:03:45 Yeah 18:03:52 Sorry, hadn't really been online much for the past week 18:03:58 I'll follow up on that 18:03:58 sure, thanks 18:04:21 They could just unpack/analyze rawhide themselves I'd expect.. 18:05:50 any proposal? I would be fine with mjg's help 18:06:07 if mjg59 wants to help, I'm completely fine 18:06:11 proposal: defer for now and see if mjg59 can get them access to the info they seek 18:06:13 but it should be done before freeze if there are broken packages 18:06:43 mmaslano: We already froze for Beta 18:06:50 yes 18:07:05 well, packages have been 'broken' inasmuch as there were two configuration files for two releases already. what is the plan if the work mjg59 is helping kay with does not happen? 18:07:20 if there are pending fixes we could pass them thru the freeze as a NTH... or wait until after. 18:07:41 As the breakage is not critical I think that the fixes can be done in updates 18:08:03 so for now I agree with nirik's proposal 18:08:22 notting: We are not currently equipped to handle that question AFAICT. (We do need to be, but that's for another time.) 18:08:57 * nirik shrugs. I don't think I would block on it. 18:08:58 nirik, +1 18:09:09 it would be very nice ot fix before release tho... 18:10:20 Sure, where possible that clearly ought to happen 18:10:39 more votes on nirik's proposal? 18:10:41 +1 nirik 18:10:56 +1 I think 18:11:40 * nirik is for his own proposal too oddly enough. 18:11:46 * mmaslano too 18:11:56 +1 for lack of an alternative 18:12:01 +1 I guess. 18:12:09 sure 18:12:34 #agreed defer for now and see if mjg59 can get them access to the info they seek (+8,-0) 18:12:34 I mean, that's the process anyway if we /don't/ vote on it 18:12:55 #topic #971 Freezing for Fedora 18 Beta 18:13:00 .fesco 971 18:13:02 mmaslano: #971 (Freezing for Fedora 18 Beta) – FESCo - https://fedorahosted.org/fesco/ticket/971 18:13:13 I took that to be 'no great objection to freeze' 18:13:19 we're already frozen 18:13:25 so, close this, freeze happened. ;) 18:13:31 great 18:13:40 jreznik, who is "RH's SB manager" 18:13:52 #info Fedora 18 was already frozen 18:14:18 jwb: in as much as 'guy
[Bug 876523] perl-Text-CSV_XS-0.92 is available
https://bugzilla.redhat.com/show_bug.cgi?id=876523 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Text-CSV_XS-0.92-1.fc1 ||9 -- 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: raising warning flag on firewalld-default feature
Roberto Ragusa wrote: > Just for fun, let's see who is the worst. Challenge accepted. :-) $ cat nothing.adb procedure Nothing is begin null; end Nothing; $ gnatmake nothing.adb -o true gcc -c nothing.adb gnatbind -x nothing.ali gnatlink nothing.ali -o true $ time ./true real0m0.001s user0m0.000s sys 0m0.000s Björn Persson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora ARM weekly status meeting 2012-11-14
Good day all, This weeks Fedora ARM status meeting will take place today (Wednesday Nov 14th) in #fedora-meeting-1 on Freenode. Times in various time zones (please let us know if these do not work): PDT: 1pm MDT: 2pm CDT: 3pm EDT: 4pm UTC: 8pm BST: 9pm CST: 10pm Current items on the agenda: 1) Problem packages needing attention 2) Exynos 5 (Chromebook) Kernel - Is anyone currently working on this? 3) SE Linux issue with F18 kernels - status update 4) SFP images for F18 Beta - What images will be produced? 5) FUDCon Lawrence ARM activity planning If you have any other items you would like to discuss that are not mentioned, please feel free to send an email to the list or bring it up at the end of the meeting. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Wed, Nov 14, 2012 at 1:24 PM, Matthew Miller wrote: > On Tue, Nov 13, 2012 at 11:53:16PM -0600, Ian Pilcher wrote: >> Wait. So the .pkla file I wrote to allow my run virt-manager as my >> normal user is going to stop working, and I'm going to have to write the >> replacement in JavaScript? > > This particular case is the primary one I've seen for people actually > writing their own policy. I think maybe we should make a Unix group for it > and make that the default. (But I don't think that solves the problem.) If David is unwilling to just resurrect the old .pkla parser, one option for "solving" the problem might be writing a piece of code that would provide compatibility with the .pkla files. This could be (the only) JS config snippet parsing the files directly if the JS environment allowed file system access, or alternatively a generator run before starting polkit to generate a large JS config representing the contents of .pkla files. Anyone interested in implementing it? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using snapper for OfflineSystemUpdates
On 14 November 2012 16:27, Bill Nottingham wrote: > If you're using the yum backend, it already has support for this > via a plugin. Yes, I'm using yum but this problem applies for other distros too. > snapper's just a wrapper around the other commandline tools, right? We > do have 'system-storage-manager' now; see the 'ssm snapshot' command > it provides. I looked at ssm, but I didn't find any way to do anything other than snapshot, create and delete. I need to be able to roll back the current system to a working system using a snapshot, or at least get a diff of one snapshot to another. Snapper seems to provide a dbus service which I can use to do all the heavy lifting. They are indeed very similar. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
firewalld and other firewall frameworks
Hi folks, Since there's currently a lot of discussion going on surrounding firewalld I thought I'd throw in another aspect to these discussions (following encouragement from Mathew Miller). I'm speaking with my shorewall package maintainer hat on, but the issue would arise with any other framework for managing iptables rulesets. What's the official line (and hopefully this will end up in the documentation) on using other frameworks such as shorewall? In the past we've assumed that users installing shorewall know enough to disable the ip[6]tables service. Will the same be true with firewalld - i.e. will it simply be a case of disabling activation of firewalld? Is there any mechanism within firewalld for playing nicely with other products that generate iptables rules? Cheers, Jonathan. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 18 now in Beta freeze (again)
Greetings. Fedora 18 is now in freeze and the Beta change deadline is upon us (again). Updates will land in updates-testing after being pushed. Updates that fix accepted blocker and accepted NTH bugs for the Beta release will be pushed into the base repo when stable. We are in the Pre Beta section of the release, so the Pre Beta to pre-release updates policy applies: http://fedoraproject.org/wiki/Updates_Policy#Pre_Beta Please see: http://fedoraproject.org/wiki/Branch_Freeze_Policy http://fedoraproject.org/wiki/Change_deadlines http://fedoraproject.org/wiki/QA:SOP_blocker_bug_process http://fedoraproject.org/wiki/QA:SOP_nth_bug_process For more details. kevin signature.asc Description: PGP signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using snapper for OfflineSystemUpdates
On 11/14/2012 03:53 PM, Richard Hughes wrote: In https://fedoraproject.org/wiki/Features/OfflineSystemUpdates we've implemented doing the package updates at first-boot time. This makes a lot of the hard-to-fix problems a lot easier. The question then becomes, how do we make the OS Update process even smarter? A simple check would be to see if X started after doing an upgrade, and if it failed, to rollback to the disk snapshot or / (and /boot?) that we previously knew worked. Do do this we can currently use anything-on-lvm, or btrfs and quite a bit of shell-foo. I'm quite keen on no adding lots of tricky code to PackageKit to deal with all this complexity, so what about using snapper? See http://en.opensuse.org/Portal:Snapper for more details. It's an OpenSuse project, and other than a small patch I've sent upstream to get things compiling on Fedora it looks pretty small, self-contained and sane. Does anybody have any better ideas than snapper? I really don't want to roll my own on this one unless there's a good reason. Richard. You mean the snapper which is stuck in review #852174 :) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using snapper for OfflineSystemUpdates
Richard Hughes (hughsi...@gmail.com) said: > In https://fedoraproject.org/wiki/Features/OfflineSystemUpdates we've > implemented doing the package updates at first-boot time. This makes a > lot of the hard-to-fix problems a lot easier. The question then > becomes, how do we make the OS Update process even smarter? A simple > check would be to see if X started after doing an upgrade, and if it > failed, to rollback to the disk snapshot or / (and /boot?) that we > previously knew worked. > > Do do this we can currently use anything-on-lvm, or btrfs and quite a > bit of shell-foo. I'm quite keen on no adding lots of tricky code to > PackageKit to deal with all this complexity, so what about using > snapper? See http://en.opensuse.org/Portal:Snapper for more details. > > It's an OpenSuse project, and other than a small patch I've sent > upstream to get things compiling on Fedora it looks pretty small, > self-contained and sane. > > Does anybody have any better ideas than snapper? I really don't want > to roll my own on this one unless there's a good reason. If you're using the yum backend, it already has support for this via a plugin. (Haven't tested it recently, but it's been there for a few releases.) snapper's just a wrapper around the other commandline tools, right? We do have 'system-storage-manager' now; see the 'ssm snapshot' command it provides. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Pcre 8.32 RC1 in Rawhide
Hello, I've pushed release candidate of PCRE 8.32 into rawhide today. I belive it should not cause any difficulties as I've run it in my system for some time. It should be fully compatible with previous version though it introduces some significant changes like UTF-32 support, proper case-folding for multi-variant cases (e.g. Greek sigma), some JIT refactoring for 1.4 speed-up, Unicode 6.2.0, and pcregrep new `-oN' option to print any arbitrary submatches. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Setting the default firewall configuration (was Re: Attention, dependency fighters)
Am 14.11.2012 01:52, schrieb Adam Williamson: > I don't think that maintaining iptables/s-c-f forever as a 'lightweight > alternative' to firewalld is the way to go IT IS the way to go! not as default, not supported via GUI is OK but iptables.service and "configuration" with shellscripts is what in many professional usecases is needed, the only thing which is needed by administrators is the iptables-command and iptables.service loading "/etc/sysconfig/iptables" at startup so you can satisfy the desktop users with GUI/firewalld and do not punish professional users with iptables-rules you never can put in any GUI signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
hdf5 1.8.10 being pushed to rawhide
I'll be building hdf5 1.8.10 for rawhide shortly. This will require a rebuild of all hdf5 using packages. I'll try to get to most of them today. -- 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: [@core] working definition for the minimal package set
On Tuesday, November 13, 2012 04:55:50 PM Adam Williamson wrote: > > So far everything works without, and I think we should endevor to keep > > that true. > > I think this is similar to the firewalld issue in that the basic theory > here is that, look, NetworkManager is the way, the truth and the light: > it's supposed to be the One True Networking System, and we're just > keeping the network service around because there's some stuff it does > that NM doesn't do yet. > > This logic is getting a tad stretched because we've been rolling with it > for several years at this point, but AIUI this is still the party line > and the reason NetworkManager is in core. In theory the idea is not that > we provide, actively maintain and support both NM and the network > service, but that we want to only provide, maintain and support NM, and > we're keeping the legacy 'network service' stuff around only until NM is > done. > > It might be worth re-evaluating whether that's realistic any more, > though, and whether we're really committed to finally replacing > network with NM in some kind of reasonable timeframe. For Common Criteria purposes, everything running as root goes under the microscope and its painful and costly. We have to avoid that. If NM did not run as root and just retained whatever capability it needed, then we have an easier time. Same thing with firewalld. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Image-Info] 1.33 bump
commit 17b62e29c189ff9d4cb83e2978df1de468491b38 Author: Petr Šabata Date: Wed Nov 14 16:53:58 2012 +0100 1.33 bump .gitignore |1 + perl-Image-Info.spec | 65 ++--- sources |2 +- 3 files changed, 36 insertions(+), 32 deletions(-) --- diff --git a/.gitignore b/.gitignore index d5c715d..d646c5e 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,2 @@ Image-Info-1.28.tar.gz +/Image-Info-1.33.tar.gz diff --git a/perl-Image-Info.spec b/perl-Image-Info.spec index b035e36..754f74a 100644 --- a/perl-Image-Info.spec +++ b/perl-Image-Info.spec @@ -1,63 +1,66 @@ -%define rgbtxt %{_datadir}/X11/rgb.txt - Name: perl-Image-Info -Version:1.28 -Release:14%{?dist} +Version:1.33 +Release:1%{?dist} Summary:Image meta information extraction module for Perl - Group: Development/Libraries License:GPL+ or Artistic URL:http://search.cpan.org/dist/Image-Info/ -Source0: http://www.cpan.org/authors/id/T/TE/TELS/image/Image-Info-%{version}.tar.gz -BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) - +Source0: http://search.cpan.org/CPAN/authors/id/S/SR/SREZIC/Image-Info-1.33.tar.gz BuildArch: noarch -BuildRequires: perl(Image::Xbm), perl(Image::Xpm), perl(XML::Simple) -BuildRequires: perl(Test::Pod), perl(Test::Pod::Coverage) +BuildRequires: perl(Carp) +BuildRequires: perl(Compress::Zlib) +BuildRequires: perl(constant) +BuildRequires: perl(Exporter) +BuildRequires: perl(ExtUtils::MakeMaker) +BuildRequires: perl(File::Spec) +BuildRequires: perl(Getopt::Long) +BuildRequires: perl(Image::TIFF) +BuildRequires: perl(Image::Xbm) +BuildRequires: perl(Image::Xpm) +BuildRequires: perl(IO::String) +BuildRequires: perl(lib) +BuildRequires: perl(Test::More) +BuildRequires: perl(Test::Pod) +BuildRequires: perl(Test::Pod::Coverage) +BuildRequires: perl(XML::LibXML::Reader) +BuildRequires: perl(XML::Simple) Requires: rgb -Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) +Requires: perl(Compress::Zlib) +Requires: perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version)) %description This Perl extension allows you to extract meta information from various types of image files. - %prep %setup -q -n Image-Info-%{version} chmod -c 644 exifdump imgdump -%{__perl} -pi -e 's|/usr/X11R6/lib/X11/rgb\.txt|%{rgbtxt}|' \ -lib/Image/Info/XPM.pm - %build -%{__perl} Makefile.PL INSTALLDIRS=vendor +perl Makefile.PL INSTALLDIRS=vendor make %{?_smp_mflags} - %install -rm -rf $RPM_BUILD_ROOT -make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT -find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';' -find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null ';' -chmod -R u+w $RPM_BUILD_ROOT/* - +make pure_install DESTDIR=%{buildroot} +find %{buildroot} -type f -name .packlist -exec rm -f {} ';' +%{_fixperms} %{buildroot}/* %check make test - -%clean -rm -rf $RPM_BUILD_ROOT - - %files -%defattr(-,root,root,-) -%doc CHANGES README exifdump imgdump +%doc CHANGES CREDITS README TODO exifdump imgdump +%{perl_vendorlib}/Bundle/ %{perl_vendorlib}/Image/ %{_mandir}/man3/*.3pm* - %changelog +* Wed Nov 14 2012 Petr Šabata - 1.33-1 +- 1.33 bump +- Get rid of the old cruft +- Fix dependencies +- Update the source URL + * Fri Jul 20 2012 Fedora Release Engineering - 1.28-14 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild diff --git a/sources b/sources index a946495..72e0766 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -09453662ceb4bd57e1f2fcdd957c7a66 Image-Info-1.28.tar.gz +63f36362cb80d783c7f8df751ace89a0 Image-Info-1.33.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Image-Info-1.33.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Image-Info: 63f36362cb80d783c7f8df751ace89a0 Image-Info-1.33.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Using snapper for OfflineSystemUpdates
In https://fedoraproject.org/wiki/Features/OfflineSystemUpdates we've implemented doing the package updates at first-boot time. This makes a lot of the hard-to-fix problems a lot easier. The question then becomes, how do we make the OS Update process even smarter? A simple check would be to see if X started after doing an upgrade, and if it failed, to rollback to the disk snapshot or / (and /boot?) that we previously knew worked. Do do this we can currently use anything-on-lvm, or btrfs and quite a bit of shell-foo. I'm quite keen on no adding lots of tricky code to PackageKit to deal with all this complexity, so what about using snapper? See http://en.opensuse.org/Portal:Snapper for more details. It's an OpenSuse project, and other than a small patch I've sent upstream to get things compiling on Fedora it looks pretty small, self-contained and sane. Does anybody have any better ideas than snapper? I really don't want to roll my own on this one unless there's a good reason. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Wednesday, November 14, 2012 08:07:25 AM tim.laurid...@gmail.com wrote: > On Wed, Nov 14, 2012 at 6:53 AM, Ian Pilcher wrote: > > On 11/13/2012 09:50 PM, Matthias Clasen wrote: > > > Yes, this was a misunderstanding. What is still supported is the .policy > > > > files containing the default policy. And that is very good, since such > > policy files are installed by pretty much every package that uses polkit, > > while .pkla files were only used by very few packages. > > > > > > Wait. So the .pkla file I wrote to allow my run virt-manager as my > > normal user is going to stop working, and I'm going to have to write the > > replacement in JavaScript? > > > > Let's just say I'm struggling to find the words ... > > In F18 yes. > > http://davidz25.blogspot.dk/2012/06/authorization-rules-in-polkit.html This blog misses the most important property about security settings...they have to be auditable through automation. If you have 10,000 systems and need to know your security posture, you have to be able to check them through automation. If the javascript had a file over in /etc that it read configuration things from, then we are OK. But if we have to go check the code itself, there is a problem. -Steve > http://www.freedesktop.org/software/polkit/docs/master/polkit.8.html > > Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
2012/11/14 Chris Adams > [...] > Ehh, for local "root" mails from failing cron jobs, "less > /var/mail/root" works just fine. :) > Sending mails with telnet also works fine but I don't think that this is the question ;). We work on the definition of core and what will be inside. If we say, mail must be inside we should also install a client to access the mail. That's why I wrote, we should define what core is first (and document it) and then talk about the packages which should be in core. Regards, Thomas -- Linux ... enjoy the ride! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
> From: Chris Adams > > Well, as soon as you have cron, you'll have things wanting to send > email, and even sendmail mail to "root" on the local system requires > some type of MTA in most cases. >From my experience, an MTA is still not required. Any stdout/err from the cron jobs just go to the syslog, but this may be systemd's journal magic that I've been seeing. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
> From: Stephen John Smoogen > > On Tue, Nov 13, 2012 at 08:00:23PM -0500, Ben Cotton wrote: > > On EC2 (as in many virt environments) the hardware clock source is actually > > synced and running an ntpd service on the client is redundant. > > > > > They say it is but it is not always. I have had multiple cases > in KVM and some in Xen where supposedly the clock is kept up but what > you end up is actually watching time go backwards if you hit heavy > load in IO or CPU or Mem. Of course if you run into hardware like > that.. you can install it after your DB has gone poopsies. > I've seen that happen as well. I found this by hitting the pause button on the guest IIRC. I just always use NTP to avoid the worry, but I agree NTP (whether ntpd or chronyd) belongs in @standard not @core. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Once upon a time, Thomas Bendler said: > True, but then you need a mail client as well otherwise you won't see the > local mails. So the question is, what is the definition of core? What > should be the goal of core? Ehh, for local "root" mails from failing cron jobs, "less /var/mail/root" works just fine. :) -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
2012/11/14 Matthew Miller > default install of a small set of packages necessary for a consistent > Fedora experience including minimal admin tools > I was just surprised that there was no discussion about your proposal, instead, there was immediately a discussion about the packages that should be in core. So should this definition be the one that we are working on? >From my point of view, core should only contain kernel, network, ssh-server plus yum to be ready for installation (locally and remotely). But if the rest of the group say, no, we need more (i.e. minimal admin tools), fine with me. But then we have something that we agreed on and that can be documented as the core base. Regards, Thomas -- Linux ... enjoy the ride! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
On Wed, Nov 14, 2012 at 9:26 AM, Chris Adams wrote: > Great - let's take something that people are using, remove that > functionality, and not announce it! > > This is not cool; it represents one of my biggest frustrations with a > bunch of the "new and improved" ways of doing things. You track down > how to do something, it works for a few releases, and then it doesn't > anymore with no notice. I don't mind this much in isolation— and to some extent its unavoidable if there is to be progress. I also have the experience and impression that Fedora often dismisses use cases in the 'long tail' as things that "power users" can get by twiddling some opaque config file or registry entry or hacking some bit of code— this happens more often the closer you get to the desktop, but believe its a culture which permeates the project more generally than that. In isolation this too would be occasionally frustrating but finite in baddness. The combination of the two— that anything non-stock is subject to constant and often undocumented breakage _and_ that many non nearly-universal use cases are too non-mainstream to consider supportable stock features really diminishes the value I receive from using a distribution at all. More on the subject— in this brave new polkit JS world, when an administrator is considering upgrading their Fedora (or even some packages), what tools will they have to validate that their local JS actually works at all much less produces the desired behavior? I don't see any tools or documentation to facilitate that.It seems to me that adding a bunch of unsound programmatic configuration which can't reasonably be used by the end users due the overhead of keeping up regular fedora churn, especially absent good validation tools, is not a productive change relative to just baking in the additional logic and exposing it via basic configuration switches. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-HTTP-Negotiate] Modernize the spec and drop command macros
commit 36836080810c02ed86d0eb0b87fa452a87b1b396 Author: Petr Šabata Date: Wed Nov 14 15:37:02 2012 +0100 Modernize the spec and drop command macros perl-HTTP-Negotiate.spec | 16 +--- 1 files changed, 9 insertions(+), 7 deletions(-) --- diff --git a/perl-HTTP-Negotiate.spec b/perl-HTTP-Negotiate.spec index 4e44b9a..bd2f8a1 100644 --- a/perl-HTTP-Negotiate.spec +++ b/perl-HTTP-Negotiate.spec @@ -1,6 +1,6 @@ Name: perl-HTTP-Negotiate Version:6.01 -Release:3%{?dist} +Release:4%{?dist} Summary:Choose a variant to serve License:GPL+ or Artistic Group: Development/Libraries @@ -13,7 +13,7 @@ BuildRequires: perl(HTTP::Headers) >= 6 # Tests only: BuildRequires: perl(Test) BuildRequires: perl(HTTP::Request) -Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) +Requires: perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version)) Requires: perl(HTTP::Headers) >= 6 Conflicts: perl-libwww-perl < 6 @@ -31,14 +31,13 @@ value of the various Accept* header fields in the request. %setup -q -n HTTP-Negotiate-%{version} %build -%{__perl} Makefile.PL INSTALLDIRS=vendor +perl Makefile.PL INSTALLDIRS=vendor make %{?_smp_mflags} %install -make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT -find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \; -find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \; -%{_fixperms} $RPM_BUILD_ROOT/* +make pure_install DESTDIR=%{buildroot} +find %{buildroot} -type f -name .packlist -exec rm -f {} \; +%{_fixperms} %{buildroot}/* %check make test @@ -49,6 +48,9 @@ make test %{_mandir}/man3/* %changelog +* Wed Nov 14 2012 Petr Šabata - 6.01-4 +- Modernize the spec and drop command macros + * Fri Jul 20 2012 Fedora Release Engineering - 6.01-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_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: [@core] working definition for the minimal package set
On Wed, Nov 14, 2012 at 03:24:04PM +0100, Thomas Bendler wrote: > Ok, but what is the intent? The first mail was a questioning what should be > the scope of core and I didn't see a discussion answering this question. I That's *this* discussion. :) > think we should first define the mission statement and then discuss the > technical details. Or is it only unclear to me what the intent is? I kind of skipped past the mission statement because no one commented on the draft one I made, which is: The Fedora Minimal Core SIG ensures that the Fedora minimal package set is an intentionally curated selection rather than an ad hoc accretion of packages. to the first of the stated goals, which is: "Choose a working definition for "minimal" (kernel + systemd only vs enough to get to yum install over the net vs basic traditional unix system)". Based on the conversation so far, I think the target is: - mandatory install of everything up to yum install from the network - default install of a small set of packages necessary for a consistent Fedora experience including minimal admin tools -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
2012/11/14 Chris Adams > [...] > Well, as soon as you have cron, you'll have things wanting to send > email, and even sendmail mail to "root" on the local system requires > some type of MTA in most cases. > True, but then you need a mail client as well otherwise you won't see the local mails. So the question is, what is the definition of core? What should be the goal of core? Regards, Thomas -- Linux ... enjoy the ride! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: remove polkit from core?
Once upon a time, tim.laurid...@gmail.com said: > On Wed, Nov 14, 2012 at 6:53 AM, Ian Pilcher wrote: > > Wait. So the .pkla file I wrote to allow my run virt-manager as my > > normal user is going to stop working, and I'm going to have to write the > > replacement in JavaScript? > > > > Let's just say I'm struggling to find the words ... > > In F18 yes. > > http://davidz25.blogspot.dk/2012/06/authorization-rules-in-polkit.html > http://www.freedesktop.org/software/polkit/docs/master/polkit.8.html Great - let's take something that people are using, remove that functionality, and not announce it! This is not cool; it represents one of my biggest frustrations with a bunch of the "new and improved" ways of doing things. You track down how to do something, it works for a few releases, and then it doesn't anymore with no notice. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
2012/11/14 Matthew Miller > [...] > I'd like to go back a step here to the question starting the thread. > There's > plenty of time to go over each package, but the basic question is intent. > Clearly man pages aren't necessary for a super-minimal JEOS image, but > that's not *historically* been the intent of @core, and based on the > discussion so far I think it will continue to not be. > [...] > Ok, but what is the intent? The first mail was a questioning what should be the scope of core and I didn't see a discussion answering this question. I think we should first define the mission statement and then discuss the technical details. Or is it only unclear to me what the intent is? Regards, Thomas -- Linux ... enjoy the ride! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
Once upon a time, Thomas Bendler said: > Does an MTA really make sense in the core definition? The configuration of > MTA is nowadays much more complex compared to the "old" days. Normaly you > need a FQDN, you need a SMTP relay and lot other stuff more. So you will > only get the mails off the system after a lot of configuration work which > can, from my point of view, also include the installation of an MTA. Well, as soon as you have cron, you'll have things wanting to send email, and even sendmail mail to "root" on the local system requires some type of MTA in most cases. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, Nov 14, 2012 at 01:27:21PM +0100, Thomas Bendler wrote: > - Minimal tools for admins > > less > > man-db > > procps-ng > > vim-minimal > Is man-db really necessary? In the man pages included in the man-db package > are not really helpful for a core system ... from my point of view. I'd like to go back a step here to the question starting the thread. There's plenty of time to go over each package, but the basic question is intent. Clearly man pages aren't necessary for a super-minimal JEOS image, but that's not *historically* been the intent of @core, and based on the discussion so far I think it will continue to not be. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
On Wed, Nov 14, 2012 at 12:37:38AM -0500, Seth Vidal wrote: > >On EC2 (as in many virt environments) the hardware clock source is actually > >synced and running an ntpd service on the client is redundant. > > I would say this is not accurate. > > My experience with the instances running under xen is that that is true. > My experience with the instances running in euca under kvm is that > that is not true. I didn't mean to imply that it's true everywhere. It's just true enough places that we shouldn't make it mandatory. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Wed, Nov 14, 2012 at 11:34:56AM +0100, Miloslav Trmač wrote: > AFAIK the major things for our usual use cases are covered, at least > going by the F17 criteria. Sure, there may be more things missing. Adam asked to keep those other things to the other thread, so I'll just touch on the dependency bloat issue here. I think there are other reasons it is harmful to Fedora to go ahead before this is ready, though, which I'll continue to address separately. > Looking at hour original warning flag: Squeezing every last megabyte > out of the running system for cloud is a really new thing that we > haven't historically required. Sure, it would be great to make > firewalld smaller (and rewriting firewalld to C is one of those things > that have been promised a long time ago and never happened), but I > don't really see that as a blocker. Making it absolutely minimal isn't a blocker, but pulling X libraries into the minimal install is. I think that will be resolved, reducing this particular issue to being something for future improvement. If that can't be resolved, then it alone should be sufficient cause to postpone the feature. > We _cannot_ have two different firewalls equally supported, each with > its own command line and API. Applications won't support both > equally, documentation won't support both equally, QA won't cover both > equally, users will be confused. I agree. That's why I'm so concerned that firewalld needs to be ready for all reasonable cases before we switch to it. Again, more on that in the other thread. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] working definition for the minimal package set
2012/11/13 Bill Nottingham > [...] > - Minimal tools for admins > less > man-db > procps-ng > vim-minimal > Is man-db really necessary? In the man pages included in the man-db package are not really helpful for a core system ... from my point of view. > [...] > - Get mail off the box (and define a default for doing so) > sendmail > Does an MTA really make sense in the core definition? The configuration of MTA is nowadays much more complex compared to the "old" days. Normaly you need a FQDN, you need a SMTP relay and lot other stuff more. So you will only get the mails off the system after a lot of configuration work which can, from my point of view, also include the installation of an MTA. Regards, Thomas -- Linux ... enjoy the ride! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 875603] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=875603 --- Comment #3 from Fedora Update System --- perl-No-Worries-0.7-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/perl-No-Worries-0.7-1.fc18 -- 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
[Bug 875603] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=875603 --- Comment #4 from Fedora Update System --- perl-No-Worries-0.7-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/perl-No-Worries-0.7-1.el5 -- 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: remove polkit from core?
On Tue, Nov 13, 2012 at 11:53:16PM -0600, Ian Pilcher wrote: > Wait. So the .pkla file I wrote to allow my run virt-manager as my > normal user is going to stop working, and I'm going to have to write the > replacement in JavaScript? This particular case is the primary one I've seen for people actually writing their own policy. I think maybe we should make a Unix group for it and make that the default. (But I don't think that solves the problem.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File No-Worries-0.7.tar.gz uploaded to lookaside cache by mpaladin
A file has been added to the lookaside cache for perl-No-Worries: 2392bf83b131ce4ee31f03da4b1f0b8e No-Worries-0.7.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Wed, Nov 14, 2012 at 2:35 AM, Matthew Miller wrote: > Well. I may be a little bit cynical on this, but I think the unsteered drift > of this kind of thing goes like this: > > 1. Shiny new feature covers the desktop case, so let's make it the default >in Fedora. > 2. "Don't worry, if you have other needs, the old way still works". > 3. So many things get updated to the new way that the old way isn't >reasonable anymore, but *those other use cases never get consideration*. > > It's like step 2 magically covers the end game. But of course it doesn't. That's not at all the case with firewalld. 2 ouf of 4 of the concerns that led to firewalld being postponed in F17 were server/enterprise-related, and AFAIK are now resolved. Yes, the documentation is still not great, but that's something that can realistically be improved before GA. > I'm not against progress. The static firewall scripts don't cover a lot of > cases, and are particularly a pain with virt. But let's not jump ahead of > ourselves without at _least_ a plan. AFAIK the major things for our usual use cases are covered, at least going by the F17 criteria. Sure, there may be more things missing. Looking at hour original warning flag: Squeezing every last megabyte out of the running system for cloud is a really new thing that we haven't historically required. Sure, it would be great to make firewalld smaller (and rewriting firewalld to C is one of those things that have been promised a long time ago and never happened), but I don't really see that as a blocker. > So that's a little bit of a tangent, but, as outlined in the other thread, I > don't think firewalld is at a point where making it the default would be > a good for Fedora. Maybe it could be by F19. Reducing the dependency load is > just one part of that. > > In the meantime, I think we should make sure a newly installed system with > either firewalld or the old thing (now called iptables-service) has a > sensible firewall out of the box. (Same all-closed-but-ssh as we've had > forever, I expect.) We _cannot_ have two different firewalls equally supported, each with its own command line and API. Applications won't support both equally, documentation won't support both equally, QA won't cover both equally, users will be confused. We'd get the 8-years duplication of init.d/network vs. NetworkManager all over again, and I personally strongly want to avoid that (this was a third of my FESCo election platform). Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-CGI] 3.62 bump
commit 293f9a35fdbd1495a58da5206c06074304dcf196 Author: Petr Písař Date: Wed Nov 14 10:56:36 2012 +0100 3.62 bump .gitignore|1 + perl-CGI.spec | 10 +++--- sources |2 +- 3 files changed, 9 insertions(+), 4 deletions(-) --- diff --git a/.gitignore b/.gitignore index c5df0dc..8755315 100644 --- a/.gitignore +++ b/.gitignore @@ -2,3 +2,4 @@ /CGI.pm-3.51.tar.gz /CGI.pm-3.60.tar.gz /CGI.pm-3.61.tar.gz +/CGI.pm-3.62.tar.gz diff --git a/perl-CGI.spec b/perl-CGI.spec index 808794e..86e651e 100644 --- a/perl-CGI.spec +++ b/perl-CGI.spec @@ -1,6 +1,6 @@ Name: perl-CGI Summary:Handle Common Gateway Interface requests and responses -Version:3.61 +Version:3.62 Release:1%{?dist} License:GPL+ or Artistic Group: Development/Libraries @@ -9,11 +9,12 @@ URL:http://search.cpan.org/dist/CGI BuildArch: noarch BuildRequires: perl(ExtUtils::MakeMaker) # Run-requires: +BuildRequires: perl(base) BuildRequires: perl(Carp) BuildRequires: perl(constant) BuildRequires: perl(Exporter) -BuildRequires: perl(File::Spec) >= 0.82 BuildRequires: perl(FCGI) >= 0.67 +BuildRequires: perl(File::Spec) >= 0.82 # Apache modules are optional # Tests: BuildRequires: perl(Encode) @@ -22,8 +23,8 @@ BuildRequires: perl(IO::Handle) BuildRequires: perl(lib) BuildRequires: perl(Test::More) >= 0.98 Requires: perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version)) -Requires: perl(File::Spec) >= 0.82 Requires: perl(FCGI) >= 0.67 +Requires: perl(File::Spec) >= 0.82 Obsoletes: %{name}-tests <= 3.49 %{?perl_default_filter} @@ -66,6 +67,9 @@ make test %{_mandir}/man3/*.3* %changelog +* Wed Nov 14 2012 Petr Pisar - 3.62-1 +- 3.62 bump + * Tue Nov 06 2012 Petr Šabata - 3.61-1 - 3.61 bump, no code changes diff --git a/sources b/sources index 5e38826..852c7a4 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -92c3d1a5747be1e60618f999a50dad93 CGI.pm-3.61.tar.gz +3600b5fb106c256d53393e86ba62c65e CGI.pm-3.62.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File CGI.pm-3.62.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-CGI: 3600b5fb106c256d53393e86ba62c65e CGI.pm-3.62.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Schedule for Wednesday's FESCo Meeting (2012-11-14)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 17:00UTC (1:00pm EDT, 19:00 CEST) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #963 change of names of configuration files .fesco 963 https://fedorahosted.org/fesco/ticket/963 = New business = #topic #971 Freezing for Fedora 18 Beta .fesco 971 https://fedorahosted.org/fesco/ticket/971 #topic #969 libexecdir guideline conflicts with extant packages .fesco 969 https://fedorahosted.org/fesco/ticket/969 #topic #970 F19 Feature: RPM 4.11 - http://fedoraproject.org/wiki/Features/RPM4.11 .fesco 970 https://fedorahosted.org/fesco/ticket/970 = 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: raising warning flag on firewalld-default feature
On 11/13/2012 05:35 PM, Richard W.M. Jones wrote: > On Tue, Nov 13, 2012 at 02:41:44PM +, Pádraig Brady wrote: >> >> It could be argued that python is more suited to long lived programs: >> >> $ time /bin/true >> real 0m0.002s > > Hmmm: > > $ echo '' > true.ml > $ ocamlopt.opt true.ml -o true > $ time ./true > > real 0m0.002s > user 0m0.000s > sys0m0.001s > > $ time /bin/true > > real 0m0.001s > user 0m0.000s > sys0m0.001s > > This seems about right to me: Both ocamlopt & gcc generate native > x86-64 programs, but there's a small amount of overhead in the OCaml > binary (initializing the minor heap of the GC). Just for fun, let's see who is the worst. $ cat >JavaTrue.java public class JavaTrue { public static void main(String[] args) { System.exit(0); } } $ javac JavaTrue.java $ time java -cp . JavaTrue real0m0.071s user0m0.037s sys 0m0.035s Hmmm. Slow and with a lot of sys... Let's try compiling it to native. $ gcj -o JavaTrue JavaTrue.java --main=JavaTrue $ time ./JavaTrue real0m0.026s user0m0.016s sys 0m0.010s Good improvement, but still quite slow. (OT: what a pity gcj is abandoned... great project) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel