|
|
| (83 intermediate revisions by the same user not shown) |
| Line 5: |
Line 5: |
| mailing list are summarized. | | mailing list are summarized. |
|
| |
|
| Contributing Writer: [[OisinFeeley|Oisin Feeley]] | | Contributing Writer: [[User:Ush|Oisin Feeley]] |
|
| |
|
| === Resume from Suspend Problems with Intel i945 === | | === Would You Like to Write This Beat ? === |
|
| |
|
| [[PeterRobinson|Peter Robinson]] solicited[1] experiences with problems on netbooks in resuming from suspend from those using the latest <code>Intel-2.5.0</code>drivers. His problem suddenly manifested itself on a previously working <code>EeePC</code> 901: "It had worked previously and resumes OK but I get a black screen with a cursor and around that a square of garbled bits." Peter wondered what had changed recently in order to make suspend-resume stop working. | | Following this issue (FWN#178) I will, with regret, no longer be covering the @fedora-devel list. If you are interested in writing this weekly summary of the deeds and doings on the list then please contact fedora-news-list@redhat.com or [[User:Pcalarco|Pascal Calarco]]. A short overview of what you may need to do can be obtained by reading the workflow<ref>http://fedoraproject.org/wiki/FWN/WorkFlow</ref> section of the wiki. The @fedora-news list is also extremely open and helpful. Joining<ref>http://fedoraproject.org/wiki/FWN/NewsProject/Join</ref> the News Project is quite straightforward. |
|
| |
|
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02975.html
| | <references/> |
|
| |
|
| Apparently similar failures were reported[2] by [[JonathonRoberts|Jonathon Roberts]] for a Dell Mini[3] ,[[TimLauridsen|Tim Lauridsen]] on a ThinkPad T60[4] and [[ChristophHoger|Christoph Hoger]][5] on a ThinkPad R61. Tim's problem seemed to be related to <code>compiz</code>.
| | === Is gNaughty a Hot Babe ? === |
|
| |
|
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02977.html | | [[User:Sundaram|Rahul Sundaram]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02071.html</ref> the results of a survey conducted, primarily on @fedora-list and on the forums, to discover which non-repository-packaged software Fedora consumers were using. |
|
| |
|
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02977.html
| | One interesting point is that CMUCL<ref>One of the Common Lisp implementations: http://www.cons.org/cmucl/</ref> was revealed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02088.html</ref> to be only available for 32-bit systems. However what got people really excited was<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02136.html</ref> Rahul's question about what to do concerning the <code>gNaughty</code> package. Its sole purpose seemed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02203.html</ref> to be downloading pornography. Rahul referenced the <code>hot-babe</code> CPU monitor which enjoyed controversy in Debian packaging circles due to its use of female nudity. Rahul wanted to find out "[...] is this allowed in Fedora?" |
|
| |
|
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg03005.html | | Amusingly a good deal of the controversy focused on whether the content was freely redistributable, but a predictable moral angle was raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02242.html</ref> by [[User:Alsadi|Muayyad AlSadi]] who asked for help in producing a spin which removed content deemed objectionable. Muayyad is a Jordanian developer who has been producing an Arabic-localized Fedora spin named "Ojuba" for some time. Muayyad sought a way to make identifying and tagging packages easier to facilitate this spin. [[User:Notting|Bill Nottingham]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02312.html</ref> skeptical about the chances of tags keeping meaning unless there was some sort of review board. Equally predictable was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02295.html</ref> the reaction typified by [[User:Skvidal|Seth Vidal]] which resisted any attempt to restrict packages according to standards which had nothing to do with licensing or patent issues. [[User:bochcecha|Mathieu Bridon]] thought<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02355.html</ref> that the creation of a wiki-page by Muayyad would allow anyone interested in co-ordinating work on "Inappropriate Content" to just go ahead and do it without dragging in bureaucracy. |
|
| |
|
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg03033.html
| | <references/> |
|
| |
|
| [[JeremyKatz|Jeremy Katz]] suggested[6] using the suspend quirks[7] , especially <code>vbepost</code>. [[MatthewGarret|Matthew Garret]] believed[8] this to be unnecessary as "i945 is perfectly capable of handling resume on its own in-kernel. The problem is more likely to be an excess of quirks interfering with that (or, alternatively, someone's broken the kernel)."
| | === Chrome9 Vx800 Graphics Support on LiveUSB === |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02981.html | | [[KristapsViesalgs|Kristaps Viesalgs]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02146.html</ref> for help in getting the Fedora Live USB to boot correctly on a machine using a Via Vx800 "Chrome9" GPU. Kristaps had some success with the latest upstream version (from their subversion repository) and asked: "Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? Is Fedora planning to make for VIA graphic chipset autoconfiguration utility?" |
|
| |
| [7] http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-index.html
| |
|
| |
|
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02992.html | | [[User:Ajax|Adam Jackson]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02154.html</ref> for a more specific bug report because the chip should be supported. He preferred not to ship an autoconfiguration utility instead of just getting the driver correct. Similar points were made by [[User:Adamwill|Adam Williamson]] and [[User:|Xavier Bachelot]]. The latter asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02163.html</ref> any interested developers to help out the openchrome project in both the 2D and 3D(Gallium) sides. |
|
| |
|
| [[JesseBarnes|Jesse Barnes]] (of the Intel Open Source Technology Center[9]) asked whether suspend worked from the console using:
| | <references/> |
|
| |
| <code>echo mem > /sys/power/state</code> | |
|
| |
|
| as this would indicate that there had been a regression in 2.5.0 as opposed to a kernel bug. [[MatthewGarrett|Matthew Garrett]] thought that Jesse's suggestion would not test the same suspend pathway and that it would be better to do a:
| | === Who Wants a Pony? === |
|
| |
| <pre>dbus-send --system --print-reply --dest=org.freedesktop.Hal \
| |
| /org/freedesktop/Hal/devices/computer \
| |
| org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0
| |
| </pre>
| |
|
| |
|
| Matthew begged[10] "Please (please, please) don't attempt to add resume quirks for anything with Intel video hardware now. It's only hiding kernel bugs."
| | [[User:Kushal|Kushal Das]] promised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02139.html</ref> a pony to anyone that would take the trouble to review<ref>http://bugzilla.redhat.com/show_bug.cgi?id=503021</ref> one of his packages. |
|
| |
|
| | <references/> |
|
| |
|
| [9] http://software.intel.com/sites/oss/
| | === Firestarter Retired as Unportable to PolicyKit === |
|
| |
|
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00082.html | | [[User:Maxamillion|Adam Miller]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02089.html</ref> whether he should just retire the <code>Firestarter</code><ref>Firestarter is a firewall configuration GUI</ref> package for which he had recently become the maintainer. His query was based on the recent filing of RFEs to integrate <code>Firestarter</code> with <code>PolicyKit</code>. These suggested to Adam that a large amount of work would be needed due to the lack of any upstream activity for four years and the need to grok <code>PolicyKit</code>. |
|
| |
|
| === Moving X from VT7 to VT1 ===
| | Following confirmation from [[User:Sundaram|Rahul Sundaram]] and [[User:Skvidal|Seth Vidal]] a decision was made<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02094.html</ref> by Adam: "I would honestly rather retire the package than do a WONTFIX, if the project as a whole is going the direction of PolicyKit and upstream is dead then I don't want to keep old and busted cruft around the repositories as Fedora continues to look towards the future." |
| | | |
| A gigantic multi-thread flamewar consumed many list participants after [[WillWoods|Will Woods]] made sure[1] that everyone knew that in Rawhide "X HAS MOVED FROM VT7 TO VT1. GDM specifically starts X on tty1, and upstart does not start a getty on tty1 in runlevel 5." The reason behind this change was that the boot process no longer uses the old <code>RHGB</code> but instead a flicker-free and faster replacement named <code>Plymouth</code> (see Fedora Magazine[2] for a full explanation).
| | A further suggestion from "Cry" prompted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02122.html</ref> Adam to start filing RFEs against <code>system-config-firewall</code> for any features present in <code>Firestarter</code> but missing in <code>system-config-firewall</code>. |
| | | <references/> |
| Fuel for the fire was provided by the surprise experienced by many posters who solely followed @fedora-devel for their information. A perception that changes made for the purposes of improving the desktop experience were occurring at the expense of the traditional server experience also seemed to irritate many. This was despite the fact that, as [[DanNicholson|Dan Nicholson]] explained[3]: "Users who do not want a graphical boot set rc 3 as their default runlevel, and everything is the same as it always was with getty on tty1-6. If you then run startx, it will start on tty7. In rc 5, X is started on tty1 and getty is not. That's all there is to it."
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02422.html
| |
| | |
| [2] http://fedoramagazine.wordpress.com/2008/10/21/interview-fedora-10s-better-startup/
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02469.html
| |
| | |
| In answer to a question from [[TillMaas|Till Maas]] it was confirmed[4] by [[FelixMiata|Felix Miata]] that if one "[...] rebooted into runlevel 3, logged in on tty1, did telinit 5, got kdm on vt7, switched to tty1, [then there was] a normal shell prompt following typical X startup messages, and kdm still on vt7 [.]"
| |
| | |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02478.html
| |
| | |
| [[DanNicholson|Dan Nicholson]] also corrected[5] assumptions that the changes were made to improve boot speed with the information that it was to prevent the ugly flicker of VT switching during boot and asked "Why is it significant what tty any program runs on? Isn't the assumption that getty will be on tty1 just as faulty as the assumption X will be on tty7?" [[ShmuelSiegel|Shmuel Siegel]] gave[6] an answer which was repeated many times in the threads: "Because you are changing a user interface. What is going to happen when the user switches to tty1 and nothing happens? The basic logic of putting X on tty7 is to get it out of the way. Humans will use the lowest numbered ttys first. Besides breaking existing documentation, including advice on various forums, is not a good idea." [[BillNottingham|Bill Nottingham]] added[7] to Dan's rationale: "1) Reducing the amount of flicker and useless mode switching on startup is definitely a good thing 2) From a logical standpoint, the first tty should be for the most important user interaction. If you're booting in text mode, that's a getty. If you're booting with a GUI login... that's the GUI." [[CallumLerwick|Callum Lerwick]] and [[BrianWheeler|Brian Wheeler]] exchanged[8] details of the "vast improvement[s]" including removal of up to twelve seconds which resulted from the lack of monitor resync delays.
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02458.html
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02464.html
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02543.html
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02518.html
| |
| | |
| [[GerdHoffman|Gerd Hoffman]] made[9] an interesting suggestion about how <code>Plymouth</code> could do a VT switch immediately after <code>KMS</code>[10] had entered graphics mode but before printing anything to screen. In the course of this he clarified that "The flicker / resync delay comes from the *mode switch*, not the *vt switch*. And, no, a vt switch does *not* imply a mode switch. The reason you'll have flicker today when switching from/to X11 is that X11 does a mode switch when you switch from/to the terminal X11 is running on." BillNottingham was skeptical but Gerd insisted [11] that his approach would work.
| |
| | |
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02623.html
| |
| | |
| [10] Kernel Mode Setting: http://kerneltrap.org/node/8242
| |
| | |
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02820.html
| |
| | |
| After [[TillMaas|Till Maas]] suggested "[...] the kernel should be patched to start booting graphically using tty7 and not tty1." [[BillNottingham|Bill Nottingham]] passed[12] on the idea as it would involve: "Having the kernel parse its own commandline for a runlevel (a concept that has nothing to do with the kernel, and doesn't even exist under some init systems) and then choosing to rearrange the tty init sequence based on that?" and in further discussion with [[MatthewWoehlke|Matthew Woehlke]] reiterated[13] "You're having the kernel operate on Fedora specific commandline options to start on a completely different tty, one that could be configured by anyone locally to do something else entirely. (Unless you do it in userspace, which means you jump away and then jump back for text mode, which...)" [[CaseyDahlin|Casey Dahlin]] modified[14] the idea to "[...] either offer a getty on tty7 (not too hard) or we could instead add a small API to the kernel that would allow remapping which F key went to which tty, so you could have ctrl+alt+f1 bring up tty7. That way we could remap things so the user got the correct behavior. We wouldn't have to actually /do/ this, but if the API were there, we can tell the people who care to go figure it out."
| |
| | |
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02544.html
| |
| | |
| [13] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02594.html
| |
| | |
| [14] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02553.html
| |
| | |
| [[WillWoods|Will Woods]] explained[15] how to revert the change, but this was contested[16] by [[DanNicholson|Dan Nicholson]] on the basis that the latest <code>gdm</code> does not support <code>FirstVT.</code> Dan provided an untested patch and explained that "[s]ince plymouth writes the /var/spool/gdm file on boot and then gdm removes it, any subsequent starts will put X on the first available VT, which is tty7 in the common configuration. With my patch, prefdm writes the file every time it's executed. I don't know if that's the correct behavior for all cases where prefdm would be run. I'm looking at upstream gdm right now, and FirstVT isn't respected. Looking at the rawhide patches, I don't see anything that would enable that functionality again."
| |
| | |
| [15] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02506.html
| |
| | |
| [16] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02516.html
| |
| | |
| Later [[DaxKelson|Dax Kelson]] reopened[17] the thread with a list of objections which pointed out the negative impact upon documentation and user habit of the change. He garnered a good deal of support from many other respected contributors.
| |
| | |
| [17] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02601.html
| |
| | |
| At the end of the thread [[BillNottingham|Bill Nottingham]] asked[18] the interesting question of why the change appeared to come as such a surprise given that it had been telegraphed in advance by a formal feature proposal[19] and had been implemented in rawhide: "Are people not running rawhide and the test releases? Are they not looking at features as they are proposed and being involved in the process? Are they just sitting around waiting to be outraged?" Dax rejoined[20] that it was not obvious from the documentation that there would be a side-effect which disturbed an expected convention.
| |
| | |
| [18] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02830.html
| |
| | |
| [19] http://fedoraproject.org/wiki/Features/BetterStartup
| |
| | |
| [20] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02853.html
| |
| | |
| === Fedora 11: POSIX File Capabilities ===
| |
| | |
| [[PanuMatilainen|Panu Matilainen]] announced[1] that he had added file capability support to <code>rpm</code>. With kernel support for storing capabilities on filesystem since 2.6.24 and the most recent <code>libcap</code> he asked if now was the time to "[...] start considering moving away from SUID bits to capabilities, in Fedora 11 maybe?"
| |
| | |
| SethVidal wondered how this would affect networked file systems and [[DavidQuigley|David Quigley]] answered[2] that "[...] capabilities are stored in xattrs they will run into the same problems that SELinux does. Labeled NFS is working to address this by providing a per file attribute through NFSv4 for extra security information."
| |
| | |
| Another show-stopper was the erasure of file-based capabilities by <code>prelink</code>. It appeared[3] that there was a certain amount of desire to examine whether <code>prelink</code> might cause more trouble than it was worth on faster hardware. Prelink's problems also included incorrectly stripping <code>OCaml</code> binaries and preventing <code>rpm -V</code> from working correctly.
| |
| | |
| [[ColinWalters|Colin Walters]] noted[4] that the desktop team had "been moving the OS away from exec-based domain transitions to message passing (e.g. PolicyKit) for a variety of reasons. I think it might be worth considering introducing a rule actually in Fedora for "no new SUID/fcap binaries"[.]" [[SteveGrubb|Steve Grubb]] was worried[5] that this direction resulted in the introduction of another MAC system and that auditing from userspace was untrustworthy. Concern was also raised[6] by [[MichaelStone|Michael Stone]] on the affects on solid-state memory consumption.
| |
|
| |
| [[SteveGrubb|Steve Grubb]] sought details on how rpm would work with kernels lacking file capabilities and wanted[7] to "start removing some of the setuid bits." He suggested[8] to [[ChrisAdams|Chris Adams]] that <code>tar</code> and <code>star</code> should be capable of storing these new extended attributes and that <code>aide</code> would be useful in tracking changes to them.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02637.html
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02849.html
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02923.html
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02729.html
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02809.html
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02818.html
| |
| | |
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02777.html
| |
| | |
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02823.html
| |
| | |
| === Purging Unnecessary .la Files ===
| |
| | |
| An apparent contravention of the packaging guidelines was noticed[1] by [[DebarshiRay|Debarshi Ray]] in the <code>dia</code> package. It contained <code>%{_libdir}/%{name}/*.la</code> files[2]. [[ColinWalters|Colin Walters]] was[3][4] enthusiastic about the idea of "not encourag[ing] the libtool agenda to redefine how shared libraries work on our platform." [[JerryJames|Jerry James]] found[5] that he had quite a number of them on his x86_64 machine.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg03031.html
| |
| | |
| [2] .la are libtool archive files: http://www.gnu.org/software/libtool/manual/html.node/index.html#Top
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg03032.html
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg03039.html
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg03038.html
| |
|
| |
|
| [[DanNicholson|Dan Nicholson]] argued[6] that it would be best to convince libtool upstream to support some way to choose whether or not the library archives were installed at build time, but Colin was unrelenting and argued[7]: "Or alternatively convince the automake people that it shouldn't be in the business of software lifecycle management (make uninstall) any more than people should be coding/overriding build systems (make;make install) inside RPM spec files. This seems possible; probably worth trying to at least have an environment variable AUTOMAKE.OPTIONS = i-dont-need-uninstall."
| | === Russian Fedora ? === |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg03048.html | | When [[User:Peter|Peter Lemenkov]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02013.html</ref> about the idea of creating a Fedora Foundation outside of the U.S.A. the usual arguments from the past few years were rehashed. [[User:Kkofler|Kevin Kofler]] gave<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02025.html</ref> an able summary why this would still present Red Hat with a problem. |
|
| |
|
| [7] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg03051.html | | An assertion by [[User:|Alexey Torkhov]] that there existed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02390.html</ref> a Red Hat-sanctioned "RussianFedora" spin which contained mp3 codecs and other material excluded from the actual Fedora Project repositories drew demands for proof from [[User:Sundaram|Rahul Sundaram]]. |
|
| |
|
| [[DavidWoodhouse|David Woodhouse]] also wanted[8] to see the back of libtool "[...]you can just throw it away and forget it ever existed? I just write proper Makefiles, and if I ever _want_ to spend a couple of minutes watch some bizarre script trying to work out what type of FORTRAN compiler I have on my system, I can write myself a little bash script for that too[...]" but [[RichardJones|Richard W. M. Jones]] disagreed[9] sharply as he found it useful for building shared libraries on a wide variety of platforms. In response to [[ColinWalter|Colin Walters']] suggestion to build a hook in <code>RPM</code> to nuke <code>.la</code> files he stated[10] that they were essential for the <code>MinGW</code> packages.
| | <references/> |
|
| |
|
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00019.html
| | === Will FESCo Revisit Kmods ? === |
|
| |
|
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00024.html | | A discussion of why <code>VirtualBox</code> will not be a feature due to its code not yet heading upstream and consequently remaining as <code>kmods</code> drew a statement of support from [[User:Kkofler|Kevin Kofler]] for reverting the current banning of <code>kmods</code> should he become a FESCo member. Upon request from [[RichardJones|Richard W.M. Jones]] for a dispassionate summary of the reasons to avoid <code>kmods</code> drew<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02254.html</ref> a concise response from [[User:Skvidal|Seth Vidal]]. |
|
| |
|
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00023.html | | [[User:Adamwill|Adam Williamson]] and [[User:Mdomsch|Matt Domsch]] (Dell's DKMS mastermind) kicked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02368.html</ref> some ideas back and forth over the advantages of <code>akmods</code> versus <code>kmods</code>. |
|
| |
|
| [[ToshioKuratomi|Toshio Kuratomi]] and [[MichaelSchwendt|Michael Schwendt]] discussed[11] how newer versions of <code>libltld</code> can work without missing <code>libtool archives</code> and that it was desirable to remove them because a "[...] private copy of a system library would be a violation of the Packaging Guidelines for security reasons [.]"
| | <references/> |
|
| |
|
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00064.html
| | === Upgrade from Fedora 10 to Rawhide (Fedora 11) === |
|
| |
|
| [[RichardJones|Richard W. M. Jones]] decided[12] to do some testing to determine whether MinGW needed "[...] the *.la files for MinGW packages" or "[...] the .la files in MinGW packages[.]" | | Following a report from [[UweKiewel|Uwe Kiewel]] that a <pre>yum upgrade</pre> had spewed all sorts of errors the supported methods for upgrades were re-stated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02041.html</ref> by [[User:Adamwill|Adam Williamson]]: "[I]f you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline." |
|
| |
|
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00085.html
| | <references/> |
Developments
In this section the people, personalities and debates on the @fedora-devel
mailing list are summarized.
Contributing Writer: Oisin Feeley
Would You Like to Write This Beat ?
Following this issue (FWN#178) I will, with regret, no longer be covering the @fedora-devel list. If you are interested in writing this weekly summary of the deeds and doings on the list then please contact fedora-news-list@redhat.com or Pascal Calarco. A short overview of what you may need to do can be obtained by reading the workflow[1] section of the wiki. The @fedora-news list is also extremely open and helpful. Joining[2] the News Project is quite straightforward.
Is gNaughty a Hot Babe ?
Rahul Sundaram posted[1] the results of a survey conducted, primarily on @fedora-list and on the forums, to discover which non-repository-packaged software Fedora consumers were using.
One interesting point is that CMUCL[2] was revealed[3] to be only available for 32-bit systems. However what got people really excited was[4] Rahul's question about what to do concerning the gNaughty package. Its sole purpose seemed[5] to be downloading pornography. Rahul referenced the hot-babe CPU monitor which enjoyed controversy in Debian packaging circles due to its use of female nudity. Rahul wanted to find out "[...] is this allowed in Fedora?"
Amusingly a good deal of the controversy focused on whether the content was freely redistributable, but a predictable moral angle was raised[6] by Muayyad AlSadi who asked for help in producing a spin which removed content deemed objectionable. Muayyad is a Jordanian developer who has been producing an Arabic-localized Fedora spin named "Ojuba" for some time. Muayyad sought a way to make identifying and tagging packages easier to facilitate this spin. Bill Nottingham was[7] skeptical about the chances of tags keeping meaning unless there was some sort of review board. Equally predictable was[8] the reaction typified by Seth Vidal which resisted any attempt to restrict packages according to standards which had nothing to do with licensing or patent issues. Mathieu Bridon thought[9] that the creation of a wiki-page by Muayyad would allow anyone interested in co-ordinating work on "Inappropriate Content" to just go ahead and do it without dragging in bureaucracy.
Chrome9 Vx800 Graphics Support on LiveUSB
Kristaps Viesalgs asked[1] for help in getting the Fedora Live USB to boot correctly on a machine using a Via Vx800 "Chrome9" GPU. Kristaps had some success with the latest upstream version (from their subversion repository) and asked: "Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? Is Fedora planning to make for VIA graphic chipset autoconfiguration utility?"
Adam Jackson asked[2] for a more specific bug report because the chip should be supported. He preferred not to ship an autoconfiguration utility instead of just getting the driver correct. Similar points were made by Adam Williamson and [[User:|Xavier Bachelot]]. The latter asked[3] any interested developers to help out the openchrome project in both the 2D and 3D(Gallium) sides.
Who Wants a Pony?
Kushal Das promised[1] a pony to anyone that would take the trouble to review[2] one of his packages.
Firestarter Retired as Unportable to PolicyKit
Adam Miller asked[1] whether he should just retire the Firestarter[2] package for which he had recently become the maintainer. His query was based on the recent filing of RFEs to integrate Firestarter with PolicyKit. These suggested to Adam that a large amount of work would be needed due to the lack of any upstream activity for four years and the need to grok PolicyKit.
Following confirmation from Rahul Sundaram and Seth Vidal a decision was made[3] by Adam: "I would honestly rather retire the package than do a WONTFIX, if the project as a whole is going the direction of PolicyKit and upstream is dead then I don't want to keep old and busted cruft around the repositories as Fedora continues to look towards the future."
A further suggestion from "Cry" prompted[4] Adam to start filing RFEs against system-config-firewall for any features present in Firestarter but missing in system-config-firewall.
Russian Fedora ?
When Peter Lemenkov asked[1] about the idea of creating a Fedora Foundation outside of the U.S.A. the usual arguments from the past few years were rehashed. Kevin Kofler gave[2] an able summary why this would still present Red Hat with a problem.
An assertion by [[User:|Alexey Torkhov]] that there existed[3] a Red Hat-sanctioned "RussianFedora" spin which contained mp3 codecs and other material excluded from the actual Fedora Project repositories drew demands for proof from Rahul Sundaram.
Will FESCo Revisit Kmods ?
A discussion of why VirtualBox will not be a feature due to its code not yet heading upstream and consequently remaining as kmods drew a statement of support from Kevin Kofler for reverting the current banning of kmods should he become a FESCo member. Upon request from Richard W.M. Jones for a dispassionate summary of the reasons to avoid kmods drew[1] a concise response from Seth Vidal.
Adam Williamson and Matt Domsch (Dell's DKMS mastermind) kicked[2] some ideas back and forth over the advantages of akmods versus kmods.
Upgrade from Fedora 10 to Rawhide (Fedora 11)
Following a report from Uwe Kiewel that a
yum upgrade
had spewed all sorts of errors the supported methods for upgrades were re-stated[1] by Adam Williamson: "[I]f you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline."
