Re: packages requiring me to reboot...
On Wed, Dec 16, 2009 at 2:01 PM, Gregory Maxwell gmaxw...@gmail.com wrote: Yes— users with more expertise are more likely to complain about this, but thats not reason to dismiss the issue. If there were truly a disconnect here betweens the needs of the novices and those of the expert users you could argue favouring the novices, but that just isn't applicable here. Uhm. am I missing something. Aren't we talking about reboot requests that PK is spawning and I can choose to cancel in the UI interaction because I know better instead of mandatory reboots? -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Exception request from FESCo for bundled libaries
On Mon, Dec 14, 2009 at 6:44 AM, Toshio Kuratomi a.bad...@gmail.com wrote: Just to make clear, Nicolas's interpretation is correct. Attempting to work around the problem by language lawyering does not promote better software. Another specific non-library case the pytz package was shipping its own timezone definitions separate from the tzdata package that required additional maintenance (stupid shifts in daylight savings time..thanks US congress.) I was told about it, added a patch to pytz and now it reads the tzdata resource files instead of shipping its own. Less work for me as a maintainer long term.. one less aperiodic package update for users...and more consistent timezone handling for users. The intention of the guidelines...is to guide people in using their judgement on how to handle things. Now in the pytz case as soon as I was made aware of the duplication of timezone resource files..it was obvious that I should make a best effort to reuse a common system wide set and it was easily done. But sometimes its not obvious and that's when a peer discussion needs to happen. Or sometimes its obvious but a best effort runs into problems because of upstream customization or tweaking and that's when a peer discussion needs to happen. The guidelines help define the boundary of the grey area when discussion really needs to happen. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Request for help maintaining packages while away.
On Wed, Dec 9, 2009 at 10:24 AM, Jeff Spaleta jspal...@gmail.com wrote: Good Alaskan Morning! In two weeks I'm going to be in Antarctica for a month+ and I'm looking for other packagers to step in for me and maintain my packages and prepare them for F13. I'm not exactly sure what my time and bandwidth access will be so I'm planning for the worst and that I'll be reliably off the grid through mid Feb. Please let me know if you can take on a co-maintainer/primary maintainer role for any of the packges and see them through the next couple of months. Okay I've processed all the pending packagedb requests that have come in so far. Thanks for the response. I'll try to push development tree builds for the latest releases of all the packages I own in the next week. But no promises. Watch your commit emails. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Request for help maintaining packages while away.
It's making use of some deprecated functionality for example gnomevfs which really should be ported to the newer gvfs stuff. There are probably some pygtk/gtk-isms which need to be updated. I'm willing to carry this as downstream patches if I have to but I really don't want to do that. Less critically for basic operation... the export functionality needs love. I'm not willing to carry this as downstream patches as I view the export functionality as a nice-to-have feature and not critical. I'm more inclined to just patch it to keep export from crashing on error than actually fix the export to work as a downstream only patch. There's some subtle problems with language support... which I'm personally ill-equipped to work through as a US English speaker (and barely at that). Crasher bug and something I'm willing to hold as downstream only patches if needed. -jef On 12/11/09, Adam Williamson awill...@redhat.com wrote: On Wed, 2009-12-09 at 12:38 -0900, Jeff Spaleta wrote: On Wed, Dec 9, 2009 at 12:26 PM, Paul W. Frields sticks...@gmail.com wrote: Jef, I'll help with istanbul. If anyone else out there is considering doing so, please feel free to team up with me. Other than revelation(which essentially has a dead upstream)...Istanbul is probably the most in need of more development love. This made me prick up my ears, as I keep my entire gigantic password database in revelation. What kind of development does it actually need? Dead upstream or not, it seems to work fine. Is it in imminent danger of dying? I can't help, not being a coder, but I'd like to know what's going on in case I have to change my workflow :/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Request for help maintaining packages while away.
On Thu, Dec 10, 2009 at 4:24 PM, Stephen John Smoogen smo...@gmail.com wrote: Its dead upstream? Oh dear. I use it quite a bit so probably need to look it over then. I use it too. A lot of people use it. I poked upstream prior to F11 and the developer responded saying he was getting back to it soon but I haven't seen much activity. Up to this point I've tried to at least tell the Ubuntu maintainer about any patches I add since its not clear how to submit patches to upstream. What I'd like to do is get the different distro maintainers together as a group form a game plan on setting up a new dvcs trunk for the project and then politely tell the existing upstream we want to move ahead with his blessing and have him as a contributor. It's an aging codebase and it needs to transition to using the newer gvfs stuff versus the older gnomevfs stuff... at a minimum. I don't want to do that as a set of downstream patches in Fedora. And until I get back from the other side of the world I can't commit to being a new upstreamsadly. If you want to get that conversation started...you have my blessing. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Request for help maintaining packages while away.
Good Alaskan Morning! In two weeks I'm going to be in Antarctica for a month+ and I'm looking for other packagers to step in for me and maintain my packages and prepare them for F13. I'm not exactly sure what my time and bandwidth access will be so I'm planning for the worst and that I'll be reliably off the grid through mid Feb. Please let me know if you can take on a co-maintainer/primary maintainer role for any of the packges and see them through the next couple of months. Here's the set of packages that I own. I will be contacting existing co-maintainers for individual packages in the list separately this week. ScientificPython -- A collection of Python modules that are useful for scientific computing g3data -- Program for extracting the data from scanned graphs gourmet -- Recipe Manager for the GNOME desktop environment gpodder -- Podcast receiver/catcher written in Python istanbul -- Desktop Session Recorder nec2c -- Translation of NEC2 antenna modeling tool from FORTRAN to C pyscript -- PyScript - Postscript graphics with Python python-basemap -- Plots data on map projections (with continental and political boundaries) python-basemap-data -- Data for python-basemap python-dateutil -- Powerful extensions to the standard datetime module python-matplotlib -- Python plotting library python-xlib -- X client library for Python pytz -- World Timezone Definitions for Python revelation -- Password manager for GNOME 2 safekeep -- The SafeKeep backup system scipy -- Scipy: Scientific Tools for Python telescope-server -- Opensource Telescope control servers to interface with stellarium usbsink -- USBSink is a GNOME -jefDoes living in Alaska and travelling to Antarctica make me bipolar?spaleta -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Request for help maintaining packages while away.
On Wed, Dec 9, 2009 at 12:26 PM, Paul W. Frields sticks...@gmail.com wrote: Jef, I'll help with istanbul. If anyone else out there is considering doing so, please feel free to team up with me. Other than revelation(which essentially has a dead upstream)...Istanbul is probably the most in need of more development love. Upstream seems to be inactive with no release activity in quite a while. There's a lot of deprecation warnings for some pygtk calls that I would love to clean up in time for F13. And there are a couple of abrt crash tickets being spawned by istanbul.. which maybe traced back to gdk libraries calls if I'm reading the crash dumps correctly. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12: Emacs is not for software development
On Sat, Nov 28, 2009 at 6:23 AM, Kevin Kofler kevin.kof...@chello.at wrote: Both vim and Emacs are obsolescent and hard to use. Kate FTW! Hmm, at this point I would have thought nano would be the editor with one of the lowest learning curve in those very pleasant moments when an inexperienced admin needs to edit a system config file manually from runlevel 1 or similar heart stopping panicy recovery situations. Do we have nano in by default or just vi? I mean vi is fine and all.. so is emacs... both are pretty useful development tools with there own style. but both can be frustrating to use out of the gate and your in a situation where you really really need to fix something _now_. Nano isn't particularly powerful, but its pretty clear how to edit and to save and to exit from looking at the default interface...without much head scratching or heartburn. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crazy Xrandr/XOrg automatic display configuration.
On Wed, Nov 25, 2009 at 9:13 AM, Jud Craft craft...@gmail.com wrote: Oh, I misunderstood. Yeah, it should remember the previous configuration you had with this combination of outputs. This information is stored in ~/.config/monitors.xml. Right. I guess what I'm saying is...it doesn't seem to. At this point, wouldn't it be most constructive to reveal what the contents of that file so we all have a baseline expectation as to what should be happening? For example when you get a cloned setup do you see a cloneyes/clone line in that file? And is that ling gone if you get an extended setup? It would be good to see how the monitors.xml file is changing between your cloned versus extended scenarios for that projector hardware. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: crazy Xrandr/XOrg automatic display configuration.
On Wed, Nov 25, 2009 at 10:28 AM, Jud Craft craft...@gmail.com wrote: To Matthias: thanks for the tip, but I don't have a monitors.xml.backup file. From reading the bug... I think if you copy monitors.xml to monitors.xml.backup I think you'll see a difference. From the bug comments it seems monitors.xml isn't being read but if montors.xml.backup exists its always read. Looks like a real upstream bug. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Vote for the bug (was Re: Local users get to play root?)
On Thu, Nov 19, 2009 at 4:15 PM, Jeff Garzik jgar...@pobox.com wrote: Are you not familiar with the concept of bugzilla votes? Try clicking on the '(vote)' link sometime. I'm not aware of a workflow or policy which takes into account bugzilla votes in Fedora. Individual maintainers may or may not consider votes when prioritizing how they use bugzilla, but there's certainly nothing that I am aware that suggests that highly voted on bugs are subject to high level review or discussion as a part of project management. I fear that you are encouraging people to vote with the expectation that the vote will matter in some way when it may not. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Vote for the bug (was Re: Local users get to play root?)
On Thu, Nov 19, 2009 at 4:34 PM, Jeff Garzik jgar...@pobox.com wrote: I'm curious what Fedora leaders think is the proper forum for __Fedora users__ to register complaints against this policy. Voting seems to be the most efficient, and least spam-y method of doing so, but I am open to suggestions! Voting doesn't mean much if there's no agreement to process the votes. It's inappropriate to run a get out the vote campaign unless there's an agreement that the votes about how they are going to be used for something. Even non-binding public referendums have their place..as long as people are told that they are non-binding and officials are prepared to actually look at the results. We've never had any sort of agreement with regard to how to review bugzilla voting. But its a good question. The answer of course is putting up an agenda item for discussion with Fesco or the Board depending on the nature of the policy in dispute. I think case Fesco and that's already slated to happen. But I think you've failed to state something important. I think what you really want to know is how Fedora users can register complaints meant to illicit an immediate response... faster than the turn around one can obtain via a fesco meeting. You want a 911 number to call, instead of a town meeting to speak at. I realize your impatient and I recognize the reasons why, but we don't really think we have a mechanism meant to override a maintainers opinion as fast as you feel it needs to be overturned. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 11:25 AM, Colin Walters walt...@verbum.org wrote: Having Yet Another access control system in HAL was precisely the reason PolicyKit was created, so administrators can have one place to find this stuff across the OS. Doesn't mean meathead sysadmins like me actually understand how to interact with it, -jefking of the meatheadsspaleta -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 3:23 PM, Bill Nottingham nott...@redhat.com wrote: But really, given that users out of the box can do *far far worse*, I'm not seeing the 'shameful', 'antithetical', OMG THE SKY IS FALLING AND YOU ALL SHOULD BE DRAWN AND QUARTERED sort of angst. Maybe people are tired of bagging tea and want new things to be outraged about. I know I'm tired of bagging tea. Luckily for me there's a new bubble tea shop in town with free wifi. I can enjoy bagless tea all day long and still get work done. -jefneeds a bubble tea protest t-shirtspaleta -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 3:35 PM, Eric Christensen e...@christensenplace.us wrote: PackageKit is something right there on the desktop that, to its credit, needs little knowledge to use whereas many of your attack vectors noted above are generally fixed in my shop by use of a kickstart and securing the box from physical access and require a higher skill to perform. So can't you harden this with a kickstart file line like you do in your other hardening steps in your shop? I think to point Bill is trying to make is that there are of a number of other settings that need to be hardened and that this choice is just one of many choices associated with security associated with a console user. Console user security is already a leaky ship and PK is just one more hole. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 3:52 PM, Eric Christensen e...@christensenplace.us wrote: Maybe. I mean removing (or not installing) PK is a snap with kickstart. I haven't visited my kickstart in a while so... :) Whick PK are you talking about... packagekit or policykit? PackageKit is probably what you mean given the context..but PK as a shorthand can mean either. And I think you missed my point. As we are learning..the hard way... sysadmins and spin developers can and should be encouraged to generate site specific policykit rules as part of hardening/softening ALL policykit enabled applications. You we really won't be able to rip out all the stuff using policykit. We're gonna have to digest the fact that policykit is there and start dealing with it in our setups and we are going to need some hand holding so we can do it effectively. PackageKit's policy is just the beginning of the learning curve here. It may not be server relevant as an application.. but the underlying issue about checking and configuring PolicyKit settings will be server relevant and unavoidable at some point. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Opinions on packaging ATLAS (for the x86 architecture)
On Wed, Oct 7, 2009 at 7:29 AM, Bill Nottingham nott...@redhat.com wrote: Surely the way to do this is to know what your workload is doing, and not do live migration to random hardware? I think random hardware is going to be exactly what you will see a lot of scientific research appliances being thrown at. There are groups interested in offering off the shelf appliances for some complex computational codes meant to be run on private/academic/national lab infrastructure to make it easier for scientific users to run the codes correctly. It's pretty pedantic stuff, and you can really screw up the build configuration when you are trying to build your own instances (DYI kernel compiles can be refreshingly less complicated sometimes) Live migrating appliances across those boundaries will undoubtedly be desired. National Lab run clouds are going to be well defined hardware targets but academic clouds are going to be all over the place. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Opinions on packaging ATLAS (for the x86 architecture)
On Tue, Oct 6, 2009 at 2:34 PM, Richard W.M. Jones rjo...@redhat.com wrote: which is that we should avoid making permanent optimizations, and instead try to do runtime tests wherever possible. This is because P2V, V2V and virtual machine migration makes it more likely that CPU features such as SSE* can change unexpectedly. This is going to be pretty important for scientific workloads where atlas is going to be used. I've eavesdropped on several conversations where people were talking about being able to run off-the-shelf science code virtual appliance in order to reduce the environment configuration workload for an individual researcher. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On Tue, Aug 25, 2009 at 2:50 PM, Matthias Clasenmcla...@redhat.com wrote: Using those criteria, 10 slots are quickly filled: I think this underscores the problem with this approach. It's quite arbitrary. It's more about about PR than about discoverability or relevance to any particular user or usage case. Hey drive-by end users with minimal to no knowledge of linux! Look we have big name open source applications in our repository that you can also install on Windows! We are relevant! We are relevant! Hey developers! Hey look here are a few developer focused applications we want to pimp because we are heavily involved in the upstream project! Hey look everyone! A game! We have games! If its meant to be a teaser...lets make sure we are upfront about that and lets avoid any sort of language which would imply a ranking. There's no top 10-ness to the list you propose. Its a feature bulletpoint list like you see in a sales pitch slidedeck. I have no problem with a hand built ten item list. Let's just be upfront about what the list represents. Such a list is a best a teaser...deliberately designed to draw casual website travellers in and explore the repository offerings on your own. -jefCan we turn the repository into a web based game? Sort of like 'new adventure shell' did for the shell interface? Can we have adventure repository?spaleta -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora-pkgdb: make it discoverable on browser home page?
On Mon, Aug 24, 2009 at 9:26 AM, Matthias Clasenmcla...@redhat.com wrote: My initial idea was to make this a 'top 10 apps', ie be selective, instead of trying to be all-inclusive and make the user scroll through dozens of pages with niche apps... What data would you use to rank apps in a top-10 sense? -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: showing dependency trees
2009/8/24 Björn Persson bj...@xn--rombobjrn-67a.se: One likely cause is that package C, somewhere in the dependency chain between A and E, contains too many different functions. In that case C should probably be split into subpackages C1 and C2, where C1 depends on A but E depends on C2. Then E would no longer depend on A. I hope you understand that chasing down every single instance of this situation ultimately leads to a situation that is more easily duplicated by making the build process automatically split every library binary into its own subpackage. If we aren't willing to do that automatically, then why is it worth the time to have multiple individuals systematically chase them down? I'm wary that the sort of checking you want to do is a rabbit hole that will require significant continued human effort as codebases shift. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: showing dependency trees
2009/8/24 Björn Persson bj...@xn--rombobjrn-67a.se: On the other hand, not addressing such situations at all ultimately leads to a huge tangle where every single package depends on pretty much all of Fedora Everything. It's a matter of finding a good balance. Are you suggesting that things are out of balance now? What is an allowable amount of tangle? Aren't you making an assumption that we are out of balance? Define a prescriptive good enough threshold to meet. Make sure you include a cost function for the associated repository metadata increase and subpackage header for each subpackage you add. Splitting every library binary into its own subpackage might not always resolve the situation by the way. I have seen libraries that lump together all sorts of unrelated functions in a single .so file. Are you seriously suggesting expending the manpower at the distribution level to poke at which functional calls need to broken out into more libraries? One function per library! One library per subpackage! There are also libraries written in interpreted languages that aren't compiled into binaries, and in some cases the dependencies might not even be libraries at all. I'm fully aware of the difficulty with interpreted languages. And do you know which percent of those are explicit and which are auto-generated via a buildtime dependency generator? Explicit deps and provides are quite fragile..that's not going to change. The win is going to come from automating as much of the depchain in interpreted languages as possible instead of systematically trying to fix explicitly coded deps one package at a time. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto plugin by default
On Tue, Aug 18, 2009 at 2:06 PM, Jesse Keatingjkeat...@redhat.com wrote: The hit on slow disks is pretty bad too, even non-slow disks. With a local mirror the time to re-make the deltas is far longer than the time to just pull down the entire packages. Time isn't the only metric...people may also be concerned about metered bandwidth. CPU overchurn we can limit via process priority..but finding a heuristic to determine what too slow means when it comes to disk io versus bandwidth is probably something we can't do. -jefspeaking of metered bandwidth..I need to remember to work from barnes and nobles instead of working from home this winter..so i can steal power, wireless and a nice warm firespaleta -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates lacking descriptions
On Thu, Aug 13, 2009 at 1:58 AM, Mathieu Bridon (bochecha)boche...@fedoraproject.org wrote: Being a group of volunteers doesn't mean we shouldn't aim for more quality. Ah..but project wide..is this place to have a quality enhancement discussion currently? Let me try to put this into perspective. This post started about 4 updates. How many updates have we pushed? What is our defect rate? Like 1% or something? What's are defect rate associated with packaging generally? Aren't we seeing more packaging defects than update text defects? And if so, shouldn't we concentrating on packaging defect prevention until the defect rate drops below the defect rate in update texts? It's nice to talk about a zero defect goal...but enforcing that goal with policy enforcement is a rabbit hole requiring infinite resources. Doubly so because there is clearly an interpretation factor here as to what is too much or too little detail to be included. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Make upstream release monitoring (the service formerly known as FEVer) opt-out?
On Thu, Aug 6, 2009 at 10:11 PM, Rahul Sundaramsunda...@fedoraproject.org wrote: I would prefer the system to be opt-out. For completely new maintainers or anyone maintaining more than a few packages, it certainly is very useful to get notification via bugzilla about new upstream releases. Err, uhm...I'd rather not see bugzilla overloaded with this sort of notification. But I would LOVE to see this integrated as notification information into the Fedora Community portal concept. I know a lot of us rely on bugzilla as the mainstay to a lot of our workflow...everything is a nail when all you have is a hammer. Everything is a bug when all you have is a bug tracker...But I think the maintainer portal concept introduced with the debut of Community is something we should start driving enhanced functionality at. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On Sat, Jul 25, 2009 at 7:41 AM, Alan Coxa...@lxorguk.ukuu.org.uk wrote: all these symptoms sound like your upgrade went horribly wrong. I've seen preupgrade mash up a box by half upgrading like that. It's the main reason I don't think preupgrade is actually safe to use yet. My first thought is...who in the community is standing up and taking the responsibility as the front line testers of preupgrade during the pre-release process? I admit I don't test or make us of it (and thus I don't feel I'm qualified to comment on how well it functions nor do I tell people to use it because I do not use it myself)...as I prefer fresh installs so that I can experience the default configuration which can change significantly from release to release. Do we need some affirmative me-too tabulation on the install scenarios to get an idea of how much testing each method is getting? If preupgrade is seeing only 1% of the DVD installer testing would it help to publicly expose that as encouragement for more people to test preupgrade? -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Any asciidoc users?
On Wed, Jul 15, 2009 at 6:01 AM, Todd Zullingert...@pobox.com wrote: ¹ https://bugzilla.redhat.com/506953 safekeep hit it. I was just starting to diagnose the problem. Do we really need to carry patches around in multiple individual projects for what is understood to be a problem in our asciidoc packaging? Really? Can't we deal with this in asciidoc packaging? So we aren't running done multiple failure to build reports? These are the packages which asciidoc's broken safe behavior. potentially impacts on packaging building. repoquery --whatrequires --archlist=src --repoid=rawhide-source asciidoc git-cola-0:1.3.8-1.fc12.src tig-0:0.14.1-1.fc11.src gegl-0:0.1.0-1.fc12.src libXi-0:1.2.99-2.20090619.fc12.src guilt-0:0.32-3.fc11.src git-0:1.6.3.3-1.fc12.src safekeep-0:1.0.5-2.fc11.src cogito-0:0.18.2-4.fc11.src sectool-0:0.9.3-1.fc12.src -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Why do we need FC version attached to the package name?
On Mon, Jun 22, 2009 at 8:32 AM, Dave Jonesda...@redhat.com wrote: Considering these updates are supposed to be for our 'stable' release, having them be in $nextrelease first seems like a good idea anyway. including rawhide? Do you want security fix updates to block on rawhide not composing in order to prevent an upgrade path breakage. -jef? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: No sound in rawhide
On Wed, Jun 17, 2009 at 7:25 AM, Ray Van Dolsonra...@bludgeon.org wrote: Hmm, I just always figured I was supposed to add myself to the audio group. So these files are supposed to be owned by my local user account when I log in eh? No... you should be added to the acl list associated to the device if you are the physical console user as per the authorization policy managed by PolicyKit. This it how it works from at least F10 onward. Mucking around with file ownership directly is old think. The system scripts associated with pam use to do that on user login and logout...but has been replaced with the more flexible solution involving acls that PolicyKit based hardware access authorization makes use of. for example on the F10 system I'm on right now: ls -la /dev/snd/seq crw-rw+ 1 root root 116, 3 2009-06-17 07:07 /dev/snd/seq getfacl /dev/dsp # file: dev/snd/seq # owner: root # group: root user::rw- user:myuser:rw- group::rw- mask::rw- other::--- I do not own the file in the traditional Unix permissions sense. But I am listed in the acl list with read write access. If your user is not in the acl list, something misfired in the area of the PolicyKit based authorization handling. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: No sound in rawhide
On Wed, Jun 17, 2009 at 8:06 AM, Jeff Spaletajspal...@gmail.com wrote: getfacl /dev/dsp typo: that should have been .dev./snd/seq not /dev/dsp the getfacl output cut and paste was correct for /dev/snd/seq -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On Wed, Jun 17, 2009 at 9:52 AM, Bill Nottinghamnott...@redhat.com wrote: - Atom is the only currently produced 32-bit x86 chip of note; optimize for what's currently available Just as an aside, can we do anything to help people identify whether their hardware is 64bit capable? I'm thinking specifically with people with Centrino stickered laptops of unclear vintage who may not realize that they have a 64bit capable machine even when they do. The Centrino branding doesn't exactly make it obvious as Intel pushed 64bit capability into the brand at some point (2006 ?). How many people are running 32bit Fedora on 64bit capable hardware without realizing its 64bit capable laptop hardware? -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On Wed, Jun 17, 2009 at 2:00 PM, Richard W.M. Jonesrjo...@redhat.com wrote: This just doesn't look worthwhile at all. My proposal is that we actually start to 'downgrade' x86, start compiling for baseline i386, and try to support people running Fedora on really old hardware, through projects like the Minimal Platform feature. Hmm. In the scheme of the numbers you references. What does that look like in terms of a performance penalty? Or was your proposal specifically covered by Bill's numbers? is the downgrade you are talking about within the jitter of Bill's posted performance numbers as well? -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On Wed, Jun 17, 2009 at 4:55 PM, Kevin Koflerkevin.kof...@chello.at wrote: Jeff Spaleta wrote: Well, we need to start by actually telling people a 64-bit version exists in the first place! The crappy download page needs to be fixed! We should go back to something like get-fedora-all, the current get-fedora is a disaster. Its all a matter of how you look at it. If it turns out that a lot of 64bit hardware owners are running 32bit Fedora 11, then we can probably assume the function of such a page is a high impact tool acting as a guide a significant portion of our userbase towards install media. If that's so then it probably deserves a lot of attention and scrutiny for first impression impact. If on the other hand people with 64bit systems are predominately installing the 64bit version, even though its not exposed on that page then we can probably say that our current userbase demographics are very technically saavy, and that the details of the contents of that sort of on-ramp page doesn't particularly matter to them. -jefA firm believer that all great culinary inventions were in fact thought to be cooking disasters at first glance... until someone dared a 12 year old boy to eat it. Half the time the kid would die, 10% of the time it was actually tasty.spaleta -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
On Wed, Jun 17, 2009 at 3:55 PM, Mike Chambersm...@miketc.net wrote: Question is, how reliable would smolt be, if you don't know how many more are *not* reporting to smolt anyway, via not on internet but on just a local network? I'll take it with a grain of salt...but I've no a priori reason to think that the number of 32bit installs on 64bit hardware would be unrepresentativeif we exclude virtualized installs completely. I'm not trying to compare the existence of 32bit to 64bit hardware just 32bit OS installs on 64bit hardware as a subset of all registered 64bit hardware. Just looking at 64bit hardware doesn't have the same sort of legacy or geographic distribution caveats that 32bit does with regard to re-purposed equipment. 64bit stuff just hasn't been around long enough. If 32bit installs on 64bit hardware is a tiny percentage of the registered smolt installs i doubt seriously its going to a majority situation for 64bit hardware in the wild. If its 20% or more as a function registered 64bit hardware..its a big enough population to try to account for in how we communicate a change in policy with regard to 32bit. I'm not suggesting that policy decision be based on this numbers..I'm saying that how we communicate a change in policy should have these numbers in mind when generating Release specific talking points for the release where the change impacts potential install scenarios.. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
On Tue, Jun 16, 2009 at 8:22 AM, King InuYashangomp...@gmail.com wrote: Ubuntu seems to do fine including quite a few language packs on their LiveCD while providing a decent desktop. Can you make me a full accurate list of the languages supported on the Ubuntu LiveCD. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
On Mon, Jun 15, 2009 at 9:58 AM, Bill Nottinghamnott...@redhat.com wrote: While I understand you may have a lot of older hardware, the point of a *seconday* architecture is that it's not the primary architecture target. Even if we didn't split off older CPUs, we're still primarily targeting newer machines. Most worrisome would be the dropping of the OLPC 1.0 hardware.. as its relatively new in terms of a physical device available for purchase (via the 2007 and 2008 G1G1 campaigns ) If you could hang a concise and consistent definition on how old hardware needs to be in order to be considered legacy I'd feel more comfortable discussing things in terms of newest. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What I HATE about F11
On Mon, Jun 15, 2009 at 11:42 AM, Casey Dahlincdah...@redhat.com wrote: The ability for nautilus to prompt for credentials when the user tries to do something outside his permission level has been missing for far too long. Its annoying to implement, but I'll owe a beer to whoever finally does it. I just threw that out as one example of how to think like a new admin when figuring out how to perform an administrative task for the first time would end up trying to re-login as root in order to get access to gui tools to make up for a lack of familiarity with the command line. I'm sure there are other easy to reach for examples to illustrate the point. We've got a set of task specific GUI tools that make use of the authorizations framework that helps a lot when normal usage patterns requires a user to act as an admin( without really having to realize it). But I'm not sure we've collectively got our heads around the use case the defines the collective needs of the novice administrator and sets a boundary beyond which command line familiarity is expected. .File permissions may or not be one of those things we expect to fall into that novice boundary. It's difficult for me to even make a suggestion as to where the boundary is, I reach for the commandline a lot more often than I strictly need to with the current set of UI tools available. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What I HATE about F11
On Mon, Jun 15, 2009 at 12:33 PM, Casey Dahlincdah...@redhat.com wrote: Maybe we should just make the command line more friendly so users don't mind reaching for it. I vote we add clippy. I'm not saying that necessarily needs to be friendlier to use but it may need to be more discoverable as to when it is expected to be used. What I am saying is, there maybe a gap in the reality and assumed expectation on where and when self-installing novice administrators should be diving into the commandline. Nothing in how our default live CD based install experience is put together points to the commandline as a tool for doing infrequent oddball tasks not explicitly covered in by the task specific gui tools in the system menu. Is the expectation that configuring sudo for their user or the wheel group is a best practice for these sort of infrequent tasks? Do we have system interactions designed in such a way that encourages commandline usage best practices? Lacking any system interaction that points to running tasks in a terminal under sudo, trying to login to gdm as root to gain enough privileges to do file re-permissioning or editting system wide config files seems like an obvious thing novice admins would try doing and be frustrated by when that didn't work. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What I HATE about F11
On Sun, Jun 14, 2009 at 6:45 AM, Simo Sorcesso...@redhat.com wrote: I haven't done a graphical root login in the past 10 years probably and on multiple distribution. Graphical root login is meaningless. Let me ask you a question as an example to better define the expectation on behavior that people have on what it means to administer a computer system. Can you run the thread audience through the steps on how you personally go about changing permissions on a root owned file or directory on a Fedora install to give write access to an admin user.. using nothing but graphical tools as installed by default in the Fedora Desktop? I honestly don't know how to do it. And I wouldn't think to do it that way. I'll reach for the commandline somewhere in the process whether it be to configure sudo or just doing the chmod under su. Nautilus exposes permissions for root owned files but I don't see an obvious hook that allows me to use existing authorization infrastructure to gain access to change those permissions as an admin user under nautilus. But for someone else...someone new who didn't waste time learning how to banner attack their classmates logged into the school's Vax system via a serial connection, someone who is installing a linux system for personal use and learning how to interact with that system and is basically their own admin...,they may instinctively reach for a graphical way to do stuff like file permissions manipulations. root login may realistically be the simplest way they know to gain access to graphical tools to perform simple operations that the user desktop does not allow. Its great that sudo exists and can be configured but how do you discover that tool as a new user doing a self-administered install? Nautilus is the obvious, intuitive for file management tasks, and if the only graphical way to get to a version of nautilus that can manipulate system files is to login as root..then it sort of makes sense that inexperienced users will attempt to do that..because its the logic of behavior the that graphical tool UI suggests. If there is an expectation that users can work with the graphical tools to do simple administrative tasks, I'm not sure enough thought has been put into how to self-consistently expose that functionality. -jef . -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What I HATE about F11
On Sun, Jun 14, 2009 at 3:36 PM, Lennart Poetteringmzerq...@0pointer.de wrote: Are you speaking of the same smolt that lists es1371 as most popular sound card? i.e. a sound card that has been out of production since about 10 years now? Somehow I have serious doubts about the validity of the smolt data. You might have found a bug in the tallying there in how cards are self-identifying product strings. You'll notice the same exact entry is listed twice in the Audio device table. Are cards using the ENS1371 driver misreporting their vendor/card version info? There are only 5 listings in the table for the ENS1371 driver. There are dozens listed for the Intel ICH driver. I bet if you totalled up counts by driver, things would look more sensible to you with intel being a reasonably large percentage of the drivers in use. Also, isn't the smolt data generated as part of the installation process, i.e. at a time where people haven't yet had the time to disable SELinux? smolt updates the info associated with a UUID via its service and cronjob configuration on a roughly monthly basis, unless someone disables the smolt service. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
On Sat, Jun 13, 2009 at 5:46 AM, Matt Domschmatt_dom...@dell.com wrote: Your thoughts? Is there a geographic regional bias in the data? 1) Are all countries/regions downloading the split cds at less than 5% of the download activity for the given country region? 2) Is there a geographical bias in the direct download data pool? It could be that some regions are using local mirrors for downloading the isos more heavily than others. Are countries/regions equally representative in the direct iso download data logs relative to the mirrormanager mirrorlist polling logs? Answer 1 and 2 together should be able to give you a way to put all regions on an equal activity scale...to see if there are certain regions who are using split media more heavily. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Do we need split media CDs for F12?
On Sat, Jun 13, 2009 at 10:53 AM, Robert 'Bob' Jensenb...@fedoraunity.org wrote: Does no one remember what happened last time the CD ball was dropped? Lets not repeat history just for fun. We have been down this road before, it was ugly and only lasted one release. Torrent tracker numbers BTW do not always tell the truth. In many cases in these less fortunate areas one person will download the ISO images, then make CDs for any one in the surrounding villages. Sneakernet is alive and well. I asked about this topic a few minutes ago in the #fedora-social IRC channel because we seemed to have a pretty diverse mix of people chatting. There was a resounding response that the CDs need to be kept. How do we do a better job getting an accurate picture of install media usage patterns? To be honest I don't have a good idea on how to trend completely sneakernet activity..even as a historic relative measurement against itself. If the resulting installs never touch a network for updates, I don't have a way to see them at all. If you have ideas I'm all ears. Matt's attempt at trending it is just a starting point. We could do more, and I'm willing to help build up trendable metrics from the logs. But we need to agree that the metrics will help us make decisions as to how to support niche media. Is there a need to define a concept of secondary or legacy media for niche media? I don't have a problem keeping niche media in production (if there's room for it in our infrastructure), but I'd like to see a process that empowered the users and supporters of the media target to take more responsibility for it during releases inside the Fedora process. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Phoronix] Ubuntu 9.04 vs. Fedora 11 Performance
On Fri, Jun 12, 2009 at 5:28 AM, Casey Dahlincdah...@redhat.com wrote: Because they gave us a bad grade and now we're butthurt and we're taking our ball and going home so there? Because that's what everyone's going to hear, even if its not what we say. What I have a problem with is the lack of information about methodology that would allow me to interpret the result in comparison to other results using slightly different methodology.. I don't have a problem getting a bad grade. I do have a general problem with people who publish unexpected behavior regressions but don't actually use the open development process to drive feedback directly to developers. If we deserve a black eye over it, fine I'll stand up and take my punches. But the laypress can't seem to be bothered to actually be a part of the development processes which would actually drive solutions to problems..and that bothers me..greatly. For some reason, once you find yourself a soapbox to stand on, you immune to actually reporting problems in the established communication channels. This is the sort of thing I would have love them to do at the alpha and beta release points...open bug tickets about..and if the issue is unsolved by release time..then so be it..just as long as they link to the bug ticket and the technical discussion on the ticket when they punch in the eye. I know its a pipe dream...the laypress taking a proactive interest in seeing problems resolved instead of just talking about them. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Phoronix] Ubuntu 9.04 vs. Fedora 11 Performance
On Thu, Jun 11, 2009 at 9:51 AM, Eric Springererik...@gmail.com wrote: Likely for the same reasons we have a bug tracker instead of a 'what works list'. But I agree, Fedora performed quite favourably especially taking into consideration the database benchmarks. The problem with knowing that Phoronix got a head scratching result for Apache.. doesn't really tell us anything useful. If I were going to treat this as a bugreport I would have liked to have seen at least a me too effort to confirm the result from the person...contributing..the benchmark snippet. I personally have very little faith in the laypress's ability to communicate information developers can actually use to make sense of unexpected problems as its in their own interests to sit on those problems and write about them outside of the affect project's communication and bug reporting processes. If this is going to be taken seriously an actual tester or contributor needs to start trying to confirm it..someone who can be relied on to work with the package maintainers and developers. The laypress reviewers who do things like run benchmarks are as a breed highly unreliable when it comes to actually HELPING diagnose the problem. Numbers for the sake of numbers isn't the point. The benchmarks are only as useful as your commitment to followup on diagnosing potential problems. The laypress continues to miss the point about having an open development process by which users can engage with developers. I live for the day when each and every problem reported in articles written by the technical laypress, comes with cross-referenced links to bug reports opened by the laypress journalists who discovered the problem so the discussion on the diagnose of the problem can continue where the right people..the people who can provide and integrate a solution..can actually deal with it. No the technical laypress isn't actually interested in seeing problems solved...they just want to find things talk about. The worst part is there's no obvious place to start looking for a difference for the Apache benchmark. The article doesn't make any suggestions as to where the difference is. Unlike the filesystem tests where there is a clear difference in underlying system configurations and even Phoronix picked up on it as a probable cause. Numbers for the sake of numbers. Do they even understand how to interpret their own test suite as a diagnostic tool? I guess what we really need is the same test run on stock F10 and F11 on the same hardware and see if there is a regression there. If its selinux latency they'll both be impacted and it should be a wash. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Phoronix] Ubuntu 9.04 vs. Fedora 11 Performance
On Thu, Jun 11, 2009 at 10:44 AM, Xose Vazquez Perezxose.vazq...@gmail.com wrote: then compile apache ; exec it and run ab: $ ab -n 50 -c 100 http://localhost:8088/test.html So did they use the phoronix-test-suite that is packaged as part of fedora and used fedora packaged apache binaries? Or did they build their own local versions of everything outside of the Fedora build system. Knowing if they are testing Fedora built and packaged apache matters a lot in terms of interpretation. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: USB autosuspend in F12
On Tue, Jun 9, 2009 at 10:32 AM, Matthew Garrettm...@redhat.com wrote: Through F12 I'm going to be slowly enabling autosuspend on various pieces of USB hardware. The aim is to ensure that it's only enabled on hardware that supports it. As you move forward with this across the devicescape, how are you going to selectively enable devices to apply autosuspend to? Is this done by a whitelisting of specific device ids? Or is this going to be done based on a detected set of capabilities and then pruning that back with a blacklist? I've got some exotic homebrew usb equipment that I'm going to have to troubleshoot on my own, so it would be useful to know how you are going to slice the device space so I can figure out which devices should and should not be affected..eventually. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Packager = Programmer?
On Wed, Jun 3, 2009 at 11:43 PM, Frank Murphy (Frankly3d) frankl...@gmail.com wrote: Does trying to become a packager. Involve being currently a Developer, as in Programming skills\certification, whether Perl\Python\c++ etc. I would put it this way there should be an expectation that packagers are willing to learn programming skills relevant to the packages they are maintaining. There's no proficiency level or anything like that. But if you aren't interested in learning how to read and use python..you should probably not maintain a package that is heavily dependent on python. Those are the sort of personal choices that can turn the time you gift as a volunteer contribution to Fedora into a burden instead of having fun doing the work. I personally do not maintain package for things that are written in languages I'm not interested in learning how to use. I avoid perl. I avoid java. I generally have no personal interest in developing or refining my ability to read or use either(but it seems like I won't be able to avoid the java trap for long as part of my day job). And as a result I don't try to maintain packages for either. I wish I knew how to organize some optional program language specific skills development sessions aimed at packagers that made sense..but I don't. Nothing like a cert or anything like that, but to introduce packagers and potential packagers to languages just as a good skills building exercise. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Comaintainers needed - Gnote and Transmission
On Thu, Jun 4, 2009 at 11:22 AM, Rahul Sundaram sunda...@fedoraproject.org wrote: Both are active and responsive upstreams and do have frequent releases. If anyone want to be comaintainer, feel free to apply. If you have a good understanding of the codebase or would be able to help with fixes, that would be nice. I'm in! -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora Bugzilla Statistics 2009-05-26 - 2009-06-01
On Mon, Jun 1, 2009 at 11:32 PM, Brennan Ashton bash...@brennanashton.com wrote: There is much more information that can be pulled via a turbogrears app we are running. But I am looking to see what is useful in terms of a weekly report. I have the date tuesday to tuesday as it matches up with the Bugzappers meeting time. Are you geared up for component by component reporting or perhaps groups of components? How do triagers currently organize their time when picking components? Would component-by-component reporting help spread/grow triage manpower into hot spot areas of the repository? And the flipside, can you visualize how triage manpower is actually spread through the repository currently? Are our expert smoke jumpers landing near the hotspots without a lot of coordinated effort? or is triage being done mostly by maintainers, fighting the local fires in their back yards? And in the future I'd like to see weekly reporting feature by feature that gives a sense of progress on bugs loosely associated with a feature proposal. Can we visualize the effect that feature specific test days have on the bug lifecycle for that feature? Also reporting on tracking the aggregate progress on tracker/blocker bugs for the next release. Can you highlight work or drive interest in working on release target and blocker bugs in some way in the reporting? . -jefSaw my first smoke jumpers in action like a mile away from me last weekend...hence the imageryspaleta -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora Bugzilla Statistics 2009-05-26 - 2009-06-01
On Tue, Jun 2, 2009 at 8:53 AM, Adam Williamson awill...@redhat.com wrote: It could do, but on the other hand, we're mostly getting to the point where the components that lack coverage are ones which need a triager who's already knowledgeable about that component: we can't just parachute someone in. (see e.g. anaconda and kernel). How short is that list of components? Can you visualize that? Just identifying that finite list could help motivate exactly that sort of recruitment effort needed to fill the need. If we identify the short list accurately, can we then advertise the short list as a rewarding challenge to undertake? Our very own elite highly trained specialists..our 00's..our A-team. So highly prized they even get codenames and catch phrases. -jef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gnaughty is a hot babe
On Fri, May 29, 2009 at 5:28 PM, Kevin Kofler kevin.kof...@chello.at wrote: Or even the mail client which happens to be called Evolution. I know for a fact that said mail client is a product of intelligent design...so that should take the edge of that particular debate. -jefnice threadjacking attempt, I salute you!spaleta -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Can anyone volunteer to help with a Python 2.5 / Python 2.4 code issue?
On Fri, May 1, 2009 at 11:57 AM, David Malcolm dmalc...@redhat.com wrote: So where's the 2.5-only code? Im getting python import errors trying to use the triager link off the main page when running on Centos no such error running under Fedora 9. Something's different. But I need more background on the problem. -jef ___ Fedora-python-devel-list mailing list Fedora-python-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-python-devel-list
Re: Can anyone volunteer to help with a Python 2.5 / Python 2.4 code issue?
On Fri, May 1, 2009 at 12:06 PM, Jeff Spaleta jspal...@gmail.com wrote: Err reverse that.. python 2.4 no defaultdict class in collections module python 2.5 collections does have it well a simple change defaultdict=dict in controllers.py seems not to cause any damage. It really depends on if you need the minor changes between defaultdict and a regular dict. I could go though the trouble of building out the defaultdict subclass by hand and overriding _missing_ in a similar way to make use of defaultfactory. That would be the correct fix. But is it needed? Do you ever actually use defaultfactory functionality in the codebase? So one problem down? anything else? The other errors im getting exist on both my F9 and Centos5 setup so they arent python2.5 specific... just me not having everything configured correctly. -jef ___ Fedora-python-devel-list mailing list Fedora-python-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-python-devel-list
Re: Anaconda: good work!
On 3/22/06, Thomas Canniot thomas.cann...@laposte.net wrote: Maybe we could do something here that really helps people, newbies who are just installing their first linux distribution. I dreamt of an anaconda that helps newbies make their first steps in Fedora Core. Screw that... embedded game of nexuiz would be much better. As for the mock up... perhaps an embedded ogg video of desktop interactions with localized closed caption text ala annodex. -jefso what if anaconda would require a minimum of 2 gig of ram for the video to play while anaconda does packaging actions.spaleta
Re: Unable to mount cd dvd after upgrading to FC5
On 3/23/06, Igor Jagec igo...@vip.hr wrote: 1) if you tried to run it manually... does that mean it wasn't running already? Most likely it wasn't. hald not running..even in fc4.. is a problem that will result in a number of weird symptoms. Unfortunately most likely doesn't help narrow the underlying problem down, i was hoping for confirmation while you were experiencing the problem. 2)is the dbus stuff running correctly? /sbin/service messagebus status [r...@munja ~]# /sbin/service messagebus status dbus-daemon (pid 4147 1558) se izvršava... Which means it runs properly. BTW I tried to get english output with 'export LANG=en_EN.ISO8859-1', and it didn't help for that command, and for some it did (?). Never mind. 3) does the outout of lshal show your hdc and hdd devices? [r...@munja ~]# lshal|grep hdc I wasn't asking for a grep.. because the grep won't extract all the information in the block of output that covers all the properties. I specifically ask for a block oufput and I tried to define what the beginning and end of the block looks like. Unfortunately you didn't seem to understand what I was asking for. I didn't know how to provide you more information, but I hope that above will help a bit. I saw on the redhat's news group that I'm not the only one who experienced that problem. gnome-mount isnt crashing for me... and I don't see any bugreports about gnome-mount crashing so far reported in bugzilla by anyone. If this is a common occurance, and its a real bug, someone from those news groups needs to actually file a bug report if they want the crashing fixed. People can discuss crasher issues in forums and newsgroups and mailinglists forever.. but if its not filed in bugzilla..you can never be sure the developers who need to be aware of it will know about it. -jef
Re: Anaconda: good work!
On 3/23/06, Ralf Ertzinger fed...@camperquake.de wrote: This step (what does that do, anyway?) is _slow_. 30 seconds per schema on my 500MHz iBook. Updating gnome-games takes ages. I'd have to agree, I've seen the schema updates take quite a bit of time. So long in fact that I actually flip over and start a top to see if the rpm trasaction is stalled or not. -jef
Re: gnome-screen-saver unlock artwork
On 3/23/06, Thomas J. Baker t...@unh.edu wrote: Has anyone else seen this? that's awesome!! how to diagnose that lets see first guess would be some sort of gdm/gtk/gnome theming which could be related per user? Like the gnome splash theme.. isnt that per user configurable now.. and thus have some sort of systme default as well. anything in /var/log/message that seems to be associated with screensaver turning on or the lock dialog showing up? -jef
Re: Anaconda: good work!
On 3/23/06, Hans Kristian Rosbach h...@isphuset.no wrote: Just thought I'd voice this before the maintainers just let go and completely focus on the one for FC6. I bet obvious fixes will be detected in the starting phase of developing for FC6 and those might be backported to FC5 aswell. Installer bugs happen with pretty much each release. fixed boot.isos are usually made available as links in bugzilla tickets as issues are addressed and I believe there is a mechanism which is applied to incorporate fixes into the mirrors so people doing network installs can avoid some problems. But at no point have I ever seen any discussion at any time which suggests the release team is interested in spinning up replacement isos and distributing them. And quite frankly I don't think this is the most appropriate time to suggest a change in the release model used. This is the sort of thing that should be debated during the testing phase, so plans can be in place to support respins if you are able to convince the people who have to do them that its a good idea. I don't think your request for fc5 anaconda updates post release day is going to change any minds as to the support tradeoffs associated with official respins that incorporate installer changes. -jeftoo little too latespaleta
Re: Unable to mount cd dvd after upgrading to FC5
On 3/22/06, Igor Jagec igo...@vip.hr wrote: I even tried to run hal deamon manually, to play with gnome-mount and so on, but all of that didn't help. I tried to 'rpm -V hal', but I got no output. Is there any way to solve that problem manually? To make hal to detect my hdc and hdd devices? Any help would be highly appreciated. 1) if you tried to run it manually... does that mean it wasn't running already? 2)is the dbus stuff running correctly? /sbin/service messagebus status 3) does the outout of lshal show your hdc and hdd devices? there should be a block of output starting with udi = something and ending with linux.sysfs_path = something for both the hdc and hdd device for example look for block.device = '/dev/hdc' near the end of the block of information that defines the hdc device 4) I'm still not sure what you attempted exactly, so its pretty difficult to provide any feedback. -jef
Re: Wild and crazy times for the development tree
On 3/20/06, Bill Nottingham nott...@redhat.com wrote: DVD downloads outnumber CD downloads roughly 2:1 on x86, 5:1 on x86_64, and 6:1 on ppc. Is that for fc5? I'd think the same statistic over the lifetime of a release would be more interesting. I'd argue the people who participate during the release surge are a skewed sample of the overall population. -jef
Re: Mirrorlist missing mirrors?
On 3/21/06, Avi Kivity a...@argo.co.il wrote: [...@firebolt ~]$ wget -q -O - http://fedora.redhat.com/download/mirrors/fedora-core-5 http://download.fedoraproject.org/pub/fedora/linux/core/5/$ARCH/os/ A few more mirrors would help reduce the load... the file fedora-core-5-redirect is an actual mirrorlist file. Appearently there is suppose to be some serverside redirect magic going on which is non-obvious from the client side yum configuration. I've turned on verbose mode on the fastestmirror plugin I'm using to see the list of mirrors which fastestmirror plugin is suppose to be timing to make its judgement. And I'm not seeing the mirrors as listed in the -redirect file in the fastestmirror output. So from my pov whatever magic on the server which is suppose to be redirecting clients to use fedora-core-5-redirect mirrorlist isn't working afaict. I'm not sure whom to address this problem to exactly. The redirect issue affects both core and updates in the fc5 configs. -jef
Re: Mirrorlist missing mirrors?
On 3/21/06, Jesse Keating jkeat...@j2solutions.net wrote: What exactly do you want from me here? From you in particular? That's a difficult question to answer because I'm not sure in a position to provide me with what I'm seeking... since you have already pointed out that I need to schedule a meeting between Mr. Lee and the magic lasso of truth that I have on loan from wonder woman. This in itself could be considered a failure. File a bug as such. I'm attempting to do my best to ensure than whatever bugs are filed are not closed as worksforme because of lack of reproducibility or consistency of behavior. I would like to be able to find a way to produce an auditable trail of clientside output which unsuspecting users can be directed to generate as needed per incident in an effort to document what could very well be a sporadic symptoms in order to pinpoint the if there is an underlying problem with the new redirect service. People are already confused by the changes in the mirrorlist file. If you're getting repeated failures running yum, but pointing yum to the -redirect version of the mirrorlist file consistently works, this would indicate a failure in the way the redirect is working for yum. And if using -redirect directly also produces sporadic failures for some people with similiar clientside symptoms? There are other, pre-existing issues which some users can run into.. things like timeout settings which could be mis-diagnosed as problems associated with the new redirect layer simply because the redirect process is new and opaque from the client pov. -jef
Re: Mirrorlist missing mirrors?
On 3/21/06, Jeff Spaleta jspal...@gmail.com wrote: And if using -redirect directly also produces sporadic failures for some people with similiar clientside symptoms? There are other, pre-existing issues which some users can run into.. things like timeout settings which could be mis-diagnosed as problems associated with the new redirect layer simply because the redirect process is new and opaque from the client pov. Very frustrating... how do I help users who are complaining about errors like.. http://download.fedoraproject.org/pub/fedora/linux/core/updates/5/i386/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. Error: failure: repodata/primary.xml.gz from updates: [Errno 256] No more mirrors to try. now that there is a serverside redirector in place.. how do I help track down which mirror is out of sync so it can be reported appropriate? And appearantly even though there are multiple instances of the same url in the mirrorlist, yum doesn't fail over to the next listing like they are different mirrors like it use to when the mirrorlist was a set of distinct mirrors. Instead the error occurs and yum bails like there was only a single mirror in the list. The single repeated redirecting URL appears to shortcircuit mirrorlist functionality. -jef
Re: Mirrorlist missing mirrors?
On 3/21/06, Elliot Lee sopw...@redhat.com wrote: On Tue, 21 Mar 2006, Jeroen van Meeuwen wrote: It seems to be yum that cannot cope with the redirects. The yum I have installed (yum-2.6.0-1) seems to handle the redirects fine. It's difficult for me to make such a claim based on yum-2.6.0-1 output that I have available. Things may very well be redirected as expected but there's not information being provided which I can use to confirm that. On top of that.. the mirrorlist approach fails to failover to a 2nd mirror if there is a sync problem.. when only the redirector is used as the only mirror in the list..even if its repeated in the list. That has to be counted as regression in functionality... even if the redirecting is working. Again very difficult to know whats going on here from the clientside. I'd really appreciate it if you could define a reasonably useful recipe for generating auditable content that I can direct users to use so we can track which mirrors are causing problems.. or if the redirection itself is causing a problem. Is the only way to audit this going to be having users fire up packet sniffers and logging individual packages for review? I'd really like to avoid that. -jef
Re: python module loading broken on fedora?
On 3/17/06, Neal Becker ndbeck...@gmail.com wrote: I've been trying to track down a problem with python module loading for multarch (x86_64). I think we have a problem. The discussion so far is archived here: http://mail.python.org/pipermail/python-dev/2006-March/062462.html It seems that the system Fedora has setup here: http://fedoraproject.org/wiki/Packaging/Python is not really correct. to clarify for those wanting a quick summary of the referenced thread the specific issue being the macros python_sitelib and python_sitearch resolving to different paths on x86_64 and the upstream python discussion seems to indicate this is bad mojo and not something python is expected to handle gracefully.. -jef
Re: which gstreamer versions in official fc5?
On 3/16/06, Jeremy Katz ka...@redhat.com wrote: Not everything got upgraded. It was basically a matter of looking at diffs and trying to decide what was safe. I don't think that anyone is 100% happy with how that process went. The plan is definitely to get the rest of the 2.14 final packages out as an update ASAP after Monday and there's also going to be an effort to actually track the stable releases as they're done this time around :-) Thank you for giving me yet another excuse to sit on the patches to make istanbul in Extras build on 64bit. Now that i know the new gst is going to be updated asap... makes working on gst08 istanbul package this weekend particularly pointless when I'll be able to finally roll a gst 0.10 with the gst update. -jef
Re: No more selinux-policy-*-sources
On 3/14/06, Dennis Jacobfeuerborn d.jacobfeuerb...@conversis.de wrote: I've taken a look at AppArmor and it looks like a much more incremental and easier to use solution than selinux. It's not as powerful but all this power doesn't help much if most people will turn off selinux anyway because it gets in the way. Has anyone heard of any efforts trying to port it over to Fedora? My understanding is that it still requires kernel patches which are not in the mainline kernel yet. If you want to use it.. you'll have to use a patched kernel. Snowball's chance in hell the Fedora kernels are going to include apparmor specific patches that should be going into mainline kernel for everyone to use. You want to see it ported and see it available in Fedora Extras... then go chew the novell developers ears off about getting the required kernel patches into the mainline kernel. Please go read up in the lkml archives about Immunix's SubDomain (newly renamed as Novell AppArmor) to gain insight on where in the process things are to get Immunix's..err i mean Novell's kernel patches into the mainline kernel. -jefNew name==new press release==old newsspaleta
Re: Stability of firefox
On 3/9/06, Louis E Garcia II louis...@bellsouth.net wrote: Has anyone been encountering stability issues with firefox? Seems to segfault randomly when trying to download. Also a few times loading pages. did you install any additional extentions or plugins? -jef
