Re: Rawhide is annoying me!
On 02/07/2011 01:18 AM, David wrote: > On 2/6/2011 5:41 PM, Christopher Aillon wrote: >> On 02/06/2011 01:38 PM, David wrote: >> >> >> Well... this is one of the things we want to get out of the GNOME 3 >> test days. If you aren't getting either a shell or fallback mode, we >> need to know what hardware you're using so we can make sure it's handled >> appropriately. Filing a bug with a smolt profile would help with that, >> or check out the GNOME 3 test day page and enter your data there. Will there be a spin for us that already know that our hw is Gnome3 compatible without out all that backwards compatibility cruff that will give us a pristine Gnome3 experience? :) > Well yeah. That part I understand. But.. > > As of late it seems to me that *some* not *all* devs have taken the > attitude that 'you will accept what we think that you need' and you will > be quiet'. A lot if not most of those decisions are made by the Gnome UI Designers not the developers themselves so a lot of existing *features* have not been coded out they simply no longer are exposed to the end user as an *option* in the UI but *power* users are still able to tweak those setting via gconf/dconf editors and some of that UI Design is debatable to say the least from ( my ) usage perspective. > Or your hardware is really old and/or crappy so we no longer > care about you. We currently support [1]. > And the Linux that I first started using was a 'works for everyone' type > of OS system. From the rich guy with the state of the art equipment to > those less fortunate with older equipment or systems and slow dial-up > access that is 'as good as it get here' in 'my country'. > > A people OS. Meant for all and not just mean for the privileged few. > If you are running/relying on a steam powered technology then use *DE that are designed specially support that like XFCE or LXDE. Fallout Gnome users on older hw will only ensure healthy grows usage and community surrounding the other *DE . As I see it Gnome is taking unavoidable necessary steps to keep it self as a viable Desktop option in the *modern* age on a *modern* hw and from my perspective they are about 1 - 2 years to late in the game which is probably due to various reason like for other components not being in ready enough state for them to take these necessary steps. And from my perspective they should focus only as best as they can with integration and support on one platform GNU/Linux and stop supporting altogether any other *nix platform out there to be competitive to other Desktops on other OS out there. > As I said. I can deal with this. But my mother could not. nor her > husband. Nor my brother. Nor my sister. One out of five, 20%, in just my > immediate family is not a good ratio. If Gnome is not suitable for you family usage is there anything preventing you from using any of the other *DE alternatives we ship? And why do you want to jump to F15 why don't you and or family just stick with F14 until it EOL's then check the status then? F14 was relativley feature less which many may consider a feature in it's self but given our current feature set that we are introducing in F15 to get the best experience out of those features you will need to be on relatively modern hw preferably with SSD drive ( to take fully advantage of Systemd ) and it's my personal recommendation to you should you decide to switch to F15 that you do not upgrade you current installation but rather back up you data and do a clean install for the F15 release and from that point on can choose to upgrade to newer Fedora releases. JBG 1. http://docs.fedoraproject.org/en-US/Fedora/14/html/Release_Notes/sect-Release_Notes-Welcome_to_Fedora_14.html#sect-Release_Notes-Hardware_Overview -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unavailable Maintainer: Peter Gordon
Le samedi 05 février 2011 à 16:31 -0700, Kevin Fenzi a écrit : > Greetings. > > It seems that Peter has been unavailable for Fedora packaging work for > a while now. I have been maintaining two of his packages, (midori and > webkitgtk) but there are a number of others which may need attention. I also tried to contact Peter about this bug on epiphany-extensions, without any success: https://bugzilla.redhat.com/show_bug.cgi?id=592801 I sent him a first mail about this issue and to help him maintaining this package, but (still) no answer. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide is annoying me!
On 2/6/2011 11:34 PM, Bruno Wolff III wrote: > On Sun, Feb 06, 2011 at 23:12:06 -0500, > David wrote: >> 5800 GTX card to work properly. The Linux drivers do not work as they >> should. For me. And something about the version of Xorg and this, or a >> combination of theses, makes major problems for me. Broke my desktop and >> the general Gnome 'expected to work things'. >> >> No one else has these problems? Maybe. More than likely 'no one else' >> *yet*! What for now? After the release? Best wishes. > > I agree that video driver support should be a higher priority in Fedora. > I waste a lot of time in rawhide because of video driver regressions. > Unfortunately it would take a long time for me to get good enough at video > drivers and dropping what I work on now to help out there doesn't see to > be a good idea. For some reason Fedora has serious problems with my old CRT monitor that is connected to my test machine. Fedora see 'nothing' while another distro that shall be nameless sees 1600x00 but not the maker. Since Fedora removed system-config-display I can no longer get a good 2D resolution and it takes real drivers for that. Also the Linux drivers do not control the GPU speed or the cooling fan speed. >> Do as you wish of course. I would suggest that you offer this as a >> option. A 'try this' and if it works *great* but if it blows up get >> easily back this way. > > The gnome 3 introduction could have been smoother. At the least some better > help on what to do, as there were quirks for people already running rawhide. > In general this has been a pretty sucky rawhide for me, but I really needed > to use it to work on ogre and the lzma live image stuff. All of that *I* understand I have 'tried' development Linux install for 8-10 years and broken, stopped working, is crap, is an expected thing. This, however, without an opt-in or at least a very easy 'OMG it is killed!! Click-here [] to fix' is going to create a world of grief. . >> I appreecaite all of the work that you people do. Really. But there are >> times that I disagree with the marketing paths you take. >> >> The 'fallback' IMO should not be that but be a 'try this' with the >> 'fallback' defaulted if a failure happens. > > While I am not a fan of gnome 3 so far, I think that making it the default > does fit with the Fedora development model. Again not a problem for me. i can fix this. But as long as those that can not fix this are not run off to other distributions. Or back to Windows. -- David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide is annoying me!
On 2/7/2011 4:07 AM, "Jóhann B. Guðmundsson" wrote: > On 02/07/2011 01:18 AM, David wrote: >> On 2/6/2011 5:41 PM, Christopher Aillon wrote: >>> On 02/06/2011 01:38 PM, David wrote: >>> >>> >>> Well... this is one of the things we want to get out of the GNOME 3 >>> test days. If you aren't getting either a shell or fallback mode, we >>> need to know what hardware you're using so we can make sure it's handled >>> appropriately. Filing a bug with a smolt profile would help with that, >>> or check out the GNOME 3 test day page and enter your data there. > > Will there be a spin for us that already know that our hw is Gnome3 > compatible without out all that backwards compatibility cruff that will > give us a pristine Gnome3 experience? :) > >> Well yeah. That part I understand. But.. >> >> As of late it seems to me that *some* not *all* devs have taken the >> attitude that 'you will accept what we think that you need' and you will >> be quiet'. > > A lot if not most of those decisions are made by the Gnome UI Designers > not the developers themselves so a lot of existing *features* have not > been coded out they simply no longer are exposed to the end user as an > *option* in the UI but *power* users are still able to tweak those > setting via gconf/dconf editors and some of that UI Design is debatable > to say the least from ( my ) usage perspective. > >> Or your hardware is really old and/or crappy so we no longer >> care about you. > > We currently support [1]. > >> And the Linux that I first started using was a 'works for everyone' type >> of OS system. From the rich guy with the state of the art equipment to >> those less fortunate with older equipment or systems and slow dial-up >> access that is 'as good as it get here' in 'my country'. >> >> A people OS. Meant for all and not just mean for the privileged few. >> > > If you are running/relying on a steam powered technology then use *DE > that are designed specially support that like XFCE or LXDE. > > Fallout Gnome users on older hw will only ensure healthy grows usage and > community surrounding the other *DE . > > As I see it Gnome is taking unavoidable necessary steps to keep it self > as a viable Desktop option in the *modern* age on a *modern* hw and from > my perspective they are about 1 - 2 years to late in the game which is > probably due to various reason like for other components not being in > ready enough state for them to take these necessary steps. > > And from my perspective they should focus only as best as they can with > integration and support on one platform GNU/Linux and stop supporting > altogether any other *nix platform out there to be competitive to other > Desktops on other OS out there. > >> As I said. I can deal with this. But my mother could not. nor her >> husband. Nor my brother. Nor my sister. One out of five, 20%, in just my >> immediate family is not a good ratio. > > If Gnome is not suitable for you family usage is there anything > preventing you from using any of the other *DE alternatives we ship? > > And why do you want to jump to F15 why don't you and or family just > stick with F14 until it EOL's then check the status then? > > F14 was relativley feature less which many may consider a feature in > it's self but given our current feature set that we are introducing in > F15 to get the best experience out of those features you will need to be > on relatively modern hw preferably with SSD drive ( to take fully > advantage of Systemd ) and it's my personal recommendation to you should > you decide to switch to F15 that you do not upgrade you current > installation but rather back up you data and do a clean install for the > F15 release and from that point on can choose to upgrade to newer Fedora > releases. > > JBG > > 1. > http://docs.fedoraproject.org/en-US/Fedora/14/html/Release_Notes/sect-Release_Notes-Welcome_to_Fedora_14.html#sect-Release_Notes-Hardware_Overview > "steam powered technology". This is pretty much what I was talking about here. My 'real' machine, the one that I use for work, is modern within 12 months. My 'made from taken out parts' machine is not. As I said I can deal with that. But there are others in the Fedora Community, no offense meant to anyone here, that are not in a position to deal with the 'latest and greatest eye-candy Desktops. First came KDE 4.x. And now come Gnome 3. At least the 'fancy fluff' in KDE is easily disabled. It sounds like Gnome 3 can not. Is that true? There are always users on the Fedora Users list with older equipment looking for help. What is your answer to them when they discover that their 8-10 year old computer is 5 years too old when it is the best that they have? Or can afford? Go buy a new computer? Or will it be - Go away? That would be sad. Do as you wish. I am sure that you will. But IMO the default should work. Or the fallback should be auto-magic with a polite explanation to the user of what just happene
Re: Rawhide is annoying me!
On 02/07/2011 12:29 PM, David wrote: > "steam powered technology". This is pretty much what I was talking about > here. My 'real' machine, the one that I use for work, is modern within > 12 months. My 'made from taken out parts' machine is not. As I said I > can deal with that. > > But there are others in the Fedora Community, no offense meant to anyone > here, that are not in a position to deal with the 'latest and greatest > eye-candy Desktops. First came KDE 4.x. And now come Gnome 3. At least > the 'fancy fluff' in KDE is easily disabled. It sounds like Gnome 3 can > not. Is that true? Well I'm pretty sure you can force Gnome3 in compatibility mode ( worst case scenario remove mutter/gnome-shell that I believe should suffice ) but if you want too but it should not be necessary since it should fallback automatically to that mode if your HW does not support Gnome Shell but I'm pretty sure that compatibility mode will not give you the same end user experience ( it did not for me when I hit it playing around in rawhide it looked like this [1] ) as you have with gnome 2.x. and eventually in the long run I'm pretty sure they will remove that backwards compatibility altogether. > There are always users on the Fedora Users list with older equipment > looking for help. What is your answer to them when they discover that > their 8-10 year old computer is 5 years too old when it is the best that > they have? Or can afford? Go buy a new computer? Or will it be - Go > away? That would be sad. > Any particular reason you refuse to accept XFCE and LXDE as alternatives to run on old hardware it is after all part of their target user base and those users should simply be directed their way... > Do as you wish. I am sure that you will. But IMO the default should > work. Or the fallback should be auto-magic with a polite explanation to > the user of what just happened. It should if not do as Christopher mentioned and remember bugs that don't get reported wont get fixed... "If you aren't getting either a shell or fallback mode, we need to know what hardware you're using so we can make sure it's handled appropriately. Filing a bug with a smolt profile would help with that." Not a bad idea providing a polite explanation which asks users to upgrade their hw or refer them to use alternatives to Gnome such as XFCE and LXDE which might be better suited to run on their old hw.. JBG 1. http://bugzilla-attachments.gnome.org/attachment.cgi?id=180036 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide is annoying me!
On Sat, 2011-02-05 at 18:01 +, Paul F. Johnson wrote: > Hi, > > I'm having two problems on two different boxes, both running rawhide. > > Problem 1 (my main box) - whoever decided to remove the default > applications thing from the menu, please put it back. I can understand > the rational, but it currently means that on firing up my desktop, I > don't have nautilus running as soon as I log in which is an absolute > pain. I have to configure my sound every time to use the soundblaster > rather than the on board card and it's generally just annoying. > > Is there a way that I can set the start up applications now? The same way the old app used to do it, but by hand. The "login items" preferences for the user accounts panel isn't implemented yet. > Problem 2 (laptop). Gnome is dead. I can use KDE for my desktop but > gnome, irrespective of the user, gives me a blue stripy screen and > that's it. I've tried creating a new user in case it was my settings, > but nope, blue stripy screen. I am not sure if it's related to gnome-do > (I installed it, didn't like it, yum removed it) removing something it > shouldn't have, but it does mean my laptop, unless using KDE, is no use. Login at the console, and check your ~/.xsession-errors. My guess is that there's a mismatch between the mutter, or gnome-shell plugins and the gtk3 package installed (I saw this on my laptop as well). Upgrading the machine should fix it. Cheers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora GNOME 3 Test Day #1 coming up tomorrow
On Fri, 2011-02-04 at 22:16 +0100, Michael Schwendt wrote: > On Fri, 4 Feb 2011 21:09:41 +0100, Christoph wrote: > > > > * At the graphical login screen, I cannot log in. I did the useradd > > > manually, and it appears as an empty entry to click on. Authentication > > > fails. Cursor doesn't show any asterisk characters either when typing > > > in the passphrase. > > > > The entry is empty because you did not provide a full name to useradd. > > I know that, just didn't mention it. IMO, it's a usability bug if the > login manager isn't clever enough to fall back to the username. File a bug about that, against gdm. > > Click other user, enter username, then password and you are done. This > > also works when the user list is empty which happens randomly. ~C > > As mentioned on test-list, keyboard input in X doesn't work for me at all. There were ibus and at-spi2-atk bugs. Remove those packages and text input will work again. The at-spi2-atk bugs are fixed upstream, and I believe the ibus ones are already fixed in rawhide. > Hence I cannot enter anything. Not in GNOME and not in XFCE either. > I *would* have tested the snapshot a bit, but so far I can't. The > GNOME Shell is strange, btw. The names below the various icons are > truncated with "...", and not even moving the mouse over them expands > them. There's a bug about that. See my blog post: http://www.hadess.net/2011/02/gnome-3-test-day.html Cheers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Preferred & Startup applications gone?
On Fri, 2011-02-04 at 08:52 +0100, Kevin Kofler wrote: > Adam Williamson wrote: > > it's a design feature, we are told. the intent is that applications > > should offer the option to set themselves as the default, instead of the > > desktop providing a central config point. > > To the GNOME developers (Adam, I know you are just the messenger): > > This is very broken. You cannot expect non-GNOME applications to support > setting themselves as the default in GNOME. (For example, if you want to > use, say, Konqueror as your default browser, how would you set that? > Konqueror obviously does not support GNOME preferences.) There's no GNOME preferences involved. Make sure Konqueror sets itself as the handler for x-scheme-handler/http (and https) and you're done. > Plus, we have seen where leaving this to the applications leads to on > Window$: applications fight for being the default and the user never gets > asked! Instead, merely running an app will change his/her file associations, > leading to a ping-pong effect. Please do not head down that road! We're talking about browsers and mailers. Browsers already do that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide is annoying me!
David Boles wrote: > For some reason Fedora has serious problems with my old CRT monitor > is connected to my test machine. Fedora see 'nothing' while another > distro that shall be nameless sees 1600x00 but not the maker. Since > Fedora removed system-config-display I can no longer get a good 2D > resolution and it takes real drivers for that. This is either because: a) there's a timing bug in the DDC code that we're hitting and they're not, b) your monitor no longer works with DDC (or never did) and they're installing enough xorg.conf to compensate. The former is a bug, and you could detect if it were the case by comparing the X logs from the two OSes. If one prints an EDID block and the other does not, there you go. For the other, feel free to hack s-c-d into shape, or (more preferably) add the support to gnome-display-properties or whatever your DE's tool of choice for that is. (Actually now that I'm re-reading you, it's not clear if you're using "real drivers" and "the Linux drivers" to refer to different things, for example, nvidia versus nouveau. If that's what you're doing, and nvidia is succeeding at DDC where we're not, then the RE challenge seems pretty obvious.) > Also the Linux drivers do not control the GPU speed or the cooling > fan speed. This may well be true, but it's hardly fair to blame Fedora for that. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rails 3 is in rawhide
I am pleased to announce that the last packages required for Rails 3 support in Fedora have been pushed to rawhide and successfully built in anticipation of the Fedora 15 release. Rails 3.0.3 is a major upgrade from 2.3.8 which brings some API incompatibilities as a trade off for many new features. Rails 3 has been submitted and accepted as a feature for Fedora 15. http://fedoraproject.org/wiki/Features/Rails_3.0.3 Many many thanks goes to Fedora contributors Vit Ondruch and Minnikhanov for all of their hard work packaging gems and reviewing packages. I look forward to continuing to work with them and seeing their contributions in the future. -Mo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.46.0
On Friday, February 04, 2011 05:33:24 am Petr Machata wrote: > Hi, > > beta of boost-1.46.0 was released recently and packaged yesterday. It's > now in the git, and a scratch build[2] was done. This is in preparation > for final release that should be out on 7th, just before the feature > freeze. Providing boost-1.46.0 is one of features of F15[1]. > > I'm in the process of test-driving a couple packages locally to make > sure that the new boost works. If that turns out well, I'll do a > non-scratch build of boost-1.46.0-0.beta1 later today. > > PM > > References: > [1] http://fedoraproject.org/wiki/Features/F15Boost146 > [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=2760766 I believe my package schroot may have been hit by a 1.46 issue that is fixed in 1.47 Is there a plan to update to 1.47 or backport the fixes? >From the 1.47 changelog: Doc fixes: Update release history, add tables of macros and deprecated names. Bug fix: convenience.hpp didn't fully apply BOOST_FILESYSTEM_NO_DEPRECATED to name changes. Bug fix: Ticket #1972 'remove' fixes. Bug fix: Restore deprecated basic_directory_entry names inadvertently removed. Bug fix: Provide deprecated functions has_branch_path and has_leaf, inadvertently omitted from 1.36.0 Add workarounds for Codegear/Borland C++ Builder 2009. >From http://koji.fedoraproject.org/koji/getfile?taskID=2765676&name=build.log: sbuild-chroot-config.cc: In member function 'void sbuild::chroot_config::add_config_directory(const string&, const string&)': sbuild-chroot-config.cc:170:32: error: 'class boost::filesystem3::directory_entry' has no member named 'leaf' -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: [Bug 675265] preventryusn gets added to entries on a failed delete
https://bugzilla.redhat.com/show_bug.cgi?id=675265 https://bugzilla.redhat.com/attachment.cgi?id=477486&action=diff https://bugzilla.redhat.com/attachment.cgi?id=477486&action=edit Description: When an entry is deleted with Entry USN plugin enabled, an operational attribute preventryusn is added to handle indexes and entryusn tombstone. The attribute must have been added only when the delete was successful, but it was added regardless of the result from the operation. This patch checks the delete result in the newly added entryusn delete bepost plugin (usn_bepostop_delete). If it is not successful, the bepost plugin cleans up the attribute. -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (583652) Console caches magic numbers instead of DNA-generated values
https://bugzilla.redhat.com/show_bug.cgi?id=583652 https://bugzilla.redhat.com/attachment.cgi?id=477488&action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [rhythmbox] Don't forget the changelog
On Mon, 7 Feb 2011 19:27:12 + (UTC), Cosimo wrote: > %changelog > +* Mon Feb 7 2011 Cosimo Cecchi cosimoc redhat com - 2.91.0-1.git20110207 > +- Update to a 2.91.0 git snapshot > +- Disable DAAP sharing plugin, as it requires a newer libdmapsharing > +- Depend on gtk3 > + A newer libdmapsharing such as the following one? https://bugzilla.redhat.com/664624 If so, why not add a comment? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: changes to base-x comps group
Bill Nottingham (nott...@redhat.com) said: > (Attempting to CC relevant spins/groups maintainers) > > I'm looking to do some rework of the base-x comps group. Right now, its > main purpose in life is to provide the X server that is used by the > various desktops (and the window-managers group, I suppose). However, given > that, it has stuff in it that it really shouldn't - configuration tools, > applets, session services, and so on. > > Attached is a patch series that attempts to remove this cruft from the > base-x group, and place it, where relevant, in the appropriate desktop > groups. (At least, the cruft that was on by default - I haven't attempted > to weed out the optional packages yet.) Thanks for the comments... merged now. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[ACTION REQUIRED] orphaned packages in rawhide
Each release, we undergo the effort to track down owners for orphaned packages in the release, and block those orphaned packages where necessary. It's that time again for Fedora 15. The following packages are currently orphaned and exist in F-15. As you can see, there are a lot of dependencies on these packages. Please pick up these packages if you have a need for them. Orphan Io-language Orphan TeXmacs Orphan abcMIDI Orphan abcm2ps Orphan aduna-commons-concurrent Orphan aduna-commons-pom Orphan aduna-commons-text Orphan aduna-root-poms Orphan apache-resource-bundles Orphan atomix Orphan aumix Orphan beagle Orphan bigloo comaintained by: salimma Orphan cel Orphan compat-erlang Orphan cook Orphan crystalspace comaintained by: lkundrak Orphan curry Orphan dtdparser comaintained by: dbhole Orphan eclipse-demos comaintained by: jjohnstn Orphan eclipse-slice2java Orphan eina Orphan emacs-common-pmd Orphan fedora-devshell Orphan ffcall comaintained by: salimma Orphan fonttools Orphan g2ipmsg Orphan gauche-gl Orphan gauche-gtk Orphan gedit-vala comaintained by: salimma Orphan geglmm Orphan genesis Orphan geronimo-jms Orphan geronimo-jta Orphan geronimo-parent-poms Orphan gimmage Orphan gmixer comaintained by: tomspur Orphan gnome-gmail-notifier Orphan gnome-nettool Orphan gnome-vfsmm26 Orphan gpa Orphan gsh Orphan gsql Orphan gtkglarea2 comaintained by: rjones Orphan gtklp Orphan ice Orphan idw-gpl Orphan incollector Orphan janino Orphan jgoodies-forms Orphan jgoodies-looks Orphan jokosher Orphan k3b comaintained by: jreznik rdieter rnovacek Orphan kcm_touchpad Orphan ldapjdk Orphan libfakekey Orphan libflaim Orphan libgle Orphan libgnomecanvasmm26 Orphan libmatchbox comaintained by: cwickert Orphan libpanelappletmm Orphan libtlen Orphan log4net Orphan logback Orphan man-pages-uk Orphan marlin Orphan matchbox-keyboard Orphan matchbox-window-manager comaintained by: cwickert Orphan maven-doxia-tools Orphan maven-javadoc-plugin Orphan ncmpcpp Orphan ocaml-lablgl comaintained by: rjones Orphan odfpy comaintained by: pfrields Orphan openoffice.org-extendedPDF Orphan pdfbook Orphan plexus-cli Orphan plexus-registry comaintained by: akurtakov Orphan plt-scheme Orphan pmd Orphan pop-before-smtp Orphan pybackpack Orphan pyorbit Orphan pytc Orphan python-cly Orphan python-flickrapi Orphan python-hash_ring Orphan python-id3 Orphan python-line_profiler Orphan python-mwlib comaintained by: pfrields Orphan python-transitfeed Orphan pytyrant Orphan q Orphan qstat Orphan rsstool Orphan rubygem-ParseTree Orphan rubygem-RubyInline Orphan rubygem-ZenTest Orphan rubygem-abstract Orphan rubygem-amqp Orphan rubygem-archive-tar-minitar Orphan rubygem-bunny Orphan rubygem-extlib Orphan rubygem-fastthread comaintained by: kanarip Orphan rubygem-gem_plugin Orphan rubygem-merb-gen Orphan rubygem-merb-slices Orphan rubygem-mime-types Orphan rubygem-mixlib-authentication Orphan rubygem-mixlib-cli Orphan rubygem-mixlib-config Orphan rubygem-mixlib-log Orphan rubygem-moneta Orphan rubygem-mongrel comaintained by: kanarip Orphan rubygem-ohai Orphan rubygem-rcov Orphan rubygem-ruby2ruby Orphan rubygem-ruby_parser Orphan rubygem-sexp_processor Orphan rubygem-systemu Orphan rubygem-templater Orphan rubygem-uuidtools Orphan sil-doulos-fonts Orphan sil-gentium-fonts Orphan smolt Orphan sweep Orphan taglib comaintained by: rdieter Orphan tclabc Orphan tetex-tex4ht comaintained by: pertusus Orphan tigase-server Orphan tigase-utils Orphan tigase-xmltools Orphan tiger Orphan tla comaintained by: jzeleny Orphan trove4j Orphan twitter-glib Orphan update-ca-certificates Orphan valide Orphan wmctrl Orphan wordpress-plugin-add-to-any Orphan wordpress-plugin-add-to-any-subscribe Orphan xca Orphan zikula-module-feeds List of deps left behind by orphan removal: Orphan: Io-language TnL requires Io-language-devel = 20080330-3.fc15 TnL requires libiovmall.so.2 Orphan: abcm2ps tclabc requires abcm2ps = 5.9.21-1.fc15 Orphan: aduna-commons-pom aduna-commons-concurrent requires aduna-commons-pom = 16-1.fc13 aduna-commons-text requires aduna-commons-pom = 16-1.fc13 Orphan: aduna-root-poms aduna-commons-pom requires aduna-root-poms = 13-1.fc13 Orphan: apache-resource-bundles geronimo-parent-poms requires apache-resource-bundles = 2-5.fc15 maven2 requires apache-resource-bundles = 2-5.fc15 xmltool requires apache-resource-bundles = 2-5.fc15 Orphan: beagle kerry requires beagle = 0.3.9-19.fc14 Orphan: bigloo scheme2js requires bigloo = 3.4a-1.fc14 Orphan: crystalspace cel requires crystalspace-devel = 1.2.1-8.fc14 cel requires libcrystalspace-1.2.so cel requires libcrystalspace_python-1.2.so cel-demos requires libcrystalspace-1.2.so Orphan: ffcall clisp requires ffcall = 1.10-4.20080704cvs.fc12.1 Orphan: fonttools python-compositor r
Re: [ACTION REQUIRED] orphaned packages in rawhide
Le lundi 07 février 2011 à 15:59 -0500, Bill Nottingham a écrit : > Each release, we undergo the effort to track down owners for orphaned > packages in the release, and block those orphaned packages where > necessary. It's that time again for Fedora 15. > > The following packages are currently orphaned and exist in F-15. As > you can see, there are a lot of dependencies on these packages. Please > pick up these packages if you have a need for them. > Orphan jgoodies-forms > Orphan jgoodies-looks I take these packages, required by antlrworks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in rawhide
Bill Nottingham wrote: > Each release, we undergo the effort to track down owners for orphaned > packages in the release, and block those orphaned packages where > necessary. It's that time again for Fedora 15. > > The following packages are currently orphaned and exist in F-15. As > you can see, there are a lot of dependencies on these packages. Please > pick up these packages if you have a need for them. > > > Orphan Io-language > Orphan TeXmacs > Orphan abcMIDI > Orphan abcm2ps > Orphan aduna-commons-concurrent > Orphan aduna-commons-pom > Orphan aduna-commons-text > Orphan aduna-root-poms > Orphan apache-resource-bundles > Orphan atomix > Orphan aumix > Orphan beagle > Orphan bigloo > comaintained by: salimma > Orphan cel > Orphan compat-erlang > Orphan cook > Orphan crystalspace > comaintained by: lkundrak > Orphan curry > Orphan dtdparser > comaintained by: dbhole > Orphan eclipse-demos > comaintained by: jjohnstn > Orphan eclipse-slice2java > Orphan eina > Orphan emacs-common-pmd > Orphan fedora-devshell > Orphan ffcall > comaintained by: salimma > Orphan fonttools > Orphan g2ipmsg > Orphan gauche-gl > Orphan gauche-gtk > Orphan gedit-vala > comaintained by: salimma > Orphan geglmm > Orphan genesis > Orphan geronimo-jms > Orphan geronimo-jta > Orphan geronimo-parent-poms > Orphan gimmage > Orphan gmixer > comaintained by: tomspur > Orphan gnome-gmail-notifier > Orphan gnome-nettool > Orphan gnome-vfsmm26 > Orphan gpa > Orphan gsh > Orphan gsql > Orphan gtkglarea2 > comaintained by: rjones > Orphan gtklp > Orphan ice > Orphan idw-gpl > Orphan incollector > Orphan janino > Orphan jgoodies-forms > Orphan jgoodies-looks > Orphan jokosher > Orphan k3b > comaintained by: jreznik rdieter rnovacek > Orphan kcm_touchpad > Orphan ldapjdk > Orphan libfakekey > Orphan libflaim > Orphan libgle > Orphan libgnomecanvasmm26 > Orphan libmatchbox > comaintained by: cwickert > Orphan libpanelappletmm > Orphan libtlen > Orphan log4net > Orphan logback > Orphan man-pages-uk > Orphan marlin > Orphan matchbox-keyboard > Orphan matchbox-window-manager > comaintained by: cwickert > Orphan maven-doxia-tools > Orphan maven-javadoc-plugin > Orphan ncmpcpp > Orphan ocaml-lablgl > comaintained by: rjones > Orphan odfpy > comaintained by: pfrields > Orphan openoffice.org-extendedPDF > Orphan pdfbook > Orphan plexus-cli > Orphan plexus-registry > comaintained by: akurtakov > Orphan plt-scheme > Orphan pmd > Orphan pop-before-smtp > Orphan pybackpack > Orphan pyorbit > Orphan pytc > Orphan python-cly > Orphan python-flickrapi > Orphan python-hash_ring > Orphan python-id3 > Orphan python-line_profiler > Orphan python-mwlib > comaintained by: pfrields > Orphan python-transitfeed > Orphan pytyrant > Orphan q > Orphan qstat > Orphan rsstool > Orphan rubygem-ParseTree > Orphan rubygem-RubyInline > Orphan rubygem-ZenTest > Orphan rubygem-abstract > Orphan rubygem-amqp > Orphan rubygem-archive-tar-minitar > Orphan rubygem-bunny > Orphan rubygem-extlib > Orphan rubygem-fastthread > comaintained by: kanarip > Orphan rubygem-gem_plugin > Orphan rubygem-merb-gen > Orphan rubygem-merb-slices > Orphan rubygem-mime-types > Orphan rubygem-mixlib-authentication > Orphan rubygem-mixlib-cli > Orphan rubygem-mixlib-config > Orphan rubygem-mixlib-log > Orphan rubygem-moneta > Orphan rubygem-mongrel > comaintained by: kanarip > Orphan rubygem-ohai > Orphan rubygem-rcov > Orphan rubygem-ruby2ruby > Orphan rubygem-ruby_parser > Orphan rubygem-sexp_processor > Orphan rubygem-systemu > Orphan rubygem-templater > Orphan rubygem-uuidtools > Orphan sil-doulos-fonts > Orphan sil-gentium-fonts > Orphan smolt > Orphan sweep > Orphan taglib > comaintained by: rdieter > Orphan tclabc > Orphan tetex-tex4ht > comaintained by: pertusus > Orphan tigase-server > Orphan tigase-utils > Orphan tigase-xmltools > Orphan tiger > Orphan tla > comaintained by: jzeleny > Orphan trove4j > Orphan twitter-glib > Orphan update-ca-certificates > Orphan valide > Orphan wmctrl > Orphan wordpress-plugin-add-to-any > Orphan wordpress-plugin-add-to-any-subscribe > Orphan xca > Orphan zikula-module-feeds > > List of deps left behind by orphan removal: > > Orphan: Io-language > TnL requires Io-language-devel = 20080330-3.fc15 > TnL requires libiovmall.so.2 > > Orphan: abcm2ps > tclabc requires abcm2ps = 5.9.21-1.fc15 > > Orphan: aduna-commons-pom > aduna-commons-concurrent requires aduna-commons-pom = 16-1.fc13 > aduna-commons-text requires aduna-commons-pom = 16-1.fc13 > > Orphan: aduna-root-poms > aduna-commons-pom requires aduna-root-poms = 13-1.fc13 > > Orphan: apache-resource-bundles > geronimo-parent-poms requires apache-resource-bundles = 2-5.fc15 > maven2 requires apache-resource-bundles = 2-5.fc15 > xmltool requires apache-resource-bundles = 2-5.fc15 > > Orphan: beagle > kerry requires beagle = 0.3.9-19.fc14 > > Orphan: big
Re: [ACTION REQUIRED] orphaned packages in rawhide
Am Montag, den 07.02.2011, 15:59 -0500 schrieb Bill Nottingham: > Each release, we undergo the effort to track down owners for orphaned > packages in the release, and block those orphaned packages where > necessary. It's that time again for Fedora 15. > > The following packages are currently orphaned and exist in F-15. As > you can see, there are a lot of dependencies on these packages. Please > pick up these packages if you have a need for them. > > > Orphan Io-language > Orphan TeXmacs > Orphan abcMIDI > Orphan abcm2ps > Orphan aduna-commons-concurrent > Orphan aduna-commons-pom > Orphan aduna-commons-text > Orphan aduna-root-poms > Orphan apache-resource-bundles > Orphan atomix > Orphan aumix > Orphan beagle > Orphan bigloo > comaintained by: salimma > Orphan cel > Orphan compat-erlang > Orphan cook > Orphan crystalspace > comaintained by: lkundrak > Orphan curry > Orphan dtdparser > comaintained by: dbhole > Orphan eclipse-demos > comaintained by: jjohnstn > Orphan eclipse-slice2java > Orphan eina > Orphan emacs-common-pmd > Orphan fedora-devshell > Orphan ffcall > comaintained by: salimma > Orphan fonttools > Orphan g2ipmsg > Orphan gauche-gl > Orphan gauche-gtk > Orphan gedit-vala > comaintained by: salimma > Orphan geglmm > Orphan genesis > Orphan geronimo-jms > Orphan geronimo-jta > Orphan geronimo-parent-poms > Orphan gimmage > Orphan gmixer > comaintained by: tomspur > Orphan gnome-gmail-notifier > Orphan gnome-nettool > Orphan gnome-vfsmm26 > Orphan gpa > Orphan gsh > Orphan gsql > Orphan gtkglarea2 > comaintained by: rjones > Orphan gtklp > Orphan ice > Orphan idw-gpl > Orphan incollector > Orphan janino > Orphan jgoodies-forms > Orphan jgoodies-looks > Orphan jokosher > Orphan k3b > comaintained by: jreznik rdieter rnovacek > Orphan kcm_touchpad > Orphan ldapjdk > Orphan libfakekey > Orphan libflaim > Orphan libgle > Orphan libgnomecanvasmm26 > Orphan libmatchbox > comaintained by: cwickert > Orphan libpanelappletmm > Orphan libtlen > Orphan log4net > Orphan logback > Orphan man-pages-uk > Orphan marlin > Orphan matchbox-keyboard > Orphan matchbox-window-manager > comaintained by: cwickert > Orphan maven-doxia-tools > Orphan maven-javadoc-plugin > Orphan ncmpcpp > Orphan ocaml-lablgl > comaintained by: rjones > Orphan odfpy > comaintained by: pfrields > Orphan openoffice.org-extendedPDF > Orphan pdfbook > Orphan plexus-cli > Orphan plexus-registry > comaintained by: akurtakov > Orphan plt-scheme > Orphan pmd > Orphan pop-before-smtp > Orphan pybackpack > Orphan pyorbit > Orphan pytc > Orphan python-cly > Orphan python-flickrapi > Orphan python-hash_ring > Orphan python-id3 > Orphan python-line_profiler > Orphan python-mwlib > comaintained by: pfrields > Orphan python-transitfeed > Orphan pytyrant > Orphan q > Orphan qstat > Orphan rsstool > Orphan rubygem-ParseTree > Orphan rubygem-RubyInline > Orphan rubygem-ZenTest > Orphan rubygem-abstract > Orphan rubygem-amqp > Orphan rubygem-archive-tar-minitar > Orphan rubygem-bunny > Orphan rubygem-extlib > Orphan rubygem-fastthread > comaintained by: kanarip > Orphan rubygem-gem_plugin > Orphan rubygem-merb-gen > Orphan rubygem-merb-slices > Orphan rubygem-mime-types > Orphan rubygem-mixlib-authentication > Orphan rubygem-mixlib-cli > Orphan rubygem-mixlib-config > Orphan rubygem-mixlib-log > Orphan rubygem-moneta > Orphan rubygem-mongrel > comaintained by: kanarip > Orphan rubygem-ohai > Orphan rubygem-rcov > Orphan rubygem-ruby2ruby > Orphan rubygem-ruby_parser > Orphan rubygem-sexp_processor > Orphan rubygem-systemu > Orphan rubygem-templater > Orphan rubygem-uuidtools > Orphan sil-doulos-fonts > Orphan sil-gentium-fonts > Orphan smolt > Orphan sweep > Orphan taglib > comaintained by: rdieter > Orphan tclabc > Orphan tetex-tex4ht > comaintained by: pertusus > Orphan tigase-server > Orphan tigase-utils > Orphan tigase-xmltools > Orphan tiger > Orphan tla > comaintained by: jzeleny > Orphan trove4j > Orphan twitter-glib > Orphan update-ca-certificates > Orphan valide > Orphan wmctrl > Orphan wordpress-plugin-add-to-any > Orphan wordpress-plugin-add-to-any-subscribe > Orphan xca > Orphan zikula-module-feeds > > List of deps left behind by orphan removal: > > Orphan: Io-language > TnL requires Io-language-devel = 20080330-3.fc15 > TnL requires libiovmall.so.2 > > Orphan: abcm2ps > tclabc requires abcm2ps = 5.9.21-1.fc15 > > Orphan: aduna-commons-pom > aduna-commons-concurrent requires aduna-commons-pom = 16-1.fc13 > aduna-commons-text requires aduna-commons-pom = 16-1.fc13 > > Orphan: aduna-root-poms > aduna-commons-pom requires aduna-root-poms = 13-1.fc13 > > Orphan: apache-resource-bundles > geronimo-parent-poms requires apache-resource-bundles = 2-5.fc15 > maven2 requires apache-resource-bundles = 2-5.fc15 > xmltool requires apache-resource-bundles = 2-5.fc15 > > Orphan: beagle > ke
Could not find debuginfo pkg for dependency package. . .
I've been experiencing some mutter crashes when trying to report it via abrt, abrt informed me that reporting was disabled because the backtrace is unusable and suggested I installed debuginfo-install mutter then refresh and try again which revealed. .. Could not find debuginfo pkg for dependency package glibc-2.13.90-2.x86_64 Could not find debuginfo pkg for dependency package clutter-1.6.2-1.fc15.x86_64 I'm a bit curious if we cant automatically check for missing debuginfo pacakges for relevant component(s) and inform the packager/maintainer encase they dont exist to prevent encounters like this? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[pkgdb] ocaml-lablgl ownership changed
Package ocaml-lablgl in Fedora devel is now owned by rjones To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/ocaml-lablgl ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
[pkgdb] ocaml-lablgl ownership changed
Package ocaml-lablgl in Fedora 14 is now owned by rjones To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/ocaml-lablgl ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: [ACTION REQUIRED] orphaned packages in rawhide
On Mon, Feb 07, 2011 at 03:59:42PM -0500, Bill Nottingham wrote: > Orphan ocaml-lablgl > comaintained by: rjones > Orphan: gtkglarea2 I took these two. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: perl @INC (paths) again
* Iain Arnell [03/02/2011 09:31] : > > I agree. Marcela's proposal is fine in principle, but unlikely to > achieve much in practice. I have to admit this is my conclusion as well. > On Wed, Feb 2, 2011 at 11:43 AM, Paul Howarth wrote: > > > So overall I'm in favour of using the F-15 set of paths (assuming the > > typos are fixed) but sticking with the vendor directories for everything > > apart from the perl core. > > +1 to that. Add my +1 to the list. Emmanuel -- 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: Could not find debuginfo pkg for dependency package. . .
On Mon, 07 Feb 2011 22:23:11 + Jóhann "B." Guðmundsson wrote: > I've been experiencing some mutter crashes when trying to report it > via abrt, abrt informed me that reporting was disabled because the > backtrace is unusable and suggested I installed debuginfo-install > mutter then refresh and try again which revealed. .. > > Could not find debuginfo pkg for dependency package > glibc-2.13.90-2.x86_64 > Could not find debuginfo pkg for dependency package > clutter-1.6.2-1.fc15.x86_64 Where did you install glibc from ? Koji? > I'm a bit curious if we cant automatically check for missing debuginfo > pacakges for relevant component(s) and inform the packager/maintainer > encase they dont exist to prevent encounters like this? The problem is that that version of glibc was built today, so it's not in repos and thus it's debuginfo isn't in repos either. I don't think the koji static repos include debuginfo, so if you are installing from there you will need to download and install the debuginfo manually. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Could not find debuginfo pkg for dependency package. . .
On Mon, 2011-02-07 at 16:01 -0700, Kevin Fenzi wrote: > On Mon, 07 Feb 2011 22:23:11 + > Jóhann "B." Guðmundsson wrote: > > > I've been experiencing some mutter crashes when trying to report it > > via abrt, abrt informed me that reporting was disabled because the > > backtrace is unusable and suggested I installed debuginfo-install > > mutter then refresh and try again which revealed. .. > > > > Could not find debuginfo pkg for dependency package > > glibc-2.13.90-2.x86_64 > > Could not find debuginfo pkg for dependency package > > clutter-1.6.2-1.fc15.x86_64 > > Where did you install glibc from ? Koji? > > > I'm a bit curious if we cant automatically check for missing debuginfo > > pacakges for relevant component(s) and inform the packager/maintainer > > encase they dont exist to prevent encounters like this? > > The problem is that that version of glibc was built today, so it's not > in repos and thus it's debuginfo isn't in repos either. > > I don't think the koji static repos include debuginfo, so if you are > installing from there you will need to download and install the > debuginfo manually. Yup using static repo from koji Thanks for the heads up will add those packages manually JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: perl @INC (paths) again
On 02/07/2011 11:43 PM, Emmanuel Seyman wrote: > * Iain Arnell [03/02/2011 09:31] : >> >> I agree. Marcela's proposal is fine in principle, but unlikely to >> achieve much in practice. > > I have to admit this is my conclusion as well. > >> On Wed, Feb 2, 2011 at 11:43 AM, Paul Howarth wrote: >> >>> So overall I'm in favour of using the F-15 set of paths (assuming the >>> typos are fixed) but sticking with the vendor directories for everything >>> apart from the perl core. >> >> +1 to that. > > Add my +1 to the list. Then you are likely able to explain why you want to see this implemented? I fail to see _any_ advantage this approach provides, but consider it to provide only regressons what Fedora 14 had. Ralf -- 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
Check your KDE application's license
Hi everybody, if you're maintaining a KDE application in Fedora, there might be a chance that it is using a modified GPL license header (see this thread on the legal list http://lists.fedoraproject.org/pipermail/legal/2011-February/001537.html ). I only know of this being the case with Yakuake and amaroK (see src/widgets/FlowLayout.cpp), but possibly other applications are affected as well. If you find this or a similar header in one of your packages, please change your License tag to the one pointed out on the legal list here: http://lists.fedoraproject.org/pipermail/legal/2011-February/001541.html Happy grepping, Julian signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please Review: (668950) Add posixGroup support to Console
https://bugzilla.redhat.com/show_bug.cgi?id=668950 https://bugzilla.redhat.com/attachment.cgi?id=477527&action=edit https://bugzilla.redhat.com/attachment.cgi?id=477528&action=edit https://bugzilla.redhat.com/attachment.cgi?id=477529&action=edit https://bugzilla.redhat.com/attachment.cgi?id=477530&action=edit https://bugzilla.redhat.com/attachment.cgi?id=477531&action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
new raid1 read balance working, please test it! kernel 2.6.37 based
hi guys, i made some changes to md raid1 software, could fedora test it? for me it work very nice =) the raid1 new code is based in kernel 2.6.37 here is the new and old code: www.spadim.com.br/raid1 just read_balance changed (4 modes: near_head(today) round_robin(counter per mirror) stripe (like raid0, with shift for make stripe less or more intensive), time based (depending on head positioning time and read size it calculate the fasted mirror, some new improvement must be done but it works, improvements= get io queue of each mirror and many a time estimation of queue time, with it get more close best disk) it´s open source please help me testing it, neil at raid kernel must some benchmarks to put it inside kernel source for mixed speed mirrors time based is good, for ssd only round_Robin is good (per mirror count, put 230 for 230mb/s, 150 for mb/s or multiples to make a good round robin) for disks and/or ssd mixed or not, stripe is good for disks only near head is good -- Roberto Spadim Spadim Technology / SPAEmpresarial -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in rawhide
On Mon, Feb 7, 2011 at 1:59 PM, Bill Nottingham wrote: > Orphan bigloo >comaintained by: salimma > > Orphan ffcall >comaintained by: salimma > I need these two to work, so I can either maintain or comaintain if the existing comaintainer would like me to. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
libedit update
I need a libedit update to attempt to resolve bug #511303. In particular, the latest version includes wide character (Unicode) support. I've just done the rebuild. This should not effect other programs that use libedit, but just in case, check your programs for any weirdness. If I've broken something for you, let me know, and I'll try to fix it. Repoquery tells me that the following may be affected: Io-language asterisk ceph chrony ghc-editline kaya libreadline-java link-grammar ntp openssh-clients php-cli php-pecl-xdebug pure uim Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: incompatible screen update
On Fri, 04.02.11 16:30, Miroslav Lichvar (mlich...@redhat.com) wrote: > Hi, > > just a heads up, the screen package in rawhide was updated to a pre > 4.1.0 git snapshot and after the update you won't be able to reattach > to your old screen session. > > There are actually three incompatible changes: > - the change in screen protocol > - $HOME/.screen is used as socket directory instead of > /var/run/screen > - unix sockets are used instead of named pipes > > The socket directory switch means that it's now not possibly to enable > the multiuser feature just by adding suid root to the screen binary > and chmoding the directory. To enable the feature, the package has to > be recompiled with --with multiuser, it will switch the directory > back, add suid bit and include tmpfs so systemd creates the directory > on start. $HOME is no place to place unix sockets. Unfortunately $HOME might be one weirdo file systems which do not support that. Expect bug reports about this soon. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
