From Fedora Project Wiki

< FWN‎ | Beats

(add useful JeremyKatz quote)
(Devel #168 pass 1)
Line 6: Line 6:
Contributing Writer: [[User:Ush|Oisin Feeley]]
Contributing Writer: [[User:Ush|Oisin Feeley]]


=== GSoC InstantMirror ===
=== Auto Upgrading YUM Not Worth It ===


[[WarrenTogami|Warren Togami]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00873.html</ref> for any interested parties to get involved with a GSoC<ref>http://code.google.com/soc/</ref> project to improve repository replication to mirrors.
A discussion over the possible ways to upgrade from Fedora 10 to Fedora 11 was started<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01145.html</ref> by [[GerryReno|Gerry Reno]] when he asked why <code>preupgrade</code><ref>http://fedoraproject.org/wiki/PreUpgrade</ref> from <code>Fedora 10</code> only presented <code>Rawhide</code> as an option and not <code>Fedora 11 Alpha</code>.


<references/>
A quick answer posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01147.html</ref> by GianlucaSforna mentioned the technical difficulties of tracking the versions of packages included in the alpha release. [[User:Pfrields|Paul W. Frields]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01168.html</ref> concerned that anyone trying such an upgrade made sure to update <code>rpm</code> before upgrading.  This latter point spawned<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01185.html</ref> a longish thread in which the possibility of making <code>YUM</code> take care of checking to see whether a newer version of itself or <code>rpm</code> is available.


=== Enhance Anaconda to Enable Repositories As Needed ? ===
[[User: Wwoods|Will Woods]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01254.html</ref> that running <code>preupgrade</code> isntead of doing a <code>`yum upgrade'</code> avoided all that confusion.


[[JudCraft|Jud Craft]] reported<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00921.html</ref> that installing from the <code>Fedora 10</code> DVD with the <code>fedora-updates</code> repository enabled resulted in a broken <code>NetworkManager</code> due to a missing dependency on <code>libudev.so.0</code>. Jud pointed out<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00929.html</ref> that although he could install the missing library from the DVD the situation would present a serious problem to anyone that tried "[...] a network install with updates [...] the result (a system without network access) can't be fixed without A) network access, or B) another Fedora image (also possibly requiring more network access)."
<references/>  


In answer to [[User:Jspaleta|Jef Spaleta's]] questions Jud revealed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00938.html</ref> that: "[libudev.so.0] doesn't seem to actually be installed by the stock F10 image.  If I do a plain install (no updates), NetworkManager works fine.  Running a `yum update' then pulls down all the updates, as well as `Install libudev0'.  So at some point I suppose NetworkManager picked up a dependency on libudev0, but for some reason updating during the installation process doesn't pull this new package in." [[User:Kkofler|Kevin Kofler]]<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00944.html</ref> and [[User:Jkeating|Jesse Keating]]<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00947.html</ref> both pointed out that: "[T]he updates repo isn't the Everything repo.  To really do a proper install with updates you have to enable both the Updates repo and the Everything repo." Kevin added that this was why the install from DVD with updates enabled was not an officially supported method.
=== How to Update from Fedora 10 to Rawhide ===


Several people, including [[User:Thl|Thorsten Leemhuis]], suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00953.html</ref> that modifying the <code>anaconda</code> installer to be aware of which repositories depend on each other would be useful. [[User:Jkeating|Jesse Keating]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00955.html</ref> not averse to the idea as long as it could be done in a "[...] distro agnostic way. Avoiding hardcoded hacks specifically for Fedora is one of the goals of anaconda upstream."
When "nodata" reported<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01227.html</ref> that an attempt to update <code>rpm</code> resulted in errors and <code>preupgrade</code> also failed he concluded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01245.html</ref> that the instructions<ref>http://fedoraproject.org/wiki/Fedora_11_Beta_release_notes#RPM_issues</ref> on the wiki were flawed.


Later [[User:Katzj|Jeremy Katz]] explained<ref>http://://www.redhat.com/archives/fedora-devel-list/2009-March/msg00976.html</ref> that the thinking behind the installer ignoring unsatisfiable dependencies in such cases is to "[...] get someone installed and then let them clean up afterwards[.]"
[[User:Skvidal|Seth Vidal]] and [[User:Jkeating|Jesse Keating]] were<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01250.html</ref> sure that "nodata" was not using the correct procedure which they stated as a two stage process with the first step being a:
<pre>yum update rpm</pre>
with the <code>Fedora 10</code> repository enabled and then to enable the <code>Rawhide</code> repository and do a general:
<pre>
yum update
</pre>


<references/>
Unfortunately this seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01253.html</ref> to not work for "nodata" and [[MichaelYoung|Michael A. Young's]] suggestion<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01266.html</ref> that a "[...] temporary issue with F10 having a more recent version of audit-libs than rawhide [...]" seemed like a promising lead. "Nodata" resolved<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01231.html</ref> problem by using the rescue CD to do a "<code>rpm -e --nodeps</code>" and then "<code>rpm --rebuilddb</code>".


=== Password Resets and Inactive Accounts ===
=== Fedora 11 Beta Slips by One Week ===


When [[User:Mmcgrath|Mike McGrath]] was perturbed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00509.html</ref> that so many FAS account holders had failed to reset their passwords recently a discussion of the entanglement of active account status and passwords followed.
[[User:Jkeating|Jesse Keating]] announced<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01163.html</ref> that Release Engineering, QA and maintainers had agreed that the beta release of <code>Fedora 11</code> would slip by seven days due to several issues mostly related to the rewrite of <code>anaconda</code> storage.  


Many respondents posted that they had received the email notifications but had not needed to, or had not had time to, perform their password reset.
<references/>


[[http://bugzilla.fedora.us/wiki/TomLane Tom Lane]] worried that forcing periodic password resets caused people to weaken security by writing down their passwords but [[User:Bruno|Bruno Wolf III]] argued<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00612.html</ref> that a potentially bigger threat might be "[...] someone forging messages from Mike with deceptive URLs that trick people into changing their passwords using a hostile proxy. Doing things in the current manner is training people to get fooled." He added that cryptographically signing the reset messages was important.
=== Finding the Source ===


[[User:Till|Till Maas]] requested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00710.html</ref> consistent titling of the password reset notification emails, suggested extending the grace period beyond two weeks and asked that the notification contains the information that the contents of the user's fedorapeople.org home would be moved.
A request was posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01100.html</ref> for help in finding the <code>Fedora</code> kernel sources by [[JoeOvanesian|Joe Ovanesian]]. A quick pointer was given<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01101.html</ref> by [[TomDiehl|Tom Diehl]]:
<pre>
# yum install yum-utils


[[User:Mmcgrath|Mike McGrath]] and others explored<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00779.html</ref> possible grace periods and numbers of warning emails.
# yumdownloader --source package_name
</pre>


[[User:Pertusus|Patrice Dumas]] asked why there was a password reset at all and was answered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00658.html</ref> by [[User:Jkeating|Jesse Keating]] that it was "[...] the best way Infra has today to discover all the active and inactive accounts." In response [[User:Toshio|Toshio Kuratomi]] pointed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00677.html</ref> to an open ticket which nominally deals with how long accounts should be left open if passwords have expired but had become<ref>http://fedorahosted.org/fedora-infrastructure/ticket/1237</ref> an investigation of how account inactivity can be determined.  
[[User:Sandeen|Eric Sandeen]] wondered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01130.html</ref> if it might be better to use the upstream repositories and Joe explained<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01151.html</ref> that his objective was to build a new kernel from source and use KGDB<ref>http://kgdb.linsyssoft.com/</ref> to gain familiarity with the source. [[User:Tmz|Todd Zullinger]] pointed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01154.html</ref> to a goldmine of information on the topic on the wiki<ref>http://fedoraproject.org/wiki/Building_a_custom_kernel</ref>.


After [[User:Mmcgrath|Mike McGrath]] explained that "[...] we've got thousands of contributors, relatively few of them actually commit to cvs.  So we could go around to figure out how to make all of our various auth points report back but that's a lot of work.  The account system is the only common point of entry for every contributor [...]" [[ChristopherAillon|Christopher Aillon]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00812.html</ref>: "So let's require to them to simply _log in_ to FAS to reset the timer (you need to do that to change passwords, anyway!)."
<references/>  


<references/>
=== Fedorahosted Releases ===


=== Mono Conflagration Jumps to Blog ===
[[User:Jstanley|Jon Stanley]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01015.html</ref> a quick note to say that he had made it easier to specify the upstream source URL in specfiles due to a change in fedorahosted.org


Following the FESCo decision not to replace <code>rhythmbox</code> with <code>banshee</code> as the default media-player in <code>Fedora 11</code><ref>http://fedoraproject.org/wiki/FWN/Issue166#Fedora_11_Default_Mediaplayer_Not_Banshee._Mono_to_Blame_.3F</ref> some follow-up clarifications were made by parties to the discussion and the conflagration jumped between @fedora-devel and the personal blog of [[User:Dnielsen|David Nielsen]], the <code>Banshee</code> ex-maintainer and perhaps the main force behind the Mono SIG<ref>http://fedoraproject.org/wiki/SIGs/Mono</ref>.
<references/>  


[[User:Notting|Bill Nottingham]] put forward<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00529.html</ref> a concise time-line which attempted to show that the proposal had been handled in a straightforward and usual manner. Bill noted that the Desktop SIG had expressed<ref>http://www.redhat.com/archives/fedora-desktop-list/2009-February/msg00063.html</ref> a lack of enthusiasm early in the process and that the imminent beta-freeze meant that the decision had to be taken without further prolonged discussion.
=== How to Open ACLs and Find Non-responsive Maintainers ===


[[User:Adamwill|AdamWilliamson]] suggested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00526.html</ref> that because <code>Mono</code>'s Microsoft links worried many F/OSS developers it would have been a good idea to address such concerns: "[...] explicitly rather than just pretend they don't exist in your initial proposal (the word 'Mono' does not actually occur a single time in the initial version of the Wiki page you posted)."
A couple of related threads dealt with the need to deal with a package which lay dormant apparently due to maintainer inactivity.


A question put by [[User:Johannbg|Jóhann B. Guðmundsson]] wondered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00523.html</ref> whether there was anything preventing the Mono SIG from creating their own Fedora spin in which <code>banshee</code> was given pride of place as the default media-player. [[User:Rdieter|Rex Dieter]] confirmed that there were no obstacles on this path.
[[User:Wolfy|Manuel Wolfshant]] had inquired<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00962.html</ref> earlier in the week about the allowing the provenpackagers to fix the <code>gdal</code> package. [[User:Jstanley|Jon Stanley]] promised<ref>https://www.redhat.com/archives/fedora-devel-list/2009-March/msg01035.html</ref> to re-add a ticket dealing with the issue to an upcoming FESCo meeting.  


A proposal to adopt a Code of Conduct modeled upon Ubuntu's was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00498.html</ref> made by [[RichardJones|Richard W.M. Jones]]. He also expressed regret that David was leaving Fedora and apparently moving to <code>Ubuntu</code> as referenced<ref>http://davidnielsen.wordpress.com/2009/03/07/drawing-my-own-conclusion/</ref> by a blog entry. Reading the blog suggest that <code>Foresight Linux</code> seems more to David's taste although one comment does point out<ref>http://davidnielsen.wordpress.com/2009/03/07/drawing-my-own-conclusion/#comment-285</ref> that Ubuntu "[...] head community people have been calling for volunteers to increase the work surrounding Mono and have a huge love for banshee<ref>http://castrojo.wordpress.com/2009/01/11/monodevelop-rockstar-needed-inquire-within/</ref> and Canonical isn’t anti-mono since some of their new job postings desire Mono as a skill<ref>http://webapps.ubuntu.com/employment/canonical_GDOS/</ref>."
In a separate thread the latest Rawhide Report<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01234.html</ref> led [[User:Kkofler|Kevin Kofler]] to ask<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01268.html</ref> for an opening of the ACLs on <code>gdal</code><ref>GDAL is a library to handle Geographic Information Systems data</ref> so that it could be fixed for multiple dependent packages. When [[User:Jkeating|Jesse Keating]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01296.html</ref> [[User:Alexlan|Alex Lancaster]] if he started the non-responsive maintainer process the answer appeared<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01301.html</ref> to be that it was Jesse himself. In an aside MilosJakubicek provided<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01298.html</ref> links to the current process. Alex seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01303.html</ref> to demonstrate clearly that the maintainer was inactive.
 
[[User:Skvidal|Seth Vidal]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00504.html</ref> among those who wondered specifically how such a code could be enforced and also where specifically the Fedora Project could be alleged to have engaged in misconduct on this issue. Reading David's blog seems to suggest both that any rudeness was privately exchanged and that his perception is<ref>http://davidnielsen.wordpress.com/2009/03/07/drawing-my-own-conclusion/#comment-297</ref> that "[...] Mono isn't welcome in Fedora, and will always be a second class citizen[.]"
 
<references/>
 
=== Documentation Betas ===
 
[[User:Jjmcd|John J. McDonough]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00835.html</ref> that owners of major features should review the Beta release notes. [[ScottRadvan|Scott Radvan]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00823.html</ref> that the Security Guide<ref>http://sradvan.fedorapeople.org/Security_Guide/en-US/</ref> would benefit from the scrutiny of any interested @fedora-devel readers.
 
<references/>
 
=== Provenpackager Re-Seed ===
 
[[User:Jstanley|Jon Stanley]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00555.html</ref> that everyone read the process by which the "provenpackager" group will be repopulated.
 
A request by [[RalfCorsepius|Ralf Corsepius]] for some definitions led [[User:Pertusus|Patrice Dumas]] to post<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00571.html</ref> that: "provenpackagers are people who can change all the packages with opened ACLs. Sponsors are the people who can accept new contributors in fedora." Further discussion led<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00581.html</ref> [[User:Mschwendt|Michael Schwendt]] to voice a concern that non-responsive maintainers might be shielded from feedback if provenpackagers step in to update and upgrade packages. [[User:Kkofler|Kevin Kofler]] offered<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00718.html</ref> the non-responsive maintainer process as a way to rectify any problems with Bugzilla tickets being ignored.
 
[[User:Mschwendt|Michael Schwendt]] questioned<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00591.html</ref> [[User:Pertusus|Patrice Dumas]] in greater detail as to why provenpackagers and sponsors are not equal sets.
 
Further details on how to apply to FESCo to become a provenpackager were elicited<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00594.html</ref> from [[User:Jwboyer|JoshBoyer]] by [[StepanKaspal|Stepan Kaspal]].
 
In a separate thread MichelSalim asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00871.html</ref> about the preferred way to become a sponsor.
<references/>
 
=== Closing Bugs NEXTRELEASE ===
 
[[User:Cwickert|Christoph Wickert]] requested<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00552.html</ref> that all maintainers (and especially Red Hat developers) would "[p]lease fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!"
 
When [[User:Sundaram|Rahul Sundaram]] responded that it depended on the seriousness of the bug and complexity of back-porting [[DanielBerrange|Daniel P. Berrange]]<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00575.html</ref> and [[User:Rakesh|Rakesh Pandit]]<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00572.html</ref> acknowledged that such complex cases might exist but that suggested that this was often a cop-out which could discourage users.
 
[[User:Katzj|Jeremy Katz]] responded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00622.html</ref> "[...] as the person who has apparently pissed you off this morning [...]" and described the case in point as much more complex than Christoph had claimed. It seemed that Christoph's ability to create <code>LiveCD</code> images of <code>Fedora 11</code> using <code>Fedora 10</code> as the development platform had been stymied by changes to <code>syslinux</code>. Jeremy added that even if this single change were reverted Christoph would need a newer <code>kernel</code> and <code>squashfs-tools</code> and more.
 
Later Jeremy clarified<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00777.html</ref> that the combination of <code>livecd-creator</code> + <code>mock</code> were complicated by <code>SELinux</code> but that this had been addressed by recent work.
 
One complication is that <code>Bodhi</code> uses NEXTRELEASE even for updates to stable releases. After some confusion on this point LukeMacken posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-March/msg00672.html</ref> that anyone wanting to change the behavior should file a ticket.


<references/>
<references/>

Revision as of 01:30, 23 March 2009

Developments

In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.

Contributing Writer: Oisin Feeley

Auto Upgrading YUM Not Worth It

A discussion over the possible ways to upgrade from Fedora 10 to Fedora 11 was started[1] by Gerry Reno when he asked why preupgrade[2] from Fedora 10 only presented Rawhide as an option and not Fedora 11 Alpha.

A quick answer posted[3] by GianlucaSforna mentioned the technical difficulties of tracking the versions of packages included in the alpha release. Paul W. Frields was[4] concerned that anyone trying such an upgrade made sure to update rpm before upgrading. This latter point spawned[5] a longish thread in which the possibility of making YUM take care of checking to see whether a newer version of itself or rpm is available.

Will Woods suggested[6] that running preupgrade isntead of doing a `yum upgrade' avoided all that confusion.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01145.html
  2. ↑ http://fedoraproject.org/wiki/PreUpgrade
  3. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01147.html
  4. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01168.html
  5. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01185.html
  6. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01254.html

How to Update from Fedora 10 to Rawhide

When "nodata" reported[1] that an attempt to update rpm resulted in errors and preupgrade also failed he concluded[2] that the instructions[3] on the wiki were flawed.

Seth Vidal and Jesse Keating were[4] sure that "nodata" was not using the correct procedure which they stated as a two stage process with the first step being a: 

yum update rpm

with the Fedora 10 repository enabled and then to enable the Rawhide repository and do a general: 

yum update

Unfortunately this seemed[5] to not work for "nodata" and Michael A. Young's suggestion[6] that a "[...] temporary issue with F10 having a more recent version of audit-libs than rawhide [...]" seemed like a promising lead. "Nodata" resolved[7] problem by using the rescue CD to do a "rpm -e --nodeps" and then "rpm --rebuilddb".

Fedora 11 Beta Slips by One Week

Jesse Keating announced[8] that Release Engineering, QA and maintainers had agreed that the beta release of Fedora 11 would slip by seven days due to several issues mostly related to the rewrite of anaconda storage.

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01227.html
  2. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01245.html
  3. ↑ http://fedoraproject.org/wiki/Fedora_11_Beta_release_notes#RPM_issues
  4. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01250.html
  5. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01253.html
  6. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01266.html
  7. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01231.html
  8. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01163.html

Finding the Source

A request was posted[1] for help in finding the Fedora kernel sources by Joe Ovanesian. A quick pointer was given[2] by Tom Diehl: 

# yum install yum-utils

# yumdownloader --source package_name

Eric Sandeen wondered[3] if it might be better to use the upstream repositories and Joe explained[4] that his objective was to build a new kernel from source and use KGDB[5] to gain familiarity with the source. Todd Zullinger pointed[6] to a goldmine of information on the topic on the wiki[7].

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01100.html
  2. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01101.html
  3. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01130.html
  4. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01151.html
  5. ↑ http://kgdb.linsyssoft.com/
  6. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01154.html
  7. ↑ http://fedoraproject.org/wiki/Building_a_custom_kernel

Fedorahosted Releases

Jon Stanley posted[1] a quick note to say that he had made it easier to specify the upstream source URL in specfiles due to a change in fedorahosted.org

  1. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01015.html

How to Open ACLs and Find Non-responsive Maintainers

A couple of related threads dealt with the need to deal with a package which lay dormant apparently due to maintainer inactivity.

Manuel Wolfshant had inquired[1] earlier in the week about the allowing the provenpackagers to fix the gdal package. Jon Stanley promised[2] to re-add a ticket dealing with the issue to an upcoming FESCo meeting.

In a separate thread the latest Rawhide Report[3] led Kevin Kofler to ask[4] for an opening of the ACLs on gdal[5] so that it could be fixed for multiple dependent packages. When Jesse Keating asked[6] Alex Lancaster if he started the non-responsive maintainer process the answer appeared[7] to be that it was Jesse himself. In an aside MilosJakubicek provided[8] links to the current process. Alex seemed[9] to demonstrate clearly that the maintainer was inactive.

  1. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00962.html
  2. ↑ https://www.redhat.com/archives/fedora-devel-list/2009-March/msg01035.html
  3. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01234.html
  4. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01268.html
  5. ↑ GDAL is a library to handle Geographic Information Systems data
  6. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01296.html
  7. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01301.html
  8. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01298.html
  9. ↑ http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01303.html
Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Beats/Developments&oldid=91991"