Re: EPEL [pkgdb] python-augeas epel7 cloned from EL-6
sorry that got sent prematurely. Here is the full version: hey all. So I was talking to Dominic Cleal this week at the Summit and he pointed out that python-augeas is getting pulled into RHEL 7 proper. Its not in the beta, but it is built for the RC. My reaction was kewl, dont have to worry about the epel package for el7! I then got a bug report asking for python-augeas in epel7[1], which i closed with the above explanation. Then i got the included pkgdb automated e-mail. :( A build has not been started in koji yet, which is good. So, what is the proper way for me to remove the EPEL7 branch? I looked at the FAQ and only saw one about removing the package from EPEL[3], which has a bad link and needs to be updated. Since its just the branch I also wasn't sure if that was the best route, or if i just delete the branch? thanks! greg [1] https://bugzilla.redhat.com/show_bug.cgi?id=1088660 [2] http://koji.fedoraproject.org/koji/packageinfo?packageID=6145 [3] https://fedoraproject.org/wiki/EPEL/FAQ#What_do_I_have_to_do_to_get_a_package_removed_from_EPEL.3F On Thu, Apr 17, 2014 at 10:41 PM, Greg Swift gregsw...@gmail.com wrote: hey all. So I was talking to Dominic Cleal this week at the Summit and he pointed out that python-augeas is getting pulled into RHEL 7 proper. Its not in the beta, but it is built for the RC. My reaction, was kewl, dont have to worry about the epel package for el7! I then got a bug report asking for python-augeas in epel7, which i closed with the above explanation. Then i got the below e-mail. :( So, what is the proper way for me to remove that branch? I looked at the FAQ and only saw this: which points to an invalid site, so that needs to be fixed. -- Forwarded message -- From: Fedora PackageDB pk...@fedoraproject.org Date: Thu, Apr 17, 2014 at 12:37 PM Subject: [pkgdb] python-augeas epel7 cloned from EL-6 To: gregsw...@gmail.com limb cloned python-augeas epel7 from EL-6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/python-augeas ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: comps' standard group spring cleaning?
On Thu, Jan 10, 2013 at 9:12 AM, john.flor...@dart.biz wrote: From: Lennart Poettering mzerq...@0pointer.de Heya, I noticed that comps' standard group includes a lot of packages that were all the hotness in 1990s but aren't really that much anymore. For example, irda-tools, pcmciautils, finger, rsh, rdist, pinfo have probably had their best times behind them, and probably shouldn't be installed by default anymore. I'd like to propose that maybe it is time to remove these from standard for F19. Note sure how to proceed on that. Propose a feature? File a bug? Is there even a comps maintainer? (Oh, and to clarify this: it's just about what to install by default, not about what to ship. It's just that I have a hard time remembering when i saw the last laptop with irda or pcmcia ports, and maybe we should not install that anymore by default...) Lennart -- Lennart Poettering - Red Hat, Inc. I agree with all those suggested, except for perhaps finger. Unfortunately, I don't think companies ID'ing their employees by number has gone out of style. I for one will continue to always install finger because I can't remember who 'd54321' is and finger really helps with that. (Although, I'm also probably the only gray beard in the company that uses this. :-) maybe i'm weird too, but ya.. i use finger more than who -greg -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Tue, Oct 23, 2012 at 8:47 AM, Vít Ondruch vondr...@redhat.com wrote: Dne 23.10.2012 15:37, Matthew Miller napsal(a): On Tue, Oct 23, 2012 at 03:22:27PM +0200, Vít Ondruch wrote: But that doesn't help people running puppet 2.6 _now_, and just introduces complication into the packaging. Introducing new package is complication anyway, so what is the point? See earlier comments. The point is that when the update goes live, people running the older version with non-compatible configs won't have their systems break. This is important. Yes, I understand that ... therefore you need two versions of puppet installed in parallel. There was proposal to prepare puppet3 package, while I think that the correct way is to move puppet to version 3 and prepare new puppet2 or compat-puppet package. Once you introduce version into the name, you will never be able to get rid of it, although puppet 4 might be 100% compatible with puppet 3 and I hope you don't like to have package puppet3-4.x in the future. I'm still not sold on parallel installation being the solution for this situation. I get the idea behind it, but to me that just adds unnecessary complication to the whole thing. Not saying its not the route to go, just not at the top of my list. What I do think would be a good idea is if we could try addressing this issue from a higher level since Puppet is decidedly not the only package with this problem. but then... i've a vested interest in that concept because I started a thread about it on the epel-devel list last week (as Toshio mentioned earlier in this thread). https://www.redhat.com/archives/epel-devel-list/2012-October/msg00015.html -greg -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Tue, Oct 23, 2012 at 1:46 PM, Matthew Miller mat...@fedoraproject.org wrote: On Tue, Oct 23, 2012 at 11:30:49AM -0700, Michael Stahnke wrote: I am still not in favor of a puppet3 package. This is largely due to overall compatibility. Puppet is a distributed system. Having the package be called puppet in some repositories and puppet3 in others (along with bin files/utils) will only the make the overall user-experience of Puppet worse IMHO. Also if the existing Puppet (2.6.x) stays out there, how would a user know that 2.6 is no longer maintained? Does having a second package without an upgrade path leaves the end-user out-to-dry in the longrun? We can make the new package available, and do something to publicize that there is going to be a change. When 2.6.x is no longer maintained for security updates, the new package gets the old name and obsoletes the temporary name. If there's some way to put deprecation notices into the default output for puppet, it might be worth considering that. An easy way would be to roll and update to the 2.6 release that logs a deprecation error on start via the init script. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages in need of new maintainers UPDATED LIST
On Fri, Oct 5, 2012 at 12:32 PM, Jon Ciesla limburg...@gmail.com wrote: pure-ftpd -- Lightweight, fast and secure FTP server i'll take that. fas = xaeth - greg -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stop the git abuse
On Mon, May 21, 2012 at 3:08 PM, Kevin Kofler kevin.kof...@chello.at wrote: Greg Swift wrote: i'm not against cleaning up ifs related to end of life/support releases, but how far are you suggesting that go? All support for Fedora n should be dropped at Fedora n's end of life. which fits within the definition I stated. okay.. np I know that I've pulled plenty of rawhide packages for build on a RHEL box when necessary, and even if they don't always support EPEL sometimes they've had if switches in them that helped save me lots of time. We do not support this usecase. It is just not feasible to maintain so many conditionals in our packages. And Fedora version conditionals won't help you anyway if you're building for RHEL, you'd need RHEL version conditionals, which packages not supporting EPEL are very unlikely to contain. So I recently helped bring python-augeas into EPEL. Before that (for the last 2+ years) the spec file supported RHEL conditionals and many of the python-augeas users did local builds of the fedora package in their RHEL environment. Just because a package has not gotten an EPEL maintainer yet, doesn't mean the package doesn't support RHEL. The zabbix package is in EPEL. On RHEL 5 that means it is in the 1.4 branch due to the update policies. The Fedora package had gone through 1.6 and 1.8 releases before RHEL6 came out, none of which are in epel-testing. Myself and many others built our updated packages off the fedora package. I know there are several other packages that fall into this category. So what would happen in those scenarios? I realize that at some threshold maintaining too many conditionals can make a spec very difficult to work with, but for very simple and limited conditionals the same could be said of having multiple spec files. I'd really think that is more of a decision to be left to the maintainer of the package since packages can vary so drastically. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stop the git abuse
On Mon, May 21, 2012 at 4:52 AM, Michael J Gruber michaeljgruber+gm...@fastmail.fm wrote: * put compatibility cludges for older releases on their respective branches (this gets rid of many if's in spec) i'm not against cleaning up ifs related to end of life/support releases, but how far are you suggesting that go? I know that I've pulled plenty of rawhide packages for build on a RHEL box when necessary, and even if they don't always support EPEL sometimes they've had if switches in them that helped save me lots of time. That and managing several specs because of this could be quite painful. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User switching is broken
2012/3/12 Sérgio Basto ser...@serjux.com On Mon, 2012-03-12 at 23:04 +0100, nodata wrote: User switching between different users on X is broken. It's not just broken for me, everyone I have asked has experienced the same problem: Clicking Switch user will often or sometimes lead to a hung screen. The switcher doesn't show the correct virtual terminal. Killing the switcher with ctrl+alt+backspace is one solution, the alternative is manually switching virtual consoles. I don't had any problem, but also don't switch much. what Fedora Release ? what X11 loads ? (cat /var/log/Xorg.0.log| grep drivers) what it is yours graphic card ? what is your windows manager ? you use kdm or gdm or other ? I had the exact same experience. my wife and I switch a lot. I changed from nouveau to nvidia and my problem _mostly_ went away. Its only happened to me once since, so I assumed that was the problem/fix. Unfortunately, I've trained the wife on the ctrl+alt+bksp so now I don't know how often she has the issue. Release: I had the issue on f16 (I skipped 15, so can not speak to that) Drivers pre-nvidia: [499406.597] (II) Loading /usr/lib64/xorg/modules/drivers/nouveau_drv.so [499406.598] (II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so [499406.598] (II) Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so [499406.648] (II) Loading /usr/lib64/xorg/modules/drivers/nouveau_drv.so Drivers post-nvidia: [ 216.734] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. [ 218.200] (II) Loading /usr/lib64/xorg/modules/drivers/nvidia_drv.so [ 218.300] (II) Loading /usr/lib64/xorg/modules/drivers/nvidia_drv.so Video card: 01:00.0 VGA compatible controller: nVidia Corporation GT218 [GeForce G210] (rev a2) wm: gnome-shell gdm the bug I found was: https://bugzilla.redhat.com/show_bug.cgi?id=739361 but i don't know if that is the one OP was referring to. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Torvalds:requiring root password for mundane things is moronic
On Fri, Mar 2, 2012 at 05:36, Nikos Roussos ni...@autoverse.net wrote: Here is a weird example of how Fedora currenty handles some permission procedures. I created a standard user account (no admin rights) and I'm trying to install a package. When I press apply I'm prompted to enter a password. Since I have no admin rights I would expect to be asked for the root password. Instead of that I'm asked to enter a password of another user who happens to be in the administrative group! See the screenshot as a proof: http://s.autoverse.net/yYi6AF See on the top right corner that I'm logged in with another account. So in the UX level we have actually disabled the root account (I can remember when was the last time I was prompted to enter it) thus we keep asking for a root password during installation that's ends up confusing people about its purpose. PS. an interesting question: if I had two users on my system belonging to the administrative group. which one's password I'll be prompted to enter when I'm logged with a standard user account, like the example above. I experience a similar scenario. On my home system (f16) I have my wife and both in the wheel group. Every time I go to run virt-manager I get prompted for her password. I do believe she is first in the wheel group after root in /etc/group. However this doesn't make any sense to me. It makes more sense for users that need that level of access to all know the root password rather than the users to know another user's password. Even then, if I am in the same group, doesn't it make more since to either prompt for my own password or just allow me? We know each others password so i've always shrugged it off cause I'm looking at other issues the few times when I am playing with the virtuals at home but since someone brought it up... -greg -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Retire rubygem-mongrel
On Fri, Jan 20, 2012 at 09:27, Vít Ondruch vondr...@redhat.com wrote: Hi, If nobody objects, I am going to retire *rubygem-mongrel* and its associated gems rubygem-gem_plugin, rubygem-fastthread and rubygem-mongrel_cluster. Mongrel is not maintained anymore [1]. It dos not support Ruby on Rails 3 available in Fedora, the last supported Ruby on Rails version was 2.3.7. There are available more viable Ruby web servers such as rubygem-thin. I believe nobody will regret this loss. I believe the rubygem-passenger package that is being worked on for inclusion in fedora still requires rubygem-fastthread. https://bugzilla.redhat.com/show_bug.cgi?id=470696 -greg -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self-introduction
My name is Greg, my handle these days is xaeth, which is effectively a shortened versin of a name I made up for accessing a MUD with strict name requirements the better part of a decade ago (I haven't played since around then either). @dayjob I am one of their lead linux engineers. I work with improving various bits of their platform and processes. One of the first things I had to learn when starting there 4 years ago was RPMs. Since then I became a stickler about enforcing the Fedora Packaging Guidelines as our internal guidelines. Sadly, there is always room for improvement, especially when re-packaging software from 3rd party vendors. The other thing I had to learn a lot about was python, and we started to make that our primary admin scripting tool internally. I started helping out on the func and cobbler projects over the last year, but currently project @dayjob is preventing me from contributing as much as I want to at the moment (I've barely touched func since 0.29, i'm sorry seth). I am also starting to use augeas more and more in our puppet setup. There is a python-augeas package, but it is not in EPEL at the moment. I've built the package and submitted the 1 patch I had in, but due to a lack of an EPEL maintainer it hasn't gotten release to EPEL. The other day on the list we got into a discussion on augeas-devel and I volunteered to take on the role if possible. I've read through the Package_Maintainers wiki. At one point in one of the docs it mentions that do do this I should follow the Become a co-maintainer process, but I guess I missed that specific processes' documentation. So I'm at the point where I am introducing myself in the regular process :) hi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
